IwGame Engine v0.28 Released – Box2D Physics Integration has Arrived

Posted on by drmop

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.

IwGame Game Engine Update

The magical elves of Pocketeers Land have been incredibly busy hammering out the latest update to the IwGame game engine and here it is. We’ve had a lot of requests for Box2D integration so we shunted it in there and managed to integrate it into the XOML mark-up language as well.

Here’s the list of changes for IwGame 0.28:

  • Image, resource group and timeline managers have been collapsed into a single resource manager. All calls to scene and global resource managers should go through getResourceManager()
  • All resource types can now be marked as managed
  • New Box2D IwGame classes added
  • Box2D integrated into the scene, actor system as well as XOML. Box2D can be disabled by undefining IW_GAME_BOX2D in IwGameBox2d.h
  • New shape system added IwGameShapes that allows you to define box, circle and polygon shapes, also available in XOML
  • XOML tag names and attrbutes are now case insensitive
  • Scenes XOML now supports Gravity and WorldScale
  • Actor XOML now supports new tags Box2dMaterial, Shape, COM (centre of mass), Sensor and CollisionFlags
  • Timelines can now be shared across different actors and scenes without them playing back too fast and not updating properly
  • CIwGameActor now has a new mthod removeVisual() which removes the actors visual from the scenes visual sprite manager
  • ToLower() and ToLower() methods added to CiwGameXml. These methods will convert all tag name and attribute names to lower or upper case (values are left untouched)

Yes, we did go ahead and remove all of the different types of managers and rolled them into a single resource manager. We also got rid of case sensitivity for tag and attribute names, which should save many of you the pain of tracking down case issues when writing XOML. I for one welcome the change 🙂

I was playing with time lines yesterday and discovered that if I attached the same one to more than one object, it got updated multiple times during a single frame, which causes the animationto play back too fast. A fix has now been added for that, so time lines can now be re-used across multiple actors and scene.

Now on to the meatier changes

Box2D Integration in Detail

Ok, so Box2D integration requests approached critical mass so we went ahead and integrated Box2D into the engine and the XOML system. The tst bed now shows anew scene (GameScene3) which has a solid floor, 2 walls and a bunch of actors that are dropped into the scenes. As you can see from the tst bed the physics is working pretty well. Lets take a quick look at the Game3Scene in XOML:


    <Scene Name="GameScene3" CanvasSize="320, 480" FixAspect="true" LockWidth="false" Colour="255, 255, 255, 255" AllowSuspend="false">
        <Box2DMaterial Name="Solid" Type="static" Density="1.0" Friction="1.0" Restitution="0.1" />
        <Box2DMaterial Name="BounceyBall" Type="dynamic" Density="1.0" Friction="0.9" Restitution="0.6" />
        <Shape Name="PlayerShape" Type="box" width="60" height="60" />
        <Shape Name="Wall" Type="box" width="20" height="320" />
        <Shape Name="Floor" Type="box" width="320" height="20" />
        <Timeline Name="Player1Intro1" AutoPlay="true">
            <Animation Anim="PlayerImageAnim" Target="SrcRect" Repeat="0" StartAtTime="1"/>
        </Timeline>
        <TestActor Name="Floor" Position="0, 200" Size="320, 20" Angle="0" SrcRect="0, 0, 32, 32" Image="Block" Shape="Floor" Box2dMaterial="Solid" CollisionFlags="1, 1, 1" />
        <TestActor Name="LeftWall" Position="-140, 0" Size="20, 480" Angle="0" SrcRect="0, 0, 32, 32" Image="Block" Shape="Wall" Box2dMaterial="Solid" CollisionFlags="1, 1, 1" />
        <TestActor Name="RightWall" Position="140, 0" Size="20, 480" Angle="0" SrcRect="0, 0, 32, 32" Image="Block" Shape="Wall" Box2dMaterial="Solid" CollisionFlags="1, 1, 1" />
        <TestActor Name="Player1" Position="-50, -200" Size="60, 60" Angle="0" SrcRect="0, 0, 36, 40" Image="Sprites" Timeline="Player1Intro1" Shape="PlayerShape" Box2dMaterial="BounceyBall" CollisionFlags="1, 1, 1" />
        <TestActor Name="Player2" Position="0, -150" Size="60, 60" Angle="0" SrcRect="0, 0, 36, 40" Image="Sprites" Timeline="Player1Intro1" Shape="PlayerShape" Box2dMaterial="BounceyBall" CollisionFlags="1, 1, 1" />
        <TestActor Name="Player3" Position="50, -200" Size="60, 60" Angle="0" SrcRect="0, 0, 36, 40" Image="Sprites" Timeline="Player1Intro1" Shape="PlayerShape" Box2dMaterial="BounceyBall" CollisionFlags="1, 1, 1" />
        <TestActor Name="Player4" Position="0, -1000" Size="60, 60" Angle="0" SrcRect="0, 0, 36, 40" Image="Sprites" Timeline="Player1Intro1" Shape="PlayerShape" Box2dMaterial="BounceyBall" CollisionFlags="1, 1, 1" />
    </Scene>

