Demands of the Engine

#1 Is there a better engine out there? One that can handle more or are they all pretty much equal?


I am just wondering, because I am good with iTGB and do not want to change, cost and learning curve are the reasons. So, what giveth?

#2 @rennie - It sounds like you are going to need to get into the source code to start making heavy optimizations. There are places in the engine that can be trimmed down if they do not relate to your game. One suggestion is to run your game with Xcode's performance tools turned on to see what the bottlenecks are.

Optimization is key to game development and should never be skipped.

#3 Ok great. I will look into that. In theory, you think, that I can get the engine to "fit" my games needs?

#4 Rennie, what is your "target" device? I've given up optimising for iPod Touch 2 and iPhone 3G. Now I only care about:

3GS
iPhone/iPod4
iPad

#5 Well that is it. I am testing on an iPod 4.

#6 Scott,

Why have you given up on the second generation devices? There are still plenty of people using them (Not just a wild assertion, I have stats from my own games to prove it)

#7 @Craig I guess it's that their hardware is significantly weaker and less programmable in the case of the gfx card than the 3GS, iPhone 4 is incrementally better. If I was doing hardcore collisions on many objects, I wouldn't target these devices.

#8 @rennie The torque source code is written in C++, you don't get any faster! If you can write an efficient and optimised collision system for your needs then you will without doubt get the performance you're looking for.

#9 Ok, well I have only been programming for a year and half so going on that, do you think I could be able to do that? And where would I write, see, edit the collisions scripts, if that is the case. Here tho in my case it is not (necessarily) the collisions but the number of objects.

I am just going thru Instruments now and have a few ideas of things I can try to reduce stress on the computer.


Thanks.

#10 @Craig, for me it's about economies of scale - I'm not seeing enough sales to warrant us (MeYuMe) spending time on optimising for the older devices. I would rather add features for the new devices e.g. TV OUT, retina, VGA cable etc I'm looking forward to the day when Apple gives us a way of nixing these devices for good - it's getting pretty close with iOS 4.3. Also, iPhone5, iPad2 and I suspect games on AppleTV are just around the corner.

IWT will launch soon as a universal app - it's now 128 Mb, here's why

- PVR GFX for slow devices (2nd gen)
- 480x320 for 3GS/iPod Touch3
- 960x640 for iPhone4/iPod Touch4
- 1024x768 for iPad

We also have updates for NeoDefender 2 as a universal app and two new games in the pipeline - I just don't have the resource to go through the pain of the optimise/test cycle for the older devices.

#11 @Rennie, have you implemented the sprite pooling that has been posted before? Also, stuff like collision layers, groups etc can improve performance. I'd focus on getting as much as you can in script before diving into C++. We've done lots in C++ (especially my colleague An) and to be honest optimising the engine is not for the faint-hearted unless you've got a really good handle on OpenGL etc

Finally, iPhone4 should handle a large number of objects without too much trouble. NeoDefender on later levels has a lot of objects on screen and and many particle effects being triggered - this stuff is pretty smooth on 3GS+

#12 Ok great Scott.

By "sprite pooling" do you mean, placing as many on one sheet as possible, following POT etc, the using source rect? I cleaned up my images,(I am in a dev stage) and some were non pot, helped a nice bit but no where near perfect.



I have a quick question.


In my main behavior I check a lot of variables inside one main function, running thru them to check the status' of them. Generally speaking, if true, do that (function), if false, nothing. So I am wondering...
a. calling a half dozen $globals, checking to see their status, this can't be demanding, is it?
b. is there a way to call them that is easier....

is this worse than...

if($global == true)
{
%this.dothis();
}

this....?

if($global)
{
%this.dothis();
}

or...

if(isObject($global))
{
%this.dothis();
}

#13 Rennie, I mean pooling of sprite and animated sprite objects. There are a number of threads and code in the forums about this. Creating sprites is expensive so you build a pool of say 20 and you take them out of the pool to use them and when they are finished with you put them back into the pool for later use.

The if statements wont make that much difference - stuff happening in loops may well do and you need to ensure that if you're looking for something in an array that once you find it you exit the array loop.

#14 Hmm. Ok thanks Scott. I will research pooling sprites. Also I will have to further research arrays. Would using arrays effect the way I do it now, which is to simply loop thru a function on a repeating schedule?

#15 Rennie, I found the post with the code for sprite pools - you asked the original question so I'm guessing you are using them?

www.garagegames.com/community/forums/viewthread/118707

#16 Thanks. What do you think of arrays? in regards to my question, if you got a minute. thanks.

#17 Wow, thanks Scott. I just re went over the code you posted, this will come in handy over the next few days for sure.


Question tho, this, "pooling", do you think it will reduce the demands on the computer? So as I say, I have 100 "pegs" these pegs are just 16x16 staticSprites that send physics, are immovable and receive collisions.




Thanks again tho that code really is massive. Thanks.

#18 The code will only be of benefit if all 100 pegs are not on screen at the same time?

Arrays are fine - I assume you mean SimSet?

#19 Well, I need to do some more research myself, on exactly what arrays are and do, and how they can help me.


As for the pegs, no. They are all on the screen at once. Any hope of light?

#20 I normally don't do this, but I'm going to chime in here for a moment in defense of Torque. I found that one of the keys to getting the most out of Torque is to use as little script as possible. In the Torque game I am currently building, I often have well over 200 objects on the screen, and the game still runs super smooth, even on my iPod Touch 2nd Generation. However, the game is written almost entirely in C++, and I only use script when I can't avoid using it (for example, behaviors and level loading).

When I first started learning Torque, I started building my game using TorqueScript, but I eventually found that the game became unplayable due to framerate issues. Around that time, I read an interview with a guy who made Dust Bunnies ( http://www.garagegames.com/community/blogs/view/17951), and he mentioned C++ components. Long story short, I researched C++ components in Torque because of that article, and I converted the game as it was to C++. I noticed immediately that the framerate was significantly better and was easily playable even in debug mode.

I should also point out that development using C++, in my opinion, is significantly easier as well. As far as I know, you cannot debug Torquescript with breakpoints and such when you run directly on an iOS device (someone please correct me if I am wrong about that).

Once I finish this game, I will try to write a tutorial for people to on how to use C++ behavior components in Torque, as the documentation on them (as far as I can tell) is very sparse and spread out, and it took me a while to get it working.

Of course, simply using C++ is only one of many optimizations. Some guys here mentioned "pooling", which basically means creating a bunch of objects during loading, so you can use them as needed to avoid repeated dynamic allocations and deallocations of objects during your game, which will often slow down your framerate or may even cause memory issues.