Draw call reduction

#1 Integrating batching is a hell lot of work due to the fact that the whole stuff is define mess class by class implementation that makes any change on that end a little trip to hell instead of a change in a single place.
I hope that with the release of T2D (the renaming of iTGB is significantly missleading, as the TGE architecture is very different from the T3D one on which T2D is said to base) a corresponding port to the iphone happens too unless the engine is completely rewritten from ground up on the rendering end.

Not much you can do without rewriting any t2d class, integrate a single global rendering manager etc.

Worst without question are particle effects and tile layers, as each single particle and tile is rendered as a distinct vertex buffer.

For that reason I would recommend, that you avoid particle effects completely and use animated sprites instead whereever possible. Gives you commonly better quality and more control as well.

On the tile layer end, ensure to remain on as little layers as possible.

#2 I'm not using particle effects for the reasons you stated and I'm only using 1 tile layer for the background tiles. However this still amounts to over 40 draw calls just for the tile layer (64x64 tiles) which is already too many before I even add the game into the mix.

Each "monster" then has 3 draw calls itself, 1 for the sprite, 1 for the name , 1 for the health bar. The UI itself is up to 10 draw calls (potion button, search button, map button, inventory skills, etc).

I'm looking at over 60 draw calls on average. Considering the difficulty of reducing it I might just have to pre-req the ipod touch 2g and/or the iphone/ipod 3GS for any expansions due to not being able to work around these iTGB performance limitations.

This problem, coupled with the stagnate code base of iTGB, is actually the primary reason why I decided to dump iTGB for future games and move to that other game engine. Though I'm definitely going to miss the ease of debugging C++ code over script.

#3 Those problems are the primary reason why I prototype in both engines I am using before I decide which way to go.
My benefit is that I'm doing game and 2D / 3D dev in general for long enough to recreate most things that iTGB has without too much work, otherwise that approach likely wouldn't work out.

We definitely finally need to get an iphone targeted iTorque.
The TGB / TGE hack ports that are desktop + iphone platform layer + a bit of opengl es hackery really don't cut it by any meaning.

Its acceptable that scripting is slow, thats what non platform code is expected to be. But its definitely not acceptable that the rendering performance problems still have not been adressed a year post release although they were pointed out since the 1.0 release, often in detail with clear pointers what is causing the problem and what is required ...

Really hoping to see some professionals with a mobile dev background filling in the space in the dev team as the original devs obviously vanished. A move of the codebase to Torque2D as soon as possible definitely would also make those things significantly easier due to the more modern architecture in TGEA / T3D than the archaic TGE is enjoying. In this case especially the GFX part.

#4 Yes it's been obvious for quite some time now that they've only had a single person working on iTGB and only part time at that. I don't feel comfortable tying myself to an engine that is not being actively supported and improved. I'm going to take your approach going forward and own multiple engines at least until I get enough experience with them all to pick one. Right now I'm trying to write a platformer game, and iTGB can definitely not handle that type of game.

#5 I agree with you guys. iTGB rendering performance is not that great. On my Main Menu screen, I have 2 sprites (background and title) and 2 gui objects and its running at 39fps.

I think the rendering engine is the biggest bottleneck with iTGB. In my game I have about 30 objects with very little logic code and it's running around 25 fps. I'm running all script but the script is very light. Judging from my main menu, I don't think the low fps has to do with the script but with the rendering engine.

Has anyone changed the iTGB engine code to improve rendering?

Anyway, my puzzle game should come out in a few months (don't have a name yet) and I will stick to iTGB and hopefully find ways to improve the performance.

It could be worst, Flash 5 beta iPhone games run around 10fps with only 5 sprites on screen.

#6 You can not change the engine code because there is no central rendering engine.
The rendering is handled on a per object base.

You would have to replace the whole hierarchy and basically do what Torque2D does with abstracting such stuff into own systems (GFX in case of T2D / T3D) which then can be opted for specific platforms.

The GFX abstraction is one of the major changes between TGE and TGEA / T3D and by far no small thing thats why porting over an internal Torque 2D build to the iphone would potentially make much more sense than trying to get TGB to work nicely because it just won't
It was never optimized, any intel user will agree on that as they run up walls trying to get an acceptable performance (part of the reason is opengl there naturally but the other part is the number of drawcalls)

#7 "Yes it's been obvious for quite some time now that they've only had a single person working on iTGB and only part time at that. I don't feel comfortable tying myself to an engine that is not being actively supported and improved."

I'm disturbed to hear the engine I just bought is only being worked on part time. :(

#8 They've got a while team on it now. Don't go by old information ;)

#9 Yea supposedly they have a team working on torque 2d, which will likely be a new product they release sometime in 2010 and will have an upgrade cost and require you to port your game to the new engine or only use for fresh games (not necessarily a bad thing). I'm pretty sure iTGB as we know it today is dead in terms of updates. We might see 1.3 finally officially come out this year with minor fixes, but we won't see any major free enhancements.

In a quick update it doesn't appear that draw calls are the issue here. I put a simple return statement into the render function of the Tilemap so it didn't even draw itself (-40 drawcalls) and it had no effect at all on my framerate.

After further analysis it appears most of my framerate issues are related to using t2dTextObjects and the mounting calls profusely.

Unfortunately those aren't easy to fix because I need the mount functionality and converting all my t2dTextObjects to static sprites is not something I want to do.

#10 Uhm...negative Nellie in sector two! Report for re-Neducation! :P

I am talking about T2Di, which does have a team. Yes, they do! T2D has had a team for a long time, while iTGB was made by contractors. With the name change to T2Di, they've added a proper team. Mich said it, so I expect it to be true.

#11 Wait, a new product with an upgrade cost?! I know they have a team working to replace the one guy that was behind iTGB, but after spending $750 for an Indie license for a product clearly inferior and incomplete at best, they're going to have the audacity to ask for more?

Please tell me your sources are not reliable or the information is at least partly speculative.

#12 I have no internal sources, everything is speculation based upon what I've seen in these forums and the changes I've seen in the code base over the past year.

@Ronny I've unintentionally become negative after seeing the changes from 1.1 to 1.3 over the past 10 months. After running the code changes through a recursive diff and looking at the quantity and quality of those changes it's obvious that only a single individual is working on it and only dedicating about 10-20% of their time on it. The amount of changes that have been added to the 1.1 code base are very small. The community contributions far outweigh the official changes.

#13 "Wait, a new product with an upgrade cost?!"

I doubt GG would do that. I'm pretty sure they will come up with a fair way to deal with current existing iTGB licensees.

Charging people to upgrade to something that should be at least like a real 1.0 version , would be outrageous.

As a side note, I must say that the constant need to scavenge the forums and the "all over the place" information is really getting tiring (that's not counting the TDN mess and the outdated tutorials).

Users should not have to do treasure hunting on the forums to find answers to simple questions like: What is the bug or typo error that's preventing me to compile on X platform. That's just not acceptable IMO. Create a big STICKY about problems and issue, and please update it frequently, daily if you have to.

Quite simple I think.

Also, I really hope that they increase their responsiveness toward the user base. i.e Quickly release version patches when BASIC things screw up and not just say something like "noted for version x.xx to be released "when it's done".

I can't complain much about my personal use of the engine, since I've spent so far at least 50% of my time in the forums and I've not coded much, looking for answers and community based patches. Combine that at the same time with the task of learning a new API/Engine and it sums up into a pretty frustrating and not very happy experience.

Just went to check some "competitors" and it was a depressing experience, and I won't hide that I'm having regrets right now with my choice.

All that being said, I'll stick with this engine, for now, but I really hope things improve in the near future. And if so, I'll be the first to praise GG and recommend this product.

#14 Regarding draw performances, after further testing on my game, it seems that the biggest hit is from the GUI objects. Avoid using these if possible.

Now about iTGB lack of updates. I agree with most people here when they say there are not enough or no support for iTGB. I mean they don't even answer any questions in the forums. Sure no updates but at least talk to your community. I had to save to pay for iTGB... iTGB isn't cheap and I only paid for it because I had confident in GarageGames support for their products. The iPhone market is fast growing so the lack of updates are really hurting all of us here. Without the support of everyone in the forums, I would get no where with my game.. So I would like to say thanks to the community again.

Maybe Brett Seyler can let us know what is going on with iTGB?

#15 I don't want to turn this into a self-plug post, but overall for my first kart game, I was able to get a solid 20 FPS out of a 1st gen iPhone and 30+ FPS out of a 2nd gen iPod. Not super but definitely good enough for the job.

Things that slowed down the FPS: GUI overlays, too many triggers, too many callbacks, too much script (AI, specifically), networking, the metrics(fps) callback, lack of PVRs, etc.... I basically just trimmed or converted to C++ where I felt the bottleneck was. I think the performance came out fine, iPod 2G below:



The karts (in filmed version) are actually on individual bloated PNG 1024x1024 sprite sheets. So I'm currently trying to squeeze a bit more performance out of it with file crunches and other tweaks, like removing more GUI items. I *did* turn off a bit of stuff in the main loop, so that might help. :)

#16 The primary problem is that everything that makes iTGB a great engine for indies you can't use, because of the performance problems. My game gets a pretty solid 15-20 FPS (1st gen devices, 30+fps on ipod touch 2G and 60+fps on 3GS) except when my AI kicks in and too many monsters wander at the wrong time. However I don't use triggers, collision detection, GUI, nor physics at all (physics for mounting and moveTo only which is primitive physics at best). Even without using any of the known low performing iTGB aspects I had next to 0 cpu cycles left for AI and game logic.

Pretty much any genre of game you create will either need all, or some, of the following:
Scripting
Physics
Collision detection
Triggers
GUI (I got away with scene objects for the gui using mount's).

I actually liked iTGB while I was developing my RPG because I wasn't using any of the above. However once I moved onto my second project, a platformer, it quickly became obvious that doing a platformer in iTGB was next to impossible without rewriting the physics, collisions detection, triggers, and custom tilemaps. Trying to layout levels without the use of TileMaps is really difficult and tilemaps are really bad perfoming in iTGB, though not on the same order of magnitudes as the physics/collisions etc.

If you work around the above by integrating third party physics, collisions, custom triggers, etc you lose the ability to realistically use the iTGB editor which adds the final nail in the coffin. The editor is already hard enough to use since all assets are loaded into a global pool for all Scenes and it loves to crash on save/shutdown.

*Disclaimer: All of this is in regard to 1st generation devices. iPOD touch 2G and the 3GS have more than enough performance for iTGB for moderately complex games (without the usage of scripting). So in about 1-2 years when their the low end iTGB will be an excellent engine for indies to write low->moderate quality games at a decent framerate.

#17 Hey Chris, Zombie Karts looks great! It's amazing how you got tgb to do mode 7. I can't wait to come up with a game that uses your kit (do planning to buy the kit sometime in the future).

Thanks for the performance tips. Good to know about GUI overlays and metrics(fps)! since i'm using both right now.

#18 Torque2D is an update to TGB not iTGB and requires a fee from TGB users.

I think iTorque definitely will get free updates to the first really iphone targeted technology when there is one, because by now the contract we all signed upon payment has not been fullfilled (larger parts of the feature list is still incorrect and inexistant as a "simple example"). Right now we just have a tech that runs on the iphone and rudimentally supports the iphone input but that is not iphone targeted and GG knows that (the comments from mat in the source can be seen as a proof of it).


iTGB as it is is not per se a bad thing.
Its just lacking far too many base requirements to work efficientely on the iphone that each and every user likely will have to integrate himself again and again or cut even simplistic concepts further down.
I was actually shocked to read that dust bunnies had to rewrite many things in code because the game mechanics seem that simple that any wanna be iphone engine should handle such efforts without many problems through the non-source end if there is one.