Framerate & Memory Usage experiences in 0.8.x

#1 Good info!

One thing I just thought of, although I don't even have iTGB yet: there is XCode project compile option for code size optimization vs. FP performance. Compile for Thumb was on by default in XCode projects for iphone, for 2.0 anyways! See iPhone OS Programming Guide | Managing your memory use:
"Adding the -mthumb compiler flag can reduce the size of your code by up to 35%. Be sure to turn this option off for floating-point intensive code modules, however, because the use of Thumb on these modules can cause performance to degrade."

#2 You should try converting your 8 512x384 png files to the pvrt4 file format. If you do not do this, the PNG files turn into fully uncompressed textures in the phone. Since you only have 24MB total for textures and surface data on the phone, using something other than PVRT format on the phone can cause serious issues. By way of example, a 1024x1024 texture atlas we had as a png file used up 4MB of ram as a texture. When we used texture tool on our non torque application to convert it to a pvrt4 format, it only took 512K of ram to hold the texture.

You will have to change the code that loads the texture into OpenGL though, so it might need to be done by Garage Games in their engine.

You can find the tool to convert png to pvrt2 and pvrt4 formats at /Developer/Platforms/iPhoneOS.platform/usr/bin/texturetool

The following code snipit is from the class I use to load textures (Which was based off of apples Texture 2D class). Hopefully it will at least give you an idea of how to load the pvrt4 files.

- (id) initWithImagePath:(NSString*)path sizeToFit:(BOOL)sizeToFit pixelFormat:(Texture2DPixelFormat)pixelFormat
{
	UIImage*				uiImage;
	WDTexture *newSelf;
	
	NSString *pathCopy = [path copy];
	
	if(![path isAbsolutePath])
		path = [[NSBundle mainBundle] pathForResource:path ofType:nil];
	
	// Try and load as a UIImage
	uiImage = [[UIImage alloc] initWithContentsOfFile:path];
	newSelf = [self initWithCGImage:[uiImage CGImage] orientation:[uiImage imageOrientation] sizeToFit:sizeToFit pixelFormat:pixelFormat];
	[uiImage release];
	
	
	GLuint glerror = 0;
	
	// If we fail to load, then try it as a PVRT file
	if(newSelf == nil)
		{
			NSData *data = [NSData dataWithContentsOfFile:path];
			const void *bytes = [data bytes];
			CGSize size = CGSizeMake(1024,1024);
			newSelf = [[WDTexture alloc] initWithData:bytes pixelFormat:kTexture2DPixelFormat_RGBA_PVRTC4 pixelsWide:1024 pixelsHigh:1024 contentSize:size];
			glerror = glGetError();
		}
	
	// Set ourself to our new self
	self = newSelf;
	
	if(self == nil)
		{
			REPORT_ERROR(@"Failed loading image at path \"%@\"", path);
			[pathCopy release];
		}
	else
		{
			_textureName = pathCopy;
		}
	
	return self;
}

#3 We will definitely look into using the proprietary pvrt texture format, for first release we wanted the standard Torque formats, PNG, JPG etc to work out of the box.

#4 Bad news in 1.0 for me, the framerate is actually worse than in 0.8.5. I'm seeing rates of 3 fps and less. Even worse, the 1.0 release also broke my sample game from a touch-and-response perspective, which had been running fine albeit at about 5-6 fps on iPhone in 0.8.5. It still runs great in the TGB harness (eg. TGB with dropping in the iTGB common folder) at like 1000+ fps, all controls accurate.

But as soon as it gets into the simulator the game stops responding correctly to mouseUp events, or something like that, since my pieces hilite but don't move like they're supposed to. FPS in the simulator drops into the 20s, kind of lame but still totally playable. But then on the iPhone - wham! - game seriously chokes, responds with same problems as the simulator in response to touches, and I'm seeing FPS of 3 during the game.

This mini-game is a pretty simple little exercise in basic clicking and light physics and particles. We're talking one 512x384 background, about 10 circular imagemap graphics, some basic particle effects.

I'm kind of stunned that the game runs this poorly. I'm ready to send this example to whomever is coding this iTGB port so they can see what I'm talking about.

#5 As a comparison I put BehaviorShooter on the iPhone, it also has a pretty low framerate with a lot of hitching during any kind of action like explosions. It's got a FPS display in it that reads between 5-8 fps during action sequences, and maybe 16-17 with nothing going on.

So whats' the deal? To be frank iTGB is not commercially usable at this point, it doesn't compare to the smooth performance of the games on iPhone today. The 1.0 tag is premature in my opinion, in fact I'd say this is 0.9 and keep it in the 0.9s until it achieves framerates 50+ or at minimum smooth and non-hitchy at 25-30. Sorry to be a grump, but there's something wrong deep in the code, bros!

#6 Kalle, does it improve at all when you turn off "Compile for Thumb" in your Torque2d.xcodeproj settings and re-compile? Just curious - I don't have time to test it right now. It should speed things up at least a little.

#7 It doesn't improve it anywhere near enough to make the executables usable.