In the above XOML scene we declare two materials, one for our solid environment pieces (floor and walls) and then another for our bouncy players.

Next we define a shape for our player, a shape for our floor and s shape for our walls.

Lastly, we create actors that represent our floor, left wall, right wall and 4 player actors, assigning the correct shapes and materials.

The above creates a scene with animating interactive physics objects

Box2D integration will be expanded in future updates to more features to IwGame and XOML.

If you want to learn more about the internals of the Box2D integration then take a look at the IwGameBox2D source files.

Shapes in XOML

You now create shapes in code or by using XOML mark-up. Take a look at the new shape classes in IwGameShapes.h. Below is an example showing a few shapes defined in XOML:


    <Shape Name="PlayerShape" Type="box" width="60" height="60" />
    <Shape Name="AlineShapel" Type="circle" radius="20" />
    <Shape Name="Platform1" Type="polygon">
        <Point Value="-100, -100" />
        <Point Value="-100, -200" />
        <Point Value="100, -100" />
        <Point Value="100, 100" />
        <Point Value="-100, 100" />
    </Shape>

Shapes can be used to define physical collision boundaries for the integrated physics system. Eventually IwGame’s new path system will utilise shapes (when its implemented)

New Resource System

The new resource system now handles all resources of any type, so all the old separate resource managers have gone. To ensure that developers do not have to be too careful with naming resources, different resources can share the same name. However, this does mean that when you ask for a resource you do need to specify its type. Here’s a few examples:

CIwGameImage* image = (CIwGameImage*)IW_GAME_GLOBAL_RESOURCES->getResourceManager()->findResource(“Sprites”, “Image”);
CIwGameAnim* animation = (CIwGameAnim*)IW_GAME_GLOBAL_RESOURCES->getResourceManager()->findResource(“PlayerImageAnim”, “Animation”);

Note that the 2nd parameter specifies the type of resource, in this case it is an Image and an Animation.

Valid type names are as follows:

  • Game – Game objects
  • Scene – Scene objects
  • Image – Image objects
  • Timeline – Animation timeline objects
  • ResourceGroup – Resource group objects
  • Animation – Animation objects
  • Shape – Shape objects
  • Box2dMaterial – Box2D material objects

This does not include any of your own custom types that you add to the system yourself.

Well, that’s it for this update. We are very likely moving onto creating the editor to accompany the engine as our next task so IwGame engine updates may come a little slower.

