AppEasy Core SDK is now open source!

If I remember correctly I promised a while back that I was going to open up the source to the AppEasy Core SDK. if you don’t know what that is then its a FREE open source cross platform game and app engine for mobiles and desktop that can be re targeted to work on anything you like as long as you implement the platform abstraction layer. At the moment, a Marmalade SDK layer is implemented so you can use it right out of the box. You will however need a Marmalade license to use it, although having a Marmalade license will give you deployment access to a vast range of platforms so its well worth it. if not then simply implement the platform layer for whatever platform(s) you desire. If you dont fancy any of that and just want to use Lua and XOML then you can always give the AppEasy service a try, which lets you deploy apps to iOS / Android and Windows desktop without the need to compile and re-write code etc..

AppEasy Core SDK is basically the big professional and powerful child of the old IwGame Engine. The IwGame Engine started as a tutorial project that I started a few years ago that was meant to teach developers how to use the Marmalade SDK. However, Marmalade has no out of the box game engine so IwGame evolved into a fully fledged game / app engine to fill that gap, although it was hastily developed and built directly on the Marmalade platform. I’m very much a recycler, so that’s not how I generally like to write an engine, I like to have a clear separation between engine and platform so it can be re-targeted at different platforms quite easily. I also wanted to get rid of the obscenely long names and add some proper structure / documentation to make the whole thing more easily understandable.

Well I think I accomplished all that and more, I also added many new features and fixed a mass of bugs along the way. When I get the time I will be replacing the old IwGame Engine page with an AppEasy Core SDK page, for me IwGame needs to be buried now I think.

I also developed a game / app editor called Goji Editor that lets you develop full on games and apps within the editor and export to AppEasy, Marmalade Quick and other engines coming soon, including HTML 5.

AppEasy Core SDK has the following core features:

