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.
Well, Dan said a few weeks ago that “it’s only until you eat your own dog food that you know you have to improve the taste of it”. I thought about this and decided that we really needed to create a game using the engine to show its various features in action. So with this, I began work on a game (currently unnamed), but decided that the game would take a few weeks to finish off, so moved over to producing a completely new game from scratch but with a simpler design. The end result was a game that was created in less than 36 man hours, including art production, coding, design and scripts (I was aiming for 24 hours but I came across a a few nasty bugs that took a fair bit of time to fix). In addition,. I underestimated how difficult it would be to put levels together without an actual editor. I will very likely build an actual editor into the cOnnectiCons game itself to allow players to create their own levels. So the game ended up with 20 levels, with an additional 20+ levels coming later.
You can take a quick look at cOnnecticOns at http://www.youtube.com/watch?v=sVa8TWYQEsQ and here are a few screen shots of our 36 hour game cOnnecticOns:
Connecticons screen shot
Connecticons screen shotConnecticons screen shot
Connecticons screen shot
We have already started submitting the game to app stores, so when we release the source “Don’t go getting any ideas lol”. The source will be provided as a learning exercise, and not for someone else to make a quick buck off.
Ok, now that’s out the way, lets take a brief look at the changed that have arrived in IwGame v0.3:
- Support added for particle based actors via CIwGameActorParticle and CIwGameActorParticles as well as XOML via ActorParticles and Particle tags. Particles can be defined individually or in batches using random parameters. Particles have position, linear velocity, angular velocity, scale velocity, colour velocity, depth velocity, velocity damping, lifespan and repeat
- Support for Marmalade fonts has been added via CIwGameFont wrapper and a new XOML Font tag
- All rendering now uses IwGx instead of Iw2D. This offers more control over rendering as well as makes the code more portable / versatile in the future
- All internal rendering upgraded to sub pixel coordinates offering MUCH smoother rendernig
- New 2D rendering class added CIwGameRender2d. This cklass allows batch rendering of primitives and rendering of text CIwGxFontPreparedData prepared text
- New very powerful template system added to XOML. The template system allows you to create a complex piece of XOML using paramaters that can be passed in when the template is instantiated. Templates can also be instantiated from code using CIwGameTemplate::Instantiate()
- CIwGame::addScene() can now auto bring a scene to the front of scene stack
- New global actions added to XOML – Launch, setBGColour, SetCurrentScene and BringtSceneToFront
- Actors and sprites now have a depth property allowing you to add 3D depth to them
- Actors and sprites now have an origin attribute
- Support added for sprites and actors for none uniform scaling
- Support added for linked actors. A linked actor will utilise the transform, colour and visibility of the actor it is linked to. In XOML, you can use the new LinkedTo tag to set linkage or the more natural and readable method of defining actors within actor tags. This system allows complex multi-patr actors to be created and animated
- Actors now support OnCreate and OnDestroy events in code and in XOML
- Scenes now support OnCreate, OnDestroy OnGainedFocus and OnLostFocus events in code and in XOML
- New text based actor and sprite types added CIwGameActorText and CIwGameTextSprite.
- Animation system now supports linear, quadratic, cubic and quartic on / out easing in code and in XOML. In addition value interpolation can be enabled / disabled
- Animations now support absolute and delta values
- Animation timelines now support OnStart, OnEnd and OnRepeat events in code and in XOML
- CIwGameAudio::PlayMusic now supports repetition with additional parameter in XOML
- New CIwGameSlotArray class added for efficient resizable arrays
- Actor Box2D collision system was broken and inefficient. The system has been completely reworked and now uses the new more efficient CIwGameSlotArray
- CIwGameBox2dBody now has new awake and active methods
- CIwGameCamera now supports velocity, damping and touch panning. Touch panning will pan the camera to follow the users finger
- More than one scene can now receive input events using the new AllowFocus functionality in code and in XOML
- New findClosestActor and findFurthestActor methods added to CIwGameScene
- CIwGameBitmapSprite now supports colour per vertex
- CIwGameSpriteManager supports enabling / disabling of batching and a new centre of projection property for depth used by depth sprites
- CIwGameInput reworked to better support multi-touch
- PlayTimeline, StopTimeline and SetTimeline now supports a second parameter which points to the scene or actor that the timeline change should be made to
- Actors can now be marked for hit testing in XOML
- Image files can now be loaded directly from XOML without the need for Marmalade resources files
- CIwGameScene and CIwGameActor based objects are now marked as destroyed when they are removed so they cannot be found in a scene or actor search
- CIwGameXmlNode now supports cloning
- Bug Fix: Actors now take into account their visibility when being hit tested
- Bug Fix: CIwGameActor::setCollidable no works
- Bug Fix: StartTimeline action now restarts a stopped timline properly
- Bug Fix: Clipping rect is now transform by the scenes transform (will not clip correctly against rotated scenes however)
- Bug Fix: XML parser fixes
- Bug Fix: CIwGame game scene switch scene bug fixes
- Bug Fix: CIwGameAds::ErrorFromResponse fix that were causing some valid ads to be in error
- Bug Fix: CIwGameAnim fixes
- Bug Fix: Polygon based Box2D bodies now fixed
- Bug Fix: Sprite rendering transform fixed
- Bug Fix: CIwGameBitmapSprite with no loaded image no longer crash
- Bug Fix: CiwGameString crashes fixed (were causing rare problems with XML system)
- Bug Fix: Fixed issue with CIwGameXmlAttribute::GetValueAsColour not checking for correct parameter count
- Bug Fix: On device scene shut down camera deletion fixed
Ok, that’s a shed load of changes, but I can assure you that they are all for the better. IwGame is now a professional grade and fairly stable engine that can be used to create games in as little as 36 hours!
Lets take a look at some of the new additions in more detail.
Templates
I want to start with my utmost favourite change to 0.3 which is templates. I am so in love with templates that I feel like I could almost marry one! They saved me so much time when developing cOnnecticOns. Templates allow you to create large sections of XOML as templates then instantiate those large
pieces of XOML somewhere else using custom parameters that you pass to the template when you instantiate it. Lets take a quick look at a super simple example:
<Template Name="ActorTemplate">
<InertActor Name="Explosion$name$" Image="$image" Position="$pos$" Scale="$scale$" Depth="$depth$" Layer="1" AngularVelocity="0" />
</Template>
Here we define a template called ActorTemplate that contains a basic InertActor definition. You may notice some strange markers in there surrounded by double dollars signs ($name$, $image$,$pos$, $scale$ and $depth$).
Now when we instantiate this template somewhere we would use:
<FromTemplate Template=”ActorTemplate” name=”actor1″ scale=”1.0″ pos=”300, 150″ depth=”1.0″ image=”sprites1″ />
The above XOML command will instantiate whatever is in the ActorTemplate template passing all of its parameters, replacing the double dollar definitions inside the template (Hmm, sounds very much like calling a function? Which I guess in some ways it is)
Templates can be as massive and as complicated as you like, allowing you to design and instantiate some very complex objects with very few lines of XOML.
Rendering Engine Upgrade
Up until version 0.29 of the IwGame Engine we used Marmalade’s Iw2D engine as the rendering core. As of v0.30 we have switched to Marmalade’s IwGx rendering system as it offers much more versatility as well as brings the engine into the realms of 3D rendering, which is where we will eventually be steering the engine.
To facilitate this change over and to keep the game engine code nice and readable, all rendering has been abstracted away into a nice simple class called CIwGameRender2d. CiwGameRender2d is and will in future be the centre point for all rendering that takes place within IwGame.
At the moment CiwGameRender2d offers:
- Batch and none batch sprite rendering of quad based polygons
- Rendering of prepared text from the Marmalade IwGxFont system
In the near future we will be adding support for various other types of primitives, 3d models and hopefully our own custom shaders etc..
Lastly, all rendering now uses sub-pixel accuracy which looks much much smoother.
Text and Fonts
IwGame now supports definition of Marmalade fonts and custom rendering of those fonts using a new text based sprite and actor. Text based sprites and actors are treat just like any other sprite or actor objects, so they can be spun, scaled, linked, colour changed etc.. Unlike generic actors text based actors can be instantiated without deriving your own class from CIwGameActorText
3D Sprites / Actors
Another one of my favourite additions to 0.3 is 3D sprites. All sprites and actors can now have a depth value (think iof this as a z value) that allows you to project sprites into 3D. This system is great for create parallaxing effects etc..
Oh and sprites / actors also get an adjustable origin and none uniform scaling
Linked Actors
Actors can be created within other actors to form a parent / child relationship. Inner actors will be linked back to their containing actor forcing them to be transformed by their parent actors. This system allows you to create a very powerful intuitive multi-part actor system complete with animations per actor part. Note that all positions, depths etc will be relative to the container actor, so for example, if the parent actor has a Depth value of 1.0f and the child actor has a Depth value of 1.0f then the child’s effective Depth will be 2.0f. Here’s an example showing parent / child actors:
<InertActor Name="Level1" Style="LevelButtonStyle" Position="0, 0" OnBeginTouch="BeginTouch11" OnTapped="StartLevel1">
<ActorText Name="Record1" Style="LevelButtonTextStyle" Colour="255, 80, 80, 255" Position="0, 0" Text="0" Depth="0" />
<ActorText Style="LevelButtonTextStyle" Position="0, 60" Text="Round 1" Depth="0" />
<InertActor Name="LevelComplete1" Size="74, 67" Image="sprites2" SrcRect="582, 423, 148,134" Position="60, -20" HitTest="false" Depth="0" Timeline="tick_scale_anim" />
</InertActor>
In the above XOML the parent actor level1 contains three children actors that will all follow theLevel1 actors visual transform.
Particle System Actors
This actor is special in that it is optimised for creating, displaying and updating a complete system of sprites (kind of like its own sprite manager). The advantage of this actor is that it does not have to deal with each particle as a separate actor object. The CIwGameActorParticles actor supports both manual and auto generation of particles. Auto generation can be controlled using a number of a control parameters.
Particles have a number of properties that can be adjusted:
- Visual
- Position
- Velocity
- Velocity Damping
- Gravity
- Scale
- Scale Velocity
- Scale Velocity Damping
- Angle
- Angle Velocity
- Angle Velocity Damping
- Colour
- Colour Velocity
- Colour Velocity Damping
- Depth
- Depth Velocity
- Depth Velocity Damping
- Active state
- Visible state
- Lifespan – Duration of particle in seconds
- SpawnDelay – The amount of time to wait before spawning for the first time
- Lives – Number of times the particle will re-spawn (-1 for infinite)
The particle actor system allows auto generation of particles within certain limits as well as manual generation. Patricles can be defined and placed both in code and in XOML.
Animation Frame Easing
Animations now support in and out easing on a per frame basis using the “Ease” attribute of the frame tag or in code. Valid values of easing include:
- linear – No easing
- quadin / quadout – Quardatic in / out easing
- cubicin / cubicout – Cubic in / out easing
- quarticin / quarticout – Quartic in / out easing
Time lines now in the Events System
Its now possible to attach actions to timeline events such as OnStatr, OnEnd and OnRepeat. So for example, each time an animation repeats you could play a sound effect or maybe when an animation finishes yu kill destroy the actor or start a particle system off going etc..
Animations now support delta / absolute coordinates
Every animation can now be specified as absolute or delta. An absolute animation will write its interpolated frame values directly into the target objects properties (such as position), whilst a delta animation will update the current target properties. So for example, a delta animation for position would adjust the position by dx, dy, where dx and dy is the current interpolated frame value.
Automatic Touch Panning for Cameras
Cameras now have X and Y axis touch panning. When a camera is touch pan enabled it will track the users finger drag on screen to determine a velocity to move the camera by. Touch panning can be enabled on the X an Y axis independently.
Other cool changes
Multi-focus scenes – More than one scene can now receive input events
Local images can now be loaded from XOML
There are many other changes but I don’t really have the time to go through them all. There’s also a mound of bug fixes that weer found during development of cOnnecticOns.
We will be releasing the full source to cOnnecticOns later this week along with an additional 10-20 levels.
Wow Mat,
You have been excessively busy there. The changes sound awesome, and I wish i was not so far along in all my Developments. I think if i was starting again I would just use this excellent engine.
Looking forward to trying your new game of course, and it lokos like the wife might like this one as well.
good luck.
Da Voodoochief
Hey Mat, looks like we are going to start eating some fine cooked meals from now on. 🙂
I think this is indeed Professional grade engine, not only the code but also the documentation. Kudos!
I will look at the source and hopefully will start using the engine for development, now that it has reached a mature state and there won’t be critical breaking changes… let the games begin!
Its been a busy time, just glad its out the way now. I really feel the engine is now ready for mass production of 2D games by everyone.
I’m going to off creating levels for this connecticons game then move back onto my previous game and get that finished. Will release the source to connecticons as soon as its tidied up enough. Will also put a quick blog together as a bit of an overview of the games development.
I think that it may be a month or so before I release 0.31 as I have quite a lot to do over the next month or so, that is unless something urgent comes up.
Now, lets all make some money 🙂
Quik marmalade issue… I am deploying the usual TestBed that comes with the new code to the Android Emulator, and I think the app.icf file is missing the “MemSize fix”, also it complained about T-Pages, so I doubled that to 32.
Added the following to app.icf
[S3E]
MemSize=16485760
[GX]
NumTPages=32
just in case anyone runs into similar trouble. (Oh Marmalade you make me jump so many hoops).
Wow, amazing update! I look forward to messing with all the new different features! Thanks for the hard work!
Thomas
Mat,
Great work! Congrats.
Now its time for us to be busy 😉
Can’t wait to port my code to this new release.
Cheers,
Criss
Wow I just saw the youtube video for your cOnnectiCons (btw awesome name!) and I think that this can be a really good game. The game appeal is similar to the most popular games such as cut the rope and I think it can be great if you can especially create a iconic face character (like the iconic angry birds) that responds to collisions. Good luck with the app in the store and hope it is successful!
I agree, giving character to the faces would be good, although I spent only around 12 hours on producing the art work for the game, being a programmer, my animation skills are a bit limited. I will have a chat with our art guys, see if they can come up with something.
Right now I’m building a level editor into the game, primarily so I can more easily create levels, but I may ship the editor with the game.
@Mat – hats off! Some real good work right there! Thanks for supporting the community by eating your own dog food 🙂
@Dan – Why does it need T-Pages? Are you using SW rendering mode (or HW & SW)? IF you are not targeting old Android phones or Bada WQ, use only HW mode to save memory, in fact, it’s better to have 2 separate builds for HW and SW…
I think, your MemSize is a bit too big, it’s better to stay under 10Mb (ideal 8Mb), you may need to start splitting your resources into smaller files and load them on demand… Avoid placing big images in Marmalade resources (like background), keep them separate (load PNG on demand).
Just to add, you can now load local images directly from XOML, no need to put them into a Marmalade resource group:
<Image Name=”Background” Location=”title_bg.png” Preload=”true” />
@GameAmour: The emulator uses only SW rendering (afaik), that is the reason it is complaining about T-Pages. The TestBed example will not run with MemSize < 10Mb that was the default. These settings are for the emulator, for Actual deployment it's better to profile and HW test it.
I just posted that for people that may want to test it on the Android Emulator, most people will figure it out, since the error descriptions are already pretty clear.
@Mat: yeah I like that a lot! Just wish we could add all resources like that. Is there any way that we can have a XOML resource manager… Ill look at how you parse the Image and try to figure it out for myself, but being able to load asset packs via XOML would be really Sweet!
At the moment, you can load other XOML files using:
<LoadXOML File=”PauseMenu.xml” />
Or via an action:
<Actions Name=”GoBack”>
<Action Method=”KillScene” Param1=”CompleteBackgroundScene” />
<Action Method=”KillScene” Param1=”CompleteButtonsScene” />
<Action Method=”LoadXOML” Param1=”Menu.xml” />
</Actions>
Although it would be good to add a XOML type to the resource manager so they can be accessed as resources.
Mat,
Thank you for fixing HitTest it works now. However, I am having an issue with user input. Since the visual for an image is the rectangular sprite, images that are not a rectangle and have a transparent background for the remaining portion of the rectangle’s sprite HitTest when the background is clicked. For example, if I have a arrow button, touching the corner of the sprite box, which is transparent and has no image of the arrow will trigger the actions. Is there a way to create a collision or tappable area that can create a polygon HitTest or collision area? Do I need to change the image format on my end or create my own function to do that?
Also I was thinking about your cOnnecticOns game and the faces and I think it would be a cool feature if different faces would set the velocities of the faces at different speeds. For example, a angry face could move at a faster velocity versus a sad face. Maybe some even cooler faces could have more features. This would make the game more dynamic.
Hi Thomas. Unfortunately the hit test code is based on testing a point against the rectangular area of the sprite and doesn’t perform any pixel testing, this is something you would need to implement.
Thanks for the cOnnectiCons suggestions
Dan,
We use HW only with zero T-Pages and 8Mb memory limit as our default simulator setup – it works!
We do use the trick to have enough memory for Marmalade resource generation – we offload them to Debug memory bucket, and set that bucket to 20Mb.
Hi drmop,
I am trying to load a JPEG image thru XOML like this:
and it loads but when drawn on the screen, the color are mixed up, it looks like it is BGR instead of RGB or something like that. The problem shows on the simulator and on a real iPod touch too.
Hi Remz,
Just fixed it, I wasn’t converting from BGR to RGB. Will add the fix for 0.31, in the meantime you can apply the following code fix at line 304 of IwGameImage.cpp:
// Convert from BGR to RGB format
unsigned char* datap = data;
for (int t = 0; t < cinfo.image_width * cinfo.image_height; t++) { unsigned char b = *datap; unsigned char r = *(datap + 2); *datap = r; *(datap + 2) = b; datap += 3; }
@GameAmour
Ok run the TestBed on the Android Emulator and see if that works… Please send me logs/catlog and icf file.
Hi Mat,
Terrific job! Thank you for all your time and hard work. Don’t know about the dog food, but there’s plenty to chew on!
What I chewed on yesterday involves the new render method IwGx. The problem (I had a fix for Iw2D) is that my bitmaps are all different sizes. The animation frame sequencing assumes that bitmaps in a sequence are the same size. When you declare an actor, you set the “size” attribute. All subsequent bitmap frames in that sequence are mapped/scaled into that specified size, sometimes giving really whacky results. I need the bitmaps to render in their native, source size.
One of the best things about your tutorials has been working thru and learning the code, so I’m thinking that setting TransformDirty between the frame changes might be a solution. But we’re a long way from where we started (seems like a while ago, doesn’t it), and with the code methods now including Xoml handling, it takes a while to grasp all the nuances. Since you have the best overall perspective of how the engine works, I’m hoping you can come up with an easy solution. Meanwhile, I’ll keep working on it.
This may be a common problem as it’s fairly normal to have different size bitmaps, and sometimes have them rotated, so that more bitmaps can be placed on the sprite sheet.
Thanks again. Love the new features.
Keith
Hi Keith,
The ideal solution would be to arrange all of your sprite frames on a sprite sheet then animate the actors SrcRect property to animate the actor. The only issue would be getting the actors visual size to be the same size as the current animation frame.
If you want to manually update the actor to apply the new size etc then you can call:
CIwGameBitmapSprite* sprite = (CIwGameBitmapSprite*)Visual;
sprite->setSrcDest(0, 0, width, height);
This will set the sprites new visual size and texture size
Mat
Mat,
Thanks, I’ll try using that.
I’ve been animating as you suggest, and you nailed the problem exactly: How to change actor’s visual size to match the current animation frame. Iw2D has a draw method to do that, but I think IwGx is the way to go.
Let me chew some more.
I have some problems with creating ActorImages. I do something like here and the problem is that I always see one frame from (0, 0) coordinates of image, not the first frame of animation. I tried to do UpdateVisual but doesnt help. Am I missing something or it is a bug? How can I force to update the visual? I could even do get first frame from animation, and pass it as rect to Init method but I don’t know
Brick* brick = new Brick ();
CIwGameAnim *anim = (CIwGameAnim*)IW_GAME_GLOBAL_RESOURCES->getResourceManager()->findResource(“BrickAnimation”, CIwGameXomlNames::Animation_Hash);
CIwGameImage* image = (CIwGameImage*)IW_GAME_GLOBAL_RESOURCES->getResourceManager()->findResource(“sprites”, CIwGameXomlNames::Image_Hash);
brick->setScene(scene);
brick->Init(image, 80, 80);
CIwGameAnimTimeline* timeline = new CIwGameAnimTimeline();
CIwGameAnimInstance* brickAnim = new CIwGameAnimInstance();
brickAnim->setAnimation(anim);
brickAnim->setTarget(brick, “SrcRect”);
timeline->addAnimation(brickAnim);
brick->setTimeline(timeline);
timeline->play();
Just a second after sending previous comment I tried one more thing and added:
brickAnim->UpdateTargetOnly(brick);
Now it looks ok:)
Of course great work with new release! I like especially TextActors and LinkedActors features. Second one make it very similar to flash sprite:) Thank you Mat for your great work.
I see that BitmapSprite behavior has changed since 0.29. Earlier the position of camera doesn’t affect how the BitmapSprite looks on screen. Now I see that BitmapSprite is still in position (0,0) and method setPosition doesn’t do anything. Additionally it looks that initial color of BitmapSprite isn’t white, they look a little darker even if getColour gives white. If you are interest and can’t see it I can reproduce it with smallest amount of code as possible.
I also have a design question. If I have a manager to manage some actors should it be an actor also (but without a visual)? I have a problem cleaning up after managers (not actors yet) and still get messages about memory leaks when I close a simulator. I wonder how can I clean up it. I tried NotifyDestroy() in scene, but when I close simulator window it is not triggered.
Hi Mat,
Terrific update! I’ve a little question regarding Box2D collision testing.
In 0.29 I used to have in the update function (of my game class), a piece of code to check the collision started collection for an actor X. Using that collection, I was able to find out to which other actors the X actor collides. (I have sensor actors, as I need to manage myself the collision).
In 0.29 this code worked perfectly. I’ve upgraded 0.3, knowing that Box2D collision changed, I’ve managed to update the code to something like this:
CIwGameSlotArray<CIwGameBox2dCollidable*>& started = (X->getBox2dBody())->getCollisionsStarted();
for (int t = 0; t < started.getSize(); t++) {
CIwGameBox2dCollidable* collision = started.element_at(t);
CIwGameActor* collisionActor = (CIwGameActor*)collision->getUserData();
if (collisionActor->getNameHash() == CIwGameString::CalculateHash(“Y”)) {
// DO SOMETHING WITH THE COLLISION X vs Y
}
}
(X->getBox2dBody())->clearCollisionsStarted();
The problem is that the collisionActor is always NULL. I’ve assumed that the actor was loaded inside the user data on the collision started event. But I’m always getting a NULL value. Also, it seems as if the “started” collection always has values, even tough if we do not have a collision. All the Box2D collision flags, categories and groups are the same as 0.29 (where it worked). I’m missing something?? something new in 0.3?
I’ve seen in the documentation (in the Box2D collision section), that we have function ResolveCollisions() inside the actor, that does a code similar to the previous one. I’ve tried moving this code to ResolveCollisions, but using Box2D this function is never called by IwGame.
Well, thanks in advance for any help!
Bye
Pablo
Hi Mat,
Do you know when you’ll be releasing the source to cOnnecticOns? I think it might provide solutions to some of the problems I’m having, and I’m sure it would be useful to other developers as well.
Thanks,
keith
@Roman: The sprites position is included in the transform when the transform is rebuilt in CIwGameSprite::RebuildTransform(). Also the camera is adde to the transform mix in CIwGameSprite::TransformVertices(). Note that the sprite manager transform contains the camera and virtual screen transforms. I’m not experiencing any strange values for colours at this end during sprite rendering. Best bet is to put a break point in at CIwGameBitmapSprite::Draw() and check to see what values are being passed into the renderer. You can use an actor as a manager.
@Pablo: The previous version of collision was faulty and in-efficient so we replaced it. The functionality remains the same, but the way you access it has changed. Section 20.5 of the documentation covers how to check for collisions using CIwGameActor::ResolveCollisions() and respond to those collisions using CIwGameActor::NotifyCollision(CIwGameActor* other). Note that for an actor to be considered for collision it must be marked as collidable, a valid Box2D material / shape must be attached and Box2D collision flags must be set up. It won’t be long before the source for cOnnecticOns is made public so you can take a look at that when its available.
@Keith: Its going to be next week now, still trying to get the editor finished, had to move away from the project to sort some other things out.
Mat,
I’ve found the problem with my solution. I’m using Box2D to simulate the physics, but, I’m working with sensor objects. In order to detect the collision the way I’m doing it, I had to made the following change in IwGame, in the function CIwGameBox2dWorld::InitWorld,
void CIwGameBox2dWorld::InitWorld()
{
// create Box2D world
World = new b2World(b2Vec2(Gravity.x, Gravity.y), false); // Pass false to doSleep instead of true
// Set up contact collision listener callback (this gets called whever a collision occurs between two bodies)
World->SetContactListener(&g_CIwGameBox2dCcollisionCallback);
}
It would be nice to have the doSleep parameter as an attribute in the scene. (It is not there, no?)
After making that change, everything works flawlessly…
Thank you!
Pablo
Hi Pablo,
I’ve added the feature to CIwGameScene and XOML
Mat
Excelent!, thanks
Mat,
The only thing now missing is to host this bad boy on github, so you can do less work, like patching stuff, reading other people code/issues/bugfixes, etc… and have the additional feature of having a public issue tracker, no duplicate bugs and all the github goodness. 😀
Well wend you have some time during the weekend take a look at it, it’s easy to start using, and adapting your workflow to it.
Regards!
Hello Mat, amazing work you have here!
Started playing with IwGame this week and got a problem with the camera panning. It works great on the emulators, but it’s not working correctly on at least one android device i’am using for testing (SG II). Dragging works but when i stop touching the screen the camera immediately stops. I have done some debug and it looks that, when i stop dragging the finger, the drag.x in CIwGameScene::Update() is always 0. Any idea why this is happening only on the actual device while working perfectly on the emulators? May it be an marmalade issue?
Cheers,
@Dan: Not suire we are going to go by way of Github. IwGame has turned into something much larger than we had ever anticipated so we want to retain full creative control over its direction.
@spec: We use the users finger drag delta from one frame to the next to determine how much velocity to apply to the camera so drag.x will become 0 when you stop moving your finger. Maybe the cameras velocity damping is too low, try setting velocity damping to 1.0
Yes i understand, it’s weird because on the 1st frame after we remove the finger when we were doing a swipe drag shouldn’t be 0.
It actually works well on the emulators, just not on the device. I had a high value of damping (0.92) but tried 1.0 anyway with no avail. When i remove the finger the camera stops immediately. It’s weird that it work well both on the x86 and arm emulator and not on the device. I wonder if is an hardware problem, it would be great if someone with an android device could test it and give feedback. Just need to change one of the cameras of the testbed to have property TouchPanX=true.
Cheers,
I made font resource using Font Builder, with taking into account kerning, but when I build ActorText it seems not work.
@Mat: Can I then suggest you add a plugins in the form of forum and or issue tracker to your wordpress blog, so that the community that will effectively grow from now on, is able to communicate more efficiently than having to digg up these comments? bbPress is very popular, as is Tal.ki
Thanks, good suggestion. I will take a look at at both of those plugins.
@Roman: Hmm, will take a look
@drmop I see you are reluctant to use Github in order to keep creative control, which you still will have, even while hosting the source there. The best on moving source to github is that you get the benefit of other people forking and adding features/fixing bugs and requesting you to pull into the source. You are in total control on what is beeing merged into your source. Also it would be nice to be able to have a fork of your project in order to be able to have minor tweaks/changes.
I see that a lot of the libs I’m currently using on bitbucket and github is helped from users being able to contribute. I saw a request for volume functions, and that would probably be something someone using your library could implement 🙂
I hope you will reconsider github/bitbucket or other social code sharing… I do think you will benefit from it if the engine takes off.
Hi Leif,
We are still debating this internally, will post a blog about it when we make a decision.
Mat