I've to agree with Kalle.
This definitely is no 1.0 release.
I somehow feel like on the TGEA again.
Has GG become really that incapable to test their technology before releasing it?
I realize that you gave a deadline, but if you give deadlines, then put up realistic deadlines, not fantasy deadlines that you don't meet and then release 0.8.x versions instead of 1.0

Right now, iTGB does not meet its advertised capabilities, even worse the performance issue is not even listed on the page anymore like it was with the 0.8 release.

As I own all Torque Technology I know that GG has some pretty smart people that definitely can solve this and I really assume that some of that smart people hop over for a while to solve the issues.
Not saying that the programmers that worked on it are not smart, but they at least do not seem to have the needed background to get it done optimized and without it, iTorque is completely worthless as the iPhone does not compensate unoptimized graphics API code by having a 3 times as powerfull system as you need to get it done. (was this ever tested during development, I mean on a real device?? I highly doubt it)

I payed an additional $500 on the Indie iTGB license, yet the technology is NOT usable at all (the shooter should run at 80-120FPS given there is really nothing that costs performance in there if the iphone optimized formats and the basics from the dev guideline are used).
We (Indie License) were told that we have to wait because the documentation is not up to the point for us to work. Well 1.0 is out and it is not present at all, so I don't understand why I could not get access back with 0.8 if I have to consult the iPhone SDK Documentation all the time anyway due to it.
I feel like I payed at least $300 too much for this not iPhone technology. I assumed TGB to have gotten much more rework to make it a true iPhone technology, to use the UIKit etc.

That I have 2 free licenses as preorderer (Thought the second one is not mentioned on the my account page like it should be according the original preorder page of iTGB Indie) doesn't help anything there, 2 games that don't run at all are just that.

What I have not checked yet is if there is a bounty to get another iTGB developer doing the optimizations.


PS: I know this is not really constructive. Right now I'm just a seriously frustrated but I guess that will get better over time when iTGB got a few updates and gets near the point where it was meant to be with 1.0

#8 I could not have said it any better. Agreed on all points.... GG kicks ass....now get to kickin'!

#9 About 1.0:

1.0 was meant to be a release where you can get going on porting your games over to iPhone with full functionality. Optimizations will come, but we didn't want to hold up your development in the meantime.

Slow framerate information:

A few things you guys should know about iTGB and the iPhone. First off we are aware of the framerate issue and there are 3 factors to this.

First, the iPhone while a nice piece of hardware is not a PC in performance, most games run between 10-30 fps, with the actual cap being a max of 60fps, the device cannot run any faster framerate than that.

Second, the iTGB version 1.0 is a full port of the code so you could get running right away, which means physics iterations are set to full, network is on etc. all of which chew up CPU cycles. Also, the resolution of the iPhone is 480x320 so if you are drawing your images at PC resolutions that will greatly decrease the speed. If your game is not using networking you can turn that off. If you do not need 8 iterations for physics you can set that to 1. Also, using the gTimeAdvance variable will keep you phyics iterations to 1 per frame.

Third, the iPhone CPU is a RISC processor so it is not optimized for strings making script a major bottleneck. We have a version of BehaviorShooter that uses components for behaviors and the performance is significantly better.

We are investigating ways to speed things up and there are some potentially good solutions. Expect to start seeing these in the next 4-8 weeks.

#10 1/2. I (and I guess others as well) am aware of that. But I think its fair to assume that the sample project already takes this into account, its after all the only reference that shows us how to use iTGB, as no other documentation is present as far as I've seen. Thought I'm still trying to get the input related information out of it to make the Adventure Kit work and get some performance information from it.

3. I don't see the exact problem. Get the editor up for iPhones, add a "build project" feature that byte compiles the script and pvr compresses the textures and make the script parser binary to the script and the problem is non existant. The current solution is pretty slugish with "start the game executable to create DSO". Thats fine for an alpha build where different less important features are missing in the technology, before it is considered to be ready for executable distribution, but not really acceptable for 1.0.
Also no one expected to see a PC technology beeing advertised as iPhone technology as it right now is the case.
That code always will be faster is clear. But using a anti-iphone implementation of the script parser as excuse for seriously problematic performance issues to me is a big no go at the price, royalities and license constraints (after all we have to advertise iTGB everwhere even if we have to solve your performance issues ourself) applied to each licensee. You ask for "professional grade indie fees and constraints", so please deliver a professional grade indie technology
If you need help on the performance implementation, start an open talk on how to best approach a given thing here so those with experience on it can give their input, use the information you get offered on the topic or at worst, just take a look at the oolongengine, an opensource 3D engine for iPhone which outperforms iTGB massively!
Especially on how to tighly integrate it, because the TGB / TGE call redirection will never lead to good graphics performance as you bomb the CPU with trash so the CPU becomes the bottleneck, not the graphics card.
For each gl command a whole list of other commands jump in to "test stuff". This is, as you already realized, no PC CPU, we don't have 2 ghz or the like. so please don't blast our precious cpu cycles with stuff thats not needed on a fixed platforms. There is no "that might happen and that and that" thanks to the fact that all systems are equal

Unless you wanted to clearly tell us "ask for a refund as we don't meet our advertisements and get Unity for iPhone at $399 without any royalities and a working deployment path", I highly recommend reconsidering this attitude. I don't want excuses, I want that it is looked into the issues and that the stuff is communicated openly to the licensees. We are not your alpha or beta testers, we are legit 1.0 licensees.
Melv did a great job at that during the EA phase of TGB if you need an example of what I mean.

#11 Paul,

I fully accept your explanation and thank you for the tips on performance optimizations. It's also great that you are now active on the forums providing advice and information. I look forward to trying these optimizations and seeing the tune ups GG applies over the next 4-8 weeks. I will restate however, 10 fps is not acceptable, it has got to run at 24-30 fps consistently, minimum, with smooth action and no hitching. I still believe there is some low-level issue that you guys will find and BOOM the speed will increase.

I wanted to also state that overall I am extremely excited about having TGB on the iPhone and once the framerate issues are resolved it will be spectacular. I also don't think you need a special editor or anything like that, it is fine to use TGB for either PC or Mac (I favor PC due to Torsion).

For those trying to put games on the iPhone simulator, here's what has worked for me:

1. Build your game with TGB, then replace the 'common' folder with what comes with iTGB
2. On the Mac, build out a TGB application using the TGB editors (Build Project should work, or you could even just find the TGBGame.app)
3. Open up the TGBGame.app file (Show Contents, or take the .app off the name) and take out the Contents folder. This contains the core TGB engine, I use this to compile the game into .dsos for the iPhone
4. Place the Contents folder right next to your 'game' and 'common' folders, then open Contents and launch 'TGBGame', I think this is in a sub-folder
5. This should open your game in a small 480x320 window, and it will compile the .dsos
6. Launch XCode, and open the Resources folder. Do a 'Get Info' on the 'game' folder, and change it from BehaviorShooter to yours. Do a 'Get Info' on the 'common' folder, and change it to yours.
7. Build and Go!!

I have no idea if this is the standard method or not, but it worked for me.

#12 @Marc - Paul is one of the iTGB developers, not a GarageGames employee. He did not come in here offering excuses. We asked him to come in here and provide technical details, as well as the reasons 1.0 was set up the way it was.

All of the issues posted since the release of iTGB have been accepted, addressed, and worked on. There are no excuses. The critical issues were posted, and we have listened and are working as hard as we can to take care of it. The next release will make everyone much more satisfied.

Edit (adding more) - A lot of people are frustrated, and we are aware of that. We are just asking that you bare with us for about a week while we resolve the most critical errors. After that, we will continue to improve iTGB. Remember folks, we never release a product and say "We're done!" =)

#13 Thank you Michael for this informations.

To me the 3rd point looked very much like an excuse due to the "the iPhone CPU is a RISC processor so it is not optimized for strings making script a major bottleneck". We are all aware of that, thats why pointing out the obvious instead of having it already adressed in 1.0 made i look like an excuse.
I'm sorry if this was not the case.

I definitely will continue my work on TGB 1.7.4 and port it over step by step to iTGB in the hope that once I reach the point where I planned the iPhone technology of it to "stop", iTGB will be ready to bear with my content performance tests :)
GG in the past reached that point, so I guess for iTGB it will happen as well.
question is most likely only the when :)

But with iTGB and the plan on TGEA 1.8 I'm definitely back around here :)

#14 I know this has all already been said but whats the highest frame rate anyones had in game in 1.0.1?

Obviously this is pretty subjective depending on whats going on etc, according to Instruments im getting 40-50fps on my menus but it drops to 1fps when the level loads, ive stripped it back to just be 2 low res scrollers for the background and a low res sprite for the player but it doesnt go above 1fps :(

Has anyone had semi reasonable frame rates yet? Or are we a way off that?

As great as it is to see my game finally load on the iPhone im now eagerly awaiting the next release!

#15 After some optimizations I was able to get stable 33 fps in the behavior shooter which I am using as prototype for my control implementations as it is pretty barebone with not much problematic in.

the funny thing is that optimization was simple: just take care that the whole view is covered with something!

#16 @Marc - Were you getting that frame rate on the device? If so, could you explain your optimization a little bit more?

#17 Wow, ill 2nd that request for some more info marc! 33fps would do me fine!

The whole screen is definitely full in my game (even over more than so)..

#18 Ok ive managed to get 6-8fps in a level by removing everything bar a static background and one sprite, there must be something going on somewhere though, Im getting 50fps on average during my intro splash screens and while navigating my menus..just the very second I load a level it drops off to single digits :S

#19 OnUpdate in a script is a serious kick in when you want to kill the performance.
Don't know, perhaps the update tick rate is still 16ms or alike.


Sadly daryll & michael are right :(
Should have known that the tile based renderer gives a crap on that ... *doooohh*
was an error that cause different things not to trigger and therefor resulted in this serious improvement.
Sorry for the false hope.