General Features
– FREE and open source! (MIT)
– Can directly use data exported from the Goji Editor (http://www.gojieditor.com)
– Can be targeted at any development system / SDK by implementing the platform layer
– Marmalade SDK platform already implemented, giving you access to many platforms out of the box
– Develop using XML, Lua and / or C++
– Easy to learn mark-up driven language called XOML that enables rapid development
– Support for Lua scripting
– Styles and Templates
– Local and web based assets
– Proportional sizing and positioning
– Auto screen sizing and device orientation lock
– Local storage access
– Multi-touch input
– Accelerometer and compass support
– Smooth sub-pixel rendering and batch rendering for speed
– Touch panning and pinch zoom
– Persistent data
– HTTP POST / GET defined declaratively
– Access to video camera streaming
– Define actions that can be carried out when events occur

Game Features
– Polygonal based sprites and sprite depth
– texture atlases and batching
– Support for Scenes (game world / app canvas) and Actors (game / app objects)
– Images, fonts, compressed WAV sound effects and and MP3 music
– Animation
– Box2D Physics (fixtures, shapes, materials, collisions and joints)
– Video Playback

App Features
– Create simple or complex user interfaces
– Full support for simple and complex data bindings
– Data definition and organisation
– Access to local and remote data
– Support for SQLite

User Interface Features
– Text input boxes
– Buttons / Check boxes
– Labels
– Icons
– Sliders
– Panels (StackPanel, WrapPanel, Canvas)
– Grids
– Image / Text View – Support for pinch zoom and pan
– Web View (display web content)
– Tab Bars
– Video Overlays
– Sliders
– XML data bindings
– Multi-touch based user interface (up to 5 simultaneous touches)

Monetisation Features
– Ad integration
– In-app purchases

Advanced Features
– XOML Variables
– Modifiers
– XOML Programs and commands
– Inline scripts

Social Features
– Facebook API support

API documentation
API documentation is located at http://www.appeasymobile.com/appeasy-api/

The AppEasy Core SDK comes complete with:
– PDF documentation located in the Docs sub folder
– Extensive doxygen code documentation
– An example app that contains 70 examples demonstrating many parts of the SDK
– An example game
– XML schema for XOML

Whilst free support is not provided, a community support forum is available at AppEasy Community

You can download AppEasy Core SDk from Github

IwGame Engine v0.29 Released – XOML is evolving

New here? What’s IwGame? IwGame is an open source free to use cross platform game engine for iPhone, iPad, Android, Bada, Playbook, Symbian, Windows Mobile, LG-TV, Windows and Mac, built on top of the Marmalade SDK. You can find out more and download the SDK from our IwGame Engine page.

The Universe conspired against me this week, first of all landing me with a nice flu, followed directly by some horrible sickness bug that featured projectile vomiting of the likes only seen in movies such as the Exorcist! Thankfully the Universe decided to give me a break this week so an IwGame Engine update got finished.

Most of the changes this week are XOML related as this is the general direction we want to take the game engine. A good mix of XOML mark-up and solid coding should make games and media apps very quick and easy to develop.

Oh and we got a new logo for the IwGame Engine woohoo! Feel free to use the logo in any of your IwGame powered products, or if you want to link to us.

Ok, onto the list of iwGame Engine changes for v0.29:

  • New style system added to XOML. Actors and scenes can now use a style to reduce repetition
  • Actors and scenes now handle events such as OnSuspend, OnTapped, OnBeginTouch etc.. When an event fires it executes a collection of actions
  • Actions added to XOML to allow definition of collections of actions that can be executed. Many default actions are suppported such as ChangeScene, KillScene, PlayTimeline, PlaySound etc.. Custom actions can also be added toextend the system
  • CIwGame now handles touch begin touch, end touch and tapped events
  • CIwGame now has new Postdraw() method for adding in custom post draw rendering
  • Actors can now be made tappable and now handle OnTapped(), OnBeginTouch() and OnEndTouchEvents()
  • Actors have new HitTest() method that can be used to check if a point is inside the actors visual
  • XOML now supports creation of cameras
  • XOML now supports creation of variables and update of variables using actions, supports string, bool, int, float, vec2, vec3 and vec4
  • XOML files can now load other XOML files with new LoadXOML tag as well as LoadXOML action
  • Scenes now support a type field
  • CIwGameBitmapSprite now supports image transforms (flips. mirrors etc) which can be also applied to actors visuals using FlipX and FlipY attributes
  • You now change the current time of a CIwGameAnimInstance and CIwGameAnimTimeline
  • Bug Fix – Actor visibile state now works properly
  • Bug Fix – CIwGameShape::setShape() now works
  • Bug Fix – Transform is now reset after CIwGameAdsView finishes rendering
  • Bug Fix – JPEG file detection fixed, was not detecting certain types of JPEG files
  • Bug Fix – CIwGameString::FindNext() crash fixed

Quite a few changes and bug fixes. Note that someo f the bug fixes directly affected IwGameAds so an update to that API will be released shortly.

Lets take a look at the changes in more detail.

XOML Variables

XOML got variables, but why? Well, there are a number of reasons:

  • We want to be able to define values that can be read by the main code
  • We want to change these values via actions
  • When we implement the UI system we are looking to add data binding capabilities that will rely on values

You can declare a variable in XOML like this:

    <Variable Name="PlayerName" Type="string" Value="Player One" />
    <Variable Name="PlayerScore" Type="int" Value="0" />
    <Variable Name="PlayColour" Type="vec4" Value="255, 128, 64, 8" />

You can later modify the value of that variable using a SetVar action, more on this later.

Each scene contains its own variables collection and the global resource system also contains a global variables collection.

XOML Styles

XOML now supports the styling of actors and scenes using the new Style tag. XOML styles enable you to create a set of properties and values that are common across a range of objects then apply tat style the to them all. Hers a quick

example:

<Style Name="BasicActorStyle">
    <Set Property="Size" Value="60, 60" />
    <Set Property="Angle" Value="0" />
    <Set Property="SrcRect" Value="0, 0, 36, 40" />
    <Set Property="Image" Value="Sprites" />
    <Set Property="Timeline" Value="Player1Intro1" />
    <Set Property="Shape" Value="PlayerShape" />
    <Set Property="Box2dMaterial" Value="BounceyBall" />
    <Set Property="CollisionFlags" Value="1, 1, 1" />
</Style>

<TestActor Name=”Player2″ Style=”BasicActorStyle” Position=”0, -150″ />

The TestActor Player2 will be assigned all of the values in the properties defined in the style saving you a whole bunch of typing as well as making your mark-up much more readable and easier to maintain.

XOML Events And Actions

Actors and scenes now support various events that can fire off user defined actions. The following events are currently defined:

Scenes:

  • OnSuspend – Called when a scene is suspended
  • OnResume – Called when a scene is resumed

Actors:

  • OnTapped – Called when the user taps an actor
  • OnBeginTouch – Called when the user begins to touch an actor
  • OnEndTouch – Called when the user stops touching an actor

More will be added as we think of them or when requested. You can also add your own custom events youself. Check out the CIwGameActor class for a reference on how to do this.

Events wouldn’t really be much use unless we could carry out some kind of action when the event occurred. Actions are defined in XOML using the Actions tag, heres an example:

<Scene Name="GameScene3" Style="GenericSceneStyle" OnSuspend="SuspendActions">
    <Actions Name="SuspendActions">
        <Action Method="SetTimeline" Param1="SceneTransition1" />
        <Action Method="PlaySound" Param1="explosion" />
    </Actions>
</Scene>

You actually create a group of actions that are all executed when the action is called by an event.

The following actions are currently supported:

  • ChangeScene – Changes the currently focused scene to the specified scene
  • SuspendScene – Suspends the specified sceme
  • ResumeScene– Resumes the specified sceme
  • HideScene– Hides the specified sceme
  • ShowScene– Shows the specified sceme
  • ActivateScene – Activates the specified sceme
  • DeactivateScene – Deactivates the specified sceme
  • KillScene – Destroys and removes the specified sceme from the game, all contained resources amd actors will be also be destroyed
  • HideActor – Hides the specified actor
  • ShowActor – Shows the specified actor
  • ActivateActor – Activates the specified actor
  • DeactivateActor – Deactivates the specified actor
  • KillActor – Kills and removes the specified actor
  • PlayTimeline – Plays the specified timeline. If no timeline is supplied then the current actor / scenes timeline will be restarted (depends on where the action was defined)
  • StopTimeline – Stops the specified timeline. If no timeline is supplied then the current timeline will be stopped. (depends on where the action was defined)
  • SetTimeline – Changes to the specified timeline. If no timeline is supplied then the current timeline will changed and restarted. (depends on where the action was defined)
  • PlaySound – Starts playing a sound effect
  • PlayMusic – Starts the playing specified music file
  • StopMusic – Stops the music player playing
  • LoadXOML – Loads a XOML file into scene or globally. If a scene is provided then the XOML will be loaded into that scene
  • SetVar – Sets the value of a variable

Again, more will be added as we think of them or when requested. You can also add your own custom actions youself. Check out the CIwGameXomlAction_Actors class for a reference on how to do this.

Coupled together the events and actions system provide a very powerful way of creating fully interactive content without having to write a single line of code.

Loading Other XOML Files

It is now possible to load other XOML files from a XOML file using the new LoadXOML tag. Heres an example:

<LoadXOML File="Common.xml" />
<LoadXOML File="Sceme2.xml" />
<LoadXOML File="Scene3.xml" />

You can also (as shown in the actions section) load a XOML file from an action.

Using this system you can create fully interactive navigation based content. Think adventure games, books, magazines and informational apps etc..

Scene Cameras

Cameras can now be defined in XOML and attached to scenes. You can also switch a scenes camera using the animation system.

Image Transforms for Sprites and Actors

Sprites and actors can now use an image transform allowing you to flip the source image used to render the object. The ne FlipX and FlipY attributes are now available in XOML.

Well thats it for this update. IwGame now has some very cool features that should hopefully make game / app development much easier and quicker for everyone.

We are going to assess the possibility of wrapping up Marmalades cool UI system with XOML very soon, will keep you all posted on how that goes. I am also looking at producing a new article on in-app purchasing with the Marmalade SDK, which will form the basis of in-app purchasing for the IwGame engine.

Marmalade SDK Tutorial – Creating an Extensible Animation System

This tutorial is part of the Marmalade SDK tutorials collection. To see the tutorials index click here

Had flu all week and now I’ve been afflicted with a chest infection so it’s been a pretty miserable week. At least the news of our game BattleBallz Chaos being shown at the Blackberry Devcon 2011 lifted the old spirits.

In the last tutorial we covered basic sprites and more to the point bitmapped sprites. We began to create a basic API called IwGame which will eventually serve as our game engine framework that we can all hopefully build cool games around (that is once we have weeded all of my bugs out 🙂 ). The idea this week is to get those sprites animating (aside from rotating, scaling and moving), we want the image of our sprite to change. My plan for this week was to build a very basic animation class that we could use to animate our bitmap frames. Well my intentions were good and I started out creating a basic image frame animation class but decided to scrap it and create a more extensive animation system that we can use for more than just image animations. If you just need the code then you can grab it from here, otherwise please feel free to read on.

What is an Animation System?

In the context of this article, an animation system is a bunch of classes that deal with animating specific components. These components could be anything from a simple one dimensional variable that represents speed or a two dimensional variable such as a vector that represents the players position to something a little more complex such as a rectangular area of space that represents a frame in an image animation

How could an animation system be useful to us? Well we could use it to animate the texture that appears on a sprite giving it personality (a face that smiles, cries or laughs for example), or we could animate an objects position and rotation to follow a specific path around the game world. We could even animation a list of instructions or game object states using a discrete animation to give the impression that the object is intelligent.

Here are a few terms that I use during this article:

  • Animation – Refers to the complete animation including all its frames, its playback rate, callbacks etc..
  • Frame – Refers to a single discrete component of the animation, this could be a particular image, position or velocity etc..
  • Frame Index – Refers to the position of a particular animation frame in an array of animation frames

An Extensible Animation System – IwGameAnim

Our new animation system IwGameAnim is built around the CIwGameAnim class. This class serves as a general purpose abstract class that we can derive custom animation types from. In this weeks code we have created 3 animation classes from CIwGameAnim:

  • CIwGameAnimImage – A rectangular bases image animation
  • CIWGameAnimFloat – A single floating point variable animation (useful for animating one dimensional components such as angle, speed and distance)
  • CIwGameAnimFVec2 – A 2D floating point vector variable animation (useful for animating two dimensional components such as velocity and position)

Its important to note at this point that I have not fully tested this code yet. I only spent a few hours writing it and testing it (time constraints), but be certain that as we use more of the animation system in our tutorials it will get fully tested eventually.

We are not going to carry out a lot of in-depth analysis of the code this seek as i want to move the Marmalade SDK tutorials series tutorials along faster, believe it or not creating these tutorials takes up a fair amount of time (although I do thoroughly enjoy writing them). That said lets take a quick look at the CIwGameAnim class:

class CIwGameAnim { // Properties protected: bool Playing; // Current playing state float CurrentFrame; // Current animation frame float PlaybackSpeed; // Rate at which to playback animation int FrameCount; // Total number of animation frames in the animation bool FrameHasChanged; // Set to true when a frame has changed bool Looping; // True if the animation loops int NumLoops; // Total number of loops played back so far int MaxLoops; // Maximum number of loops before animation stops (-1 to play forever) int PlayDelayMs; // Amount of time to wait before starting animation CIwGameCallback StartedCallback; // Callback which is called when the animation starts playing CIwGameCallback StoppedCallback; // Callback which is called when the animation stops playing CIwGameCallback LoopedCallback; // Callback which is called when the animation loops public: void setPlaybackSpeed(float speed) { PlaybackSpeed = speed; } bool hasFrameChanged() const { return FrameHasChanged; } void setPlayDelay(int delay_ms) { PlayDelayMs = delay_ms; } void setStartedCallback(CIwGameCallback callback) { StartedCallback = callback; } void setStoppedCallback(CIwGameCallback callback) { StoppedCallback = callback; } void setLoopedCallback(CIwGameCallback callback) { LoopedCallback = callback; } void setLooped(int num_loops); void setCurrentFrame(float frame); float getCurrentFrame() const { return CurrentFrame; } void Start() { Playing = true; if (PlayDelayMs != 0) PlayDelay.setDuration(PlayDelayMs); } void Stop() { Playing = false; } bool isPlaying() const { return Playing; } void Restart(); // Properties End protected: CIwGameTimer PlayDelay; // Timer used to time start of animation public: CIwGameAnim() : Playing(false), CurrentFrame(0), PlaybackSpeed(0), FrameHasChanged(true), Looping(false), NumLoops(0), MaxLoops(0), PlayDelayMs(0), StartedCallback(NULL), StoppedCallback(NULL), LoopedCallback(NULL) {} virtual ~CIwGameAnim() {} virtual void Release() = 0; virtual bool Update(float dt); };

Below is a brief description of the classes properties:

  • Playing – Marks the animation as playing or stopped
  • CurrentFrame – The current animation frame index (think of the integer part of this variable as the frame number of the animation frame we are currently seeing)
  • PlaybackSpeed – The rate at which to play back the animation, a value of  1.0f / davice_frame_rate would play the animation back at one animation frame per second (quite slowly in other words)
  • FrameCount – Total number of frames in this animation
  • FrameHasChanged – Marked true when the animation switches from one animation frame to the next
  • Looping – True if this animation loops when it reaches the end
  • NumLoops – The total number of times the animation has looped around
  • MaxLoops – The maximum number of times the animation is allowed to loop before stopping (a value of -1 means loop forever)
  • PlayDelayMs – This can be used to delay the animation playing at the start. This can be useful if you want to fire off a group of animations at the same time, but have them start at different times
  • StartedCallback – This callback (that you supply) will be called when the animation starts to play
  • StoppedCallback – This callback (that you supply) will be called when the animation stops playing naturally (not when Stop() is called)
  • LoopedCallback – This callback (that you supply) is called each time the animation reaches its end and loops to the start again

You never directly create an animation from this class, instead you can derive your own animation type from this class or use one of those already provided.

Bitmap Image Animation – IwGameAnimImage

Image animation in our game engine involves displaying different image frames one after the other to give the impression of giving personality to our sprite based objects. We store all of our animations on a sprite atlas (also known as a sprite sheet), which looks something like this:

Example sprite atlas / sheet
Example sprite atlas / sheet

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

A sprite atlas is basically a large image that contains a group of other images. To create an image animation we simply display different portions of the sprite atlas.

Bitmap animations are handled by the CIwGameAnimImage class. The CIwGameAnimImage class looks like this:

class CIwGameAnimImage : public CIwGameAnim { protected: CIwGameAnimImageFrame* Frames; // This class takes over management of Frames memory public: CIwGameAnimImage() : CIwGameAnim(), Frames(NULL) {} virtual ~CIwGameAnimImage() { Release(); } void Release(); CIwGameAnimImageFrame* getCurrentImageFrame() const { if (CurrentFrame >= 0) return Frames + (int)CurrentFrame; return NULL; } void setFrameData(CIwGameAnimImageFrame* frames, int count) { Frames = frames; FrameCount = count; } };

The class itself is very basic, it allows you to set the frame data and number of frames using setFrameData() and get the current frame using getCurrentImageFrame(). We will take a look how to use this class a little later on.

CIWGameAnimFloat and CIwGameAnimFVec2 will be discussed in more depth in a separate article that deals with animating in-game objects.

Managing Animation Frames – CIwGameAnimFrameManager

Once we begin building our game we are going to end up with many animations of a variety of types, animating images, paths for objects, spinning slick user interfaces and so on. It’s usually a good idea to have some class that can oversee the creation and tracking of this kind of information. In this case we use the CIwGameAnimFrameManager to help us create blocks of animation frames

This class provides us with the following functions for allocating blocks of frames:

float* allocFloatFrames(int count);
CIwFVec2* allocFVec2Frames(int count);
CIwGameAnimImageFrame* allocImageFrames(int count);
CIwGameAnimImageFrame* allocImageFrames(int count, int frame_w, int frame_h, int start_x, int start_y, int pitch_x, int pitch_y, int image_width);

The second version of allocImageFrames() is a helper method that will auto-generate a group of image animation frames for a sprite atlas. The parameters are:

  • count – Number of frames to generate
  • frame_w, frame_h – Width and height of each animation frame
  • start_x, start_y – Upper left hand corner of first animation frame
  • pitch_x, pitch)y – The horizontal and vertical spacing between frames
  • image_width – Width of the sprite atlas

Managing Animations – CIwGameAnimManager

It would be great to be able to just create a bunch of animations and have something to automatically update them all for us without having to track each one individually, this is where CIwGameAnimManager comes in. CIwGameAnimManager allows us to add a bunch of animations to it and the manager will manage the updating and cleaning up of the animations and all of their frames for us.

It would also be cool if we had an object that had a collection of different animations that it could play to depict it doing different actions, such as running, walking, sleeping, falling etc.. CIwGameAnimManager allows us to add all of these animations and then select which animation is the currently active animation. Switching animations will stop the current animation and set the next one off playing.

The default behaviour of a freshly created CIwGameAnimManager object is to update all animations within the manager and not just the currently playing animation. To switch the manager into tracking and playing only the current animation call setUpdateAll(false).

What’s changed in the example code

Note that our project is now called IwGame and future game engine examples will retain this name.

If you build and run the IwGame project you will see 100 sprites spinning around on the screen, but the difference will be that the sprite is of a face animating manically,.

IwGame Marmalade SDK Tutorial Example
IwGame Marmalade SDK Tutorial Example

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

In terms of assets, we now have a single sprite atlas containing all of our sprites called sprites.png located in the data folder. We have also updated our Leve1l.group group file to include just the sprites.png file into our deployment archive.

We have added four new files to our MKB file:

  • IwGameAnim.cpp
  • IwGameAnim.h
  • IwGameUtil.cpp
  • IwGameUtil.h

IwGameAnim contains our new animation classes, whilst IwGameUtil contains a collection of utility classes, types and constants. The only class we really use from IwGameUtil is the CIwGameTimer, which is a software based polled timer that allows us to time events. We use this to delay the start of animations in the animation system. We also use the CIwGameCallback to define a callback function, although we are not using callbacks in this example, we will use them in the future to activate events such as sound playback

And without further ado, lets take a quick look at Main.cpp to see whats changed:

The first thing is the inclusion of the IwGameAnim.h header file

The next thing is the removal of loading test1 and test2 resources and the addition of loading our sprite atlas sprites.png instead:

CIw2DImage* sprites_image = Iw2DCreateImageResource("sprites");

The next change is the creation of our animation frames and the animation itself:

// Create an image frame manager (manages allocation of our animation frames) CIwGameAnimFrameManager* anim_frame_manager = new CIwGameAnimFrameManager(); // Auto create a 8 frames of animation 36x40 pixels in size CIwGameAnimImageFrame* anim_frames = anim_frame_manager->allocImageFrames(8, 36, 40, 0, 0, 512, 40, 512); // Create and set up our face animation CIwGameAnimImage* face_anim = new CIwGameAnimImage(); face_anim->setFrameData(anim_frames, 8); face_anim->setLooped(-1); face_anim->setPlaybackSpeed(-0.1f); face_anim->Start();

Its not a complex piece of code, just a bit wordy. Firstly we create an animation frame manager which in turn lets us create actual animation frames. In this case we use the helper method allocImageFrames() to generate the 8 frames manic head animation from our sprite atlas.

Next we create the actual image animation, set its animation frames, tell it to loop forever and then finally set it off playing.

The next change is a bit sneaky, I had to make a few upgrades to the IwGameSprite class to allow it to render portions of a larger image, more on that in a sec. In our loop where we create 100 sprites we now set the destination size (on screen size with no scaling) explicitly:

sprite->setImage(sprites_image); sprite->setDestSize(36, 40);

We also only have to assign one texture to every sprite (this will speed up rendering as texture swapping no longer occurs when drawing two sprites with different textures)

If we now move to the main loop and take a look at our sprite update code:

for (CIwGameSpriteManager::Iterator it = sprite_manager->begin(); it != sprite_manager->end(); ++it, speed++) { // Set sprites rotation (*it)->setAngle((*it)->getAngle() + speed); // Set sprites source rectangle from its current animation frame CIwGameBitmapSprite* sprite = (CIwGameBitmapSprite*)*it; sprite->setSrcRect(anim_frame->x, anim_frame->y, anim_frame->w, anim_frame->h); }

You will notice that we now set the sprites image source rectangle (this is the rectangular area of the source image that will be displayed on the sprite), this data is pulled directly from the animation system for the animations current frame.

We then update our animation:

// Update animation face_anim->Update(1.0f);

Note that we didn’t actually place our animation inside a CIwGameAnimManager, so we call the animations Update() method manually.

And finally outside our main loop we clean up our animation data using:

// Cleanup animations if (face_anim != NULL) delete face_anim; if (anim_frame_manager != NULL) delete anim_frame_manager;

The animation system is a chunky bit of code that may take a while to absorb for some of you at the moment, but it will become apparent over the coming weeks just how to utilise it as we plan on using it quite a lot.

Changes to IwGameSprite

I found whilst adding the animation system into the latest example code that our robust sprite class needed to be a little more robust. CIwGameBitmapSprite needed support for drawing areas of of images rather than the whole image. We replaced the previous rendering code with:

int x = -(Width / 2); int y = -(Height / 2); Iw2DDrawImageRegion(Image, CIwSVec2(x, y), CIwSVec2(Width, Height), CIwSVec2(SrcX, SrcY), CIwSVec2(SrcWidth, SrcHeight));

This code calls the Marmalade SDK Iw2D function Iw2DDrawImageRegion() which allows us to draw a rectangular portion of a source image instead of the whole thing.

Note that we use absolutely no object pooling in any of these classes, but we will be adding it in the near future. I left it for now because the code is already quite complex in its current state.

Well that’s it for this tutorial. Our next tutorial will introduce Scenes and Actors where we get to tie our animation and sprites systems together into a core game engine that we can make some cool games with.

You can download the code that accompanies this article from here.

Hope you all find this blog useful and until next time, don’t forget that…., hmmm I forgot!