16 thoughts on “IwGame Engine v0.28 Released – Box2D Physics Integration has Arrived”

  1. Mat,

    Great update with tons of new features.

    One issue I am having with the update is that my code relied on getting the width and height of the background images to set boundaries and camera limits. However, I am unable to find a way to call the image’s getWidth() and getHeight().

    Other than that thanks for the work each new update brings so much more to the engine 🙂

    Thomas

  3. The resources in Common.xml are global (because they are not declared inside a scene) so they can be referenced from IW_GAME_GLOBAL_RESOURCES. Hers an example showing how to find the “Sprites” image:

    CIwGameImage* image = (CIwGameImage*)IW_GAME_GLOBAL_RESOURCES->getResourceManager()->findResource(“Sprites”, “Image”);

    Note that the 2nd parameter specifies the type of resource, in this case it is an Image.

    Type names are as follows:

    Game – Game objects
    Scene – Scene objects
    Image – Image objects
    Timeline – Animation timeline objects
    ResourceGroup – Resource group objects
    Animation – Animation objects
    Shape – Shape objects
    Box2dMaterial – Box2D material objects

    You can still get the width and height of an image, you just need to ensure that it is loaded firstly. You can force images to be preloaded by specifying Preload=”true” in the resource group definition.

    You can check the loaded state of an image by calling getState(). If the state is equal to CIwGameImage::CIwGameImage_State_Loaded then you are ok to query and use the image.

    Glad that you are pleased with the new changes. We’re starting the editor to accompany the engine very soon so updates to IwGame may come a bit slower for a while.

  4. Thanks for the reply. I realized my mistake by not setting up a CIwGameImage* with image. I tried to use (CIwGameImage*)IW_GAME_GLOBAL_RESOURCES->getResourceManager()->findResource(“FloorImage”, “Image”)->getWidth(). I got everything to work now, thanks.

    It will actually be good to get IwGame updates slower because with each new update, especially with the Xoml one, I’ve been replacing and upgrading all my coding.

    What do you have in store with the editor? I look forward to it 🙂

  5. Glad to hear that you sorted it.

    Yep, sorry about the speed of updates, the engine has been pretty much in a state of flux, but I believe its feature rich and hopefully stable enough to start using in game products now.

    The editor will basically mirror XOML, creating a usable interface to facilitate creating XOML easier. XOML will likely evolve along with the editor features, for example, we have plans to add events definition and triggering, such as an OnTapped event on an actor can open up a new scene or play a sound effect. We want to enable the production of interactive scenes without any need for coding so that media developers can put together full media products with little effort. We are trying to avoid scripting languages, so not sure if it would be possible to eventually create a full on game using just the editor.

    Short term we want the editor to enable production of scenes with custom actors, set up animations, physics, shapes etc.. and collate resources. basically something that will greatly simplify game production.

  6. Awesome. That sounds like a very useful addition to the engine. I like that you will add event handling, since all my touch events have been with an invisible actor that follows the location of the user’s touch.

    Keep up the good work Dr Mop! 🙂

  9. Hey Mat,

    First I want to thank you for the removeVisual() function. It is really useful for my coding and has solved the overlapping problem that I discussed with you before.

    I am having some trouble with my code unfortunately. Everything was going well until I realized that my game kept crashing after about of minute of using the simulator. After looking around, I found that my game kept consuming a huge amount of memory until the game crashed.

    After some debugging, I realized that there was a huge flaw in my update loop that was causing this excessive use of memory. At the start of the loop, I basically create a bunch of general sprites for use in every level.

    For example, CIwGameBitmapSprite* Floortile = new CIwGameBitmapSprite();

    In order to change the tile visuals at different levels, I basically change the image of the bitmap sprite with another one that is loaded in the global resource group. However, since the update keeps repeating, I believe new bitmap sprites are created constantly, which is filling up the memory.

    I could solve this by creating every bitmap sprite that I need as a global variable in the game.h, but that seems like it would impractical.

    What I would like to do is add the sprite into the global resource manager(which I can’t seem to do since it only takes IIwGameXomlResource* and not BitmapSprites*). Is there a way to do this or another solution that could help me create a sprite once and access that sprite in the update loop? Thanks for your help and hope everything is going well 🙂

    Thomas

  10. I just wanted to let you know that I switched everything to global variables and it seems to work without devouring the memory. If there isn’t a better solution, I will stick with this 😀

  12. Let’s say that I want to change the sprite visual of an existing actor. For example if a button is pressed by the user, I would want the image of the actor to change. The setVisual() function only takes CIwGameSprites* and therefore I need access to the sprite I want to change it to. The only two options I seemed to be able to use was either create the sprite in the game update loop or as a global variable in game.h so that the update loop will have access. However as I have said by creating a spriet in the update loop, memory kept getting filled. Is there a way to create a bitmap sprite in a xml file to retrieve. Thanks

  13. The best way is to change the image that a sprite shows using something like:

    ((CIwGameBitmapSprite*)actor->getVisual())->setImage(your_new_image);

    Or a much better way would be to store all of the button images as one large bitmap then change the sprites source position using for example:

    ((CIwGameBitmapSprite*)actor->getVisual())->setSrcRect(0, 0, 32, 32); // Button image 1
    ((CIwGameBitmapSprite*)actor->getVisual())->setSrcRect(32, 0, 32, 32); // Button image 2

  14. That’s what I wanted to do with the current visual of the actor in a scene – that is change its current visual instead of replacing the visual. However for some reason whenever I get the visual in a scene by using this code:

    Level2Scene->findActor(“FloorTile”)->getVisual()->

    There is no function setImage() that I could use to allocate the image. Do I need to call the actor in the same way as you did it above? By using (CIwGameBitmapSprite*) before the actor? If there was a function setImage, there would be no need to create the sprites, since I could just create the images in the xml files and allocate them to the actors visuals! Thanks

  15. Yes, you can cast the returned actor visual to a CIwGameBitmapSprite and then access setImage() etc..

    The base CIwGameSprite class does not contain setImage() as its a generic base class that can be used to derive sprites of any kind. For example, we may want to derive a sprite that is text based or a vector graphic etc..

Leave a Reply