Happy New year everyone and welcome to 2012. Wishing you all a fun and action packed prosperous year and may you sell a million apps.
Some good news about drmop.com, we exceeded over 100k hits for the first time in December 2011! Not massive in general terms but massive for our tiny blog 🙂
Happy New Year!
Congratulations on hitting 100k 😉
I am back working on the sample games… I think there are a few things missing in terms of collision and I really do not want to do it again if Box2D is available, so I am messing with integrating Box2D into IWGameEngine…
Also I think there is a bug in your collision code:
int dx = rect.w >> 1;
int dy = rect.y >> 1;
CollisionSize = dx * dx + dy * dy;
You are dividing width on one line and position on the other instead of height… also you are doing sphere collisions not rectangle collisions checks, also I am not entirely sure what CollisionSize is suppose to represent… but I was having issues with it so I decided to implement my own box collision, but it is similarly limited…
There is a bunch of other functionality that Box2D offers that I actually could use, so I am making the effort of looking at at, though I really did not what to be doing engine development at this time.
On another note: What do you think are right now the biggest shortcomings of IwGE? What areas do you think will need further development? What areas do you think “we” could help out the most?
Will you be making the code available on github or similar soon, so we can help with issues, patches and new features? Not that I am not happy with the stellar speed you develop code, but that way a few more people could help and not rely on just your efforts.
P.S: I am still using v0.25, did not check if bugs are solved.
Hi Dan,
Thanks for finding that collision issue, it will be fixed in the next release this week.
The collision check function is meant only as a very basic pre-collision check and not for serious collision. CollisionRect is basically there for the user to determine the area covered by an object (will eventually be used when we implement zone based maps) but not used right now.
Our next update focuses on definition of resources, scenes, actors, animations etc.. using an XML based mark-up language. We want to get this ready for when we start production of the game editor.
After this next update we are going to integrate Box2D into IwGame and wrap it up into IwGameSceneBox2D and IwGameActorBox2D Still not sure about distribution however as Box2D has a none standard license agreement, which insists on credits (something that IwGame does not). We may attempt to implement it as an optional module, not sure yet. We should hopefully have it integrated some time next week.
Personally I want to get the game editor started. Well, when I say game editor its going to be more of a game / animation editor as we plan on also using it for HTML5 based content production.
Other high priorities include tiled and zoned based map scenes
We still aren’t ready to put IwGame into Github, we don’t feel its sufficiently complete yet.
Mat
Thanks for the heads up… ill focus on my own game design for the next weeks, until IwGE is more stable then, if there are going to be many changes, i will wait for them.
Godspeed Pocketeers!
Mat
Just like to say this is great work. I reckon since I found the site in December I have probably contributed a quarter of the hits!
Just a question from a relative noob to Marmalade and C++ – do you intend to incorporate any UI functionality into IwGame? I’m thinking more of things like labels with changeable text (such as player names). I understand I can make a button using an actor etc., it’s just getting the text into the game and then onto the screen that is getting me at the moment.
Looking forward to the new release, and I have to say what a great job you are doing – you have a long term fan here!
Mark
Hi Mark,
Thanks, funny you should say that, our hits did go up by approximately 25% in December lol 🙂
We plan on wrapping up Marmalades native UI and IwUI functionality using an XML based mark-up system similar to .NET XAML and Flex MXML. This is some way off however, but its on our list. We want to make IwGame viable for app development as well you see. Coupled with the editor that we have planned, we want to make it simple for creating fully interactive animating layouts and what not.
Mat
Mat
Thanks for the reply. Looking forward to the next and future releases.
Any suggestions on how I get over my label problem – can I create a CIwUILabel as a subclass of a CIwGameActor? Or am I better off waiting to see what functionality the new version of IwGame has?
Sorry to be a pain – I understand you must be very busy.
Mark
You could potentially create your own sprite class that serves as a basis for Marmalade UI types and because its derived from sprite you will be able to use it as an actors visual. Or you could just stick a CIwUILabel inside an actor and manually update the label in the actors Update() and UpdateVisual(). When I say manually update I mean change the position / orientation, visibility etc..