iTorque2D vs. Cocos2D performance.
by Chris W Hill · in iTorque 2D · 04/07/2011 (1:07 pm) · 30 replies
Hi,
I have completed some performance tests on iTorque2D, comparing it to the Cocos2D engine. I do not mean any malice by doing this comparison, but it is unfortunately quite obvious in my tests that iTorque2D has some serious graphics performance issues. I would be happy to be proven wrong:
blog.kihongames.com/2011/04/06/itorque2d-vs-cocos2d-performance/
I cannot mention this article without bringing up the overall quality of development on the engine. I feel that at some point there was a serious development effort by quality coders. But then, due to business problems, or other issues the engine quality has suffered drastically. What's wild is that as a new user I could sense this, without seeing the source code. I could feel a coder struggling through a new feature, with a manager standing behind him saying 'looks good, ship it'.
But I could also feel Torque's foundation shining through from those quality coders. These people know how to make games. They understand a developer's role in providing support to designers, and how solid tools provide designers the ability to create fantastic games. So regardless of the issues that I've seen, I'm still here.
But there are a lot of issues. And a lot of promises of new features. I hate to be soapboxy, but it must be said.
I can sense the bad management decisions that have plagued iTorque2D through the source code. The bugs are just symptoms of this problem. The issues are fundamentally systematic, and process-oriented. For example, shipping torque for the iphone without batch calls. The level datablocks feature is half-baked at best. These are features that perhaps matched some feature spec, but do not meet the expectations of the end user (me). Demand a higher quality of polish and functionality.
Don't worry about new features. Fix the bugs. Refactor. Polish existing features to perfection. Improve the documentation. Forget about Box2D, pinch/zoom or any features I see requested on the forums. Fix what you got.
I make some assumptions in this post, and I apologize if I am off, or offend. As I said, I am a Torque user, and I just think you'd want to hear my thoughts on this.
I have completed some performance tests on iTorque2D, comparing it to the Cocos2D engine. I do not mean any malice by doing this comparison, but it is unfortunately quite obvious in my tests that iTorque2D has some serious graphics performance issues. I would be happy to be proven wrong:
blog.kihongames.com/2011/04/06/itorque2d-vs-cocos2d-performance/
I cannot mention this article without bringing up the overall quality of development on the engine. I feel that at some point there was a serious development effort by quality coders. But then, due to business problems, or other issues the engine quality has suffered drastically. What's wild is that as a new user I could sense this, without seeing the source code. I could feel a coder struggling through a new feature, with a manager standing behind him saying 'looks good, ship it'.
But I could also feel Torque's foundation shining through from those quality coders. These people know how to make games. They understand a developer's role in providing support to designers, and how solid tools provide designers the ability to create fantastic games. So regardless of the issues that I've seen, I'm still here.
But there are a lot of issues. And a lot of promises of new features. I hate to be soapboxy, but it must be said.
I can sense the bad management decisions that have plagued iTorque2D through the source code. The bugs are just symptoms of this problem. The issues are fundamentally systematic, and process-oriented. For example, shipping torque for the iphone without batch calls. The level datablocks feature is half-baked at best. These are features that perhaps matched some feature spec, but do not meet the expectations of the end user (me). Demand a higher quality of polish and functionality.
Don't worry about new features. Fix the bugs. Refactor. Polish existing features to perfection. Improve the documentation. Forget about Box2D, pinch/zoom or any features I see requested on the forums. Fix what you got.
I make some assumptions in this post, and I apologize if I am off, or offend. As I said, I am a Torque user, and I just think you'd want to hear my thoughts on this.
#22
Can you explain in more detail what you mean by sprite pools? I'm willing to test various things if they will help me shed light on performance.
04/09/2011 (2:23 pm)
@scott I have not come across a lot of stringtable lookups. The samples I've seen show that all the cpu-intensive stuff is graphics and rendering related. renderObject is up there, along with findObjects.Can you explain in more detail what you mean by sprite pools? I'm willing to test various things if they will help me shed light on performance.
#23
However, for you tests, thinking about it, there isn't much point because you allocate 100 sprites and that's it. These stay on screen for the duration of the test?
WRT to the string table - we noticed that ultimately everything would lookup an object, attribute, method name etc using the string table which internally would carry out many, many string compares. Given the time I would have attempted to fix using some sort of string hashing algorithm, thus cutting out the string compare.
BTW, great stuff that you are doing. Looking forward to the next set of results :)
04/09/2011 (2:41 pm)
Sprite pool is basically allocating a pool of sprites or animated sprites and instead of destroying them at then end of the life cycle you put them back in the pool and re-use them. It saves the overhead of creation and adding to the scenegraph.However, for you tests, thinking about it, there isn't much point because you allocate 100 sprites and that's it. These stay on screen for the duration of the test?
WRT to the string table - we noticed that ultimately everything would lookup an object, attribute, method name etc using the string table which internally would carry out many, many string compares. Given the time I would have attempted to fix using some sort of string hashing algorithm, thus cutting out the string compare.
BTW, great stuff that you are doing. Looking forward to the next set of results :)
#24
Hmm...interesting on the string table compares. I haven't really looked at the internals, I assumed there was a hash at the heart of it. Definitely a place to look to improve performance!
04/09/2011 (2:45 pm)
@Scott: Ok, that's what I thought you were talking about. Yeah, everything's allocated and re-used, i'm not destroying anything. I think sprite pooling is inconsequential for my tests.Hmm...interesting on the string table compares. I haven't really looked at the internals, I assumed there was a hash at the heart of it. Definitely a place to look to improve performance!
#25
04/09/2011 (3:12 pm)
Haha, typical, just spent the past two hours completely rewriting the input system, initial tests give promising results c++ all works, I then recompile my .cs script and the damn thing crashes on load with no error. =S
#26
OK have just majorly rewritten input system, each object now tracks which fingers are pressed on it specifically and in what order they were pressed.
So I can do:
function Penguin::onMouseUp( %this, %modifier, %worldPosition, %clicks, %order)
{
echo %order;
}
Put two fingers down, take off the first and you get a 0, do the same again but take off the second finger and you get a 1.
04/09/2011 (3:39 pm)
lol forgot the word function, too used to Torsion being nice.OK have just majorly rewritten input system, each object now tracks which fingers are pressed on it specifically and in what order they were pressed.
So I can do:
function Penguin::onMouseUp( %this, %modifier, %worldPosition, %clicks, %order)
{
echo %order;
}
Put two fingers down, take off the first and you get a 0, do the same again but take off the second finger and you get a 1.
#27
04/09/2011 (5:33 pm)
@Scott: Not only is there a lot of string table stuff, but once something goes in it never deallocates for any reason whatsoever, according to tests. The script also converts back and forth all the time, rather than caching numeric variables.
#28
Where's the code that determines the need for numeric conversion in script? I'll take a look, I learned a bit about optimisation in this area when looking at php5 and the zend2 engine.
04/09/2011 (7:17 pm)
@Ronny - aside from taking up memory I thought this idea of the string table was to speed up access in script etc?Where's the code that determines the need for numeric conversion in script? I'll take a look, I learned a bit about optimisation in this area when looking at php5 and the zend2 engine.
#29
But I've been told many times that the script converts numbers from a string on each access, so having or not having a string table does not matter for that (or so I think - I don't care if it's wrong - it's still slow). There might even be another tiny hash lookup extra while checking if the number is in the table, if that's actually where it goes ;)
What it should do is to optimise numbers by caching them, and converting them as needed. But more clever techniques exist, I'm sure. Everything is a string in TorqueScript, so I'm sure it adds to the bottleneck. The language itself is probably not very optimised either, so you've got some work to do there.
There's also the other option, which I evangelise: Screw this and add a faster script language, recreating the 1500+ function calls. It may turn out to be easier :)
04/09/2011 (9:07 pm)
You'd think it was, yes. I have no idea where it is. I get ill when I look at it ;)But I've been told many times that the script converts numbers from a string on each access, so having or not having a string table does not matter for that (or so I think - I don't care if it's wrong - it's still slow). There might even be another tiny hash lookup extra while checking if the number is in the table, if that's actually where it goes ;)
What it should do is to optimise numbers by caching them, and converting them as needed. But more clever techniques exist, I'm sure. Everything is a string in TorqueScript, so I'm sure it adds to the bottleneck. The language itself is probably not very optimised either, so you've got some work to do there.
There's also the other option, which I evangelise: Screw this and add a faster script language, recreating the 1500+ function calls. It may turn out to be easier :)
#30
If torque used some simple is_int etc style functions it could determine the appropriate internal storage for a variable potentially this would be a better approach, I guess it depends how much cpu it takes currently to determine the datatype and convert it.
On another note, for this batch rendering, since iTorque loads all level datablocks at level load and their associated sprites, why don't we have a step like the .dso compile that automates an action like the one performed by unChaos to place everything into giant spritesheets, the hard part would be finding a reliable way to do this that does not break user TorqueScript references, several approaches are possible In short though this would hit two birds with one stone and enhance sprite rendering performance whilst removing an annoying manual step.
04/10/2011 (4:44 pm)
@Ronny - I do think it would be better to store anything that can be interpreted as a number or simple data type as such and convert to string as necessary. PHP accomplishes this through a union structure that can at any one point represent an int, float, bool, pointer to hashtable array, pointer to string, pointer to an object/resource by using the same storage space.If torque used some simple is_int etc style functions it could determine the appropriate internal storage for a variable potentially this would be a better approach, I guess it depends how much cpu it takes currently to determine the datatype and convert it.
On another note, for this batch rendering, since iTorque loads all level datablocks at level load and their associated sprites, why don't we have a step like the .dso compile that automates an action like the one performed by unChaos to place everything into giant spritesheets, the hard part would be finding a reliable way to do this that does not break user TorqueScript references, several approaches are possible In short though this would hit two birds with one stone and enhance sprite rendering performance whilst removing an annoying manual step.
Torque Owner Scott Wilson-Billing
MeYuMe