iTGB 1.3 Planning
by Michael Perry · in iTorque 2D · 06/01/2009 (10:50 am) · 218 replies
The iTorque Updates Blog contains the iTGB Roadmap, which announces plans for v1.3. Here is a recap:
iTGB 1.3: The highest priority is upgrading the engine to work with the 3.0 OS and SDK for iPhones. This includes compatibility and integrating the new features.
* Compile iTGB against 3.0 SDK, with GCC 4.2
* Full motion video playback, with examples exposed to script
* Displaying pictures from device library
* Playing music from device library
* Camera access from device
In addition to 3.0 compatibility and new features, the following improvements to the base engine will be made.
* Integration of Melv May’s memory reduction code
* Significant load time reduction
* PVR for cell-based sprite sheets
* New iPhone features exposed to TorqueScript via C++ handlers
* Gesture callbacks for swipe, pinch, and zoom
* More documentation on creating optimized games, using iPhone specific features, and general reference to frameworks (engine code)
* Community member contributions
o Vibration by Dave Calabrese
o Loading and saving game data to device by Dave Calabrese
o Multi-Touch and gestures by Dave Calabrese and Justin Mosiman
* General optimizations that will increase fps
Please use this thread to post feedback about the upcoming features, or 3.0 specific functionality you might be interested in. Try not to clutter this with current bugs or 1.2 issues, which are addressed elsewhere.
iTGB 1.3: The highest priority is upgrading the engine to work with the 3.0 OS and SDK for iPhones. This includes compatibility and integrating the new features.
* Compile iTGB against 3.0 SDK, with GCC 4.2
* Full motion video playback, with examples exposed to script
* Displaying pictures from device library
* Playing music from device library
* Camera access from device
In addition to 3.0 compatibility and new features, the following improvements to the base engine will be made.
* Integration of Melv May’s memory reduction code
* Significant load time reduction
* PVR for cell-based sprite sheets
* New iPhone features exposed to TorqueScript via C++ handlers
* Gesture callbacks for swipe, pinch, and zoom
* More documentation on creating optimized games, using iPhone specific features, and general reference to frameworks (engine code)
* Community member contributions
o Vibration by Dave Calabrese
o Loading and saving game data to device by Dave Calabrese
o Multi-Touch and gestures by Dave Calabrese and Justin Mosiman
* General optimizations that will increase fps
Please use this thread to post feedback about the upcoming features, or 3.0 specific functionality you might be interested in. Try not to clutter this with current bugs or 1.2 issues, which are addressed elsewhere.
About the author
Programmer.
#102
PVR or other format?
I've also not had luck running all projects yet - before I did *anything*, I recompiled both desktop programs with the PUAP flags used by Script_Optimize. I got iPhone Test running smoothly with a relatively short startup time, but the component shooter ran terribly, and had debug lines or something around all objects.
09/11/2009 (1:19 am)
Ouch. I think I've seen those problems even on a supersimple test project (Adventure Kit tiles and no action).PVR or other format?
I've also not had luck running all projects yet - before I did *anything*, I recompiled both desktop programs with the PUAP flags used by Script_Optimize. I got iPhone Test running smoothly with a relatively short startup time, but the component shooter ran terribly, and had debug lines or something around all objects.
#103
09/11/2009 (3:38 am)
Build using 1.3 and mouse inputs don't work when running with debugger. I also don't see anything new. Going back to 1.2. 
#104
_LUMA_OPTIMISED_IMAGEMAP is defined inside of t2dImageMapDatablock.h (right near the top of the file). Loading performance with "optimised = 1" will be improved based on how many images you are loading, and if they were already power of 2 or now. Basically what was happening previously was that all images, if there were power or 2 or not, were being line-by-line copied into newly allocated GBitmaps that were power of 2 in size. So now, if you provide a power of 2 image, it skips that super slow copy operation and just creates an OGL texture from that bitmap. If you give a non-power of 2 image, it still needs to create a power of 2 image an copy the data into it, but the copy process used is much quicker.
Also note that IMAGEMODE_LINK imagemap types do not work with the "optimised" flag as they require that multiple images be recompiled into a single image.
_LUMA_STATICSPRITE_SOURCERECT enables you to set up source rects for StaticSprites. That means that you can group multiple static sprites into a single image, and instead of it using the entire image for a single sprite, you can have multiple sprites reference that image with each one referring to an individual rect within that image.
_LUMA_TEXT_SUPPORT exposes the ability to apply bilinear filtering and nearest pixel clamping to text objects so that they don't render blocky when you render them at scaled font sizes. It also enables an alpha value for text objects. I'm not sure why defining that breaks your build... it works fine on my side...
@Ronny:
The "debug lines" that you are seeing in the component shooter are a result of filter padding not being used with "optimised = 1". Filter Padding requires that images are resized at load time, which breaks the whole power of 2 rule (ie. if you have a 64x64 image loaded up with filter padding, it will resize it to a 66x66 image, and then it will actually take up 128x128 of video memory!). So, the sprites in that sample are probably expecting there to be filter padding. Since there isn't auto-filter padding now, you need to take into account bilinear filtering bleeding when you create your sprites, so each sprite needs to have a few pixels of "blank" space between it and the sprites around it so that when you render a sprite that is filtered, the hardware doesn't go and grab neighbouring pixels. So, if you set optimised = "0" and "filterpad = "1" on the imagemap datablocks in the shooter, you'll see that they lines go away nicely :)
@Mich:
All of the _LUMA #defines should actually be removed and just made part of the standard code body. The idea behind those being there in the code that I sent you was so that you could see the changes, and keep/remove what you wanted/didn't want. But if you are happy with them, then you should remove the #define's as they are just bulky / confusing!
Filter Padding for image maps is still supported, just not if you use the "optimised = 1" setting :)
09/11/2009 (6:49 am)
@Bret:_LUMA_OPTIMISED_IMAGEMAP is defined inside of t2dImageMapDatablock.h (right near the top of the file). Loading performance with "optimised = 1" will be improved based on how many images you are loading, and if they were already power of 2 or now. Basically what was happening previously was that all images, if there were power or 2 or not, were being line-by-line copied into newly allocated GBitmaps that were power of 2 in size. So now, if you provide a power of 2 image, it skips that super slow copy operation and just creates an OGL texture from that bitmap. If you give a non-power of 2 image, it still needs to create a power of 2 image an copy the data into it, but the copy process used is much quicker.
Also note that IMAGEMODE_LINK imagemap types do not work with the "optimised" flag as they require that multiple images be recompiled into a single image.
_LUMA_STATICSPRITE_SOURCERECT enables you to set up source rects for StaticSprites. That means that you can group multiple static sprites into a single image, and instead of it using the entire image for a single sprite, you can have multiple sprites reference that image with each one referring to an individual rect within that image.
_LUMA_TEXT_SUPPORT exposes the ability to apply bilinear filtering and nearest pixel clamping to text objects so that they don't render blocky when you render them at scaled font sizes. It also enables an alpha value for text objects. I'm not sure why defining that breaks your build... it works fine on my side...
@Ronny:
The "debug lines" that you are seeing in the component shooter are a result of filter padding not being used with "optimised = 1". Filter Padding requires that images are resized at load time, which breaks the whole power of 2 rule (ie. if you have a 64x64 image loaded up with filter padding, it will resize it to a 66x66 image, and then it will actually take up 128x128 of video memory!). So, the sprites in that sample are probably expecting there to be filter padding. Since there isn't auto-filter padding now, you need to take into account bilinear filtering bleeding when you create your sprites, so each sprite needs to have a few pixels of "blank" space between it and the sprites around it so that when you render a sprite that is filtered, the hardware doesn't go and grab neighbouring pixels. So, if you set optimised = "0" and "filterpad = "1" on the imagemap datablocks in the shooter, you'll see that they lines go away nicely :)
@Mich:
All of the _LUMA #defines should actually be removed and just made part of the standard code body. The idea behind those being there in the code that I sent you was so that you could see the changes, and keep/remove what you wanted/didn't want. But if you are happy with them, then you should remove the #define's as they are just bulky / confusing!
Filter Padding for image maps is still supported, just not if you use the "optimised = 1" setting :)
#105
SoundEngine.mm still has a bunch of goto statements in it which are not allowed by 4.2
aStar/* still don't have some of the changes I required in order to compile. removal of inline for pathUtilities.h and #ifndef in the pathGrid2d
@Luke 99% of my images are powers of two. I went so far as to include extra transparency around a lot of my images to ensure they were power of two. I see zero performance improvement loading levels with 1.3. I timed it multiple times.
09/11/2009 (9:35 am)
@Ronny SoundEngine.mm still has a bunch of goto statements in it which are not allowed by 4.2
aStar/* still don't have some of the changes I required in order to compile. removal of inline for pathUtilities.h and #ifndef in the pathGrid2d
@Luke 99% of my images are powers of two. I went so far as to include extra transparency around a lot of my images to ensure they were power of two. I see zero performance improvement loading levels with 1.3. I timed it multiple times.
#106
09/11/2009 (10:26 am)
Don't know what to tell you Bret. Those changes decreased our load times by > 50%.
#107
09/11/2009 (12:41 pm)
@Luke did you PVR compress those images before running your tests? PVR definitely decreases my load times significantly, but just having the PNG's be a power of 2 and NOT using PVR didn't decrease my load times.
#108
My onMouseDragged is not getting called, at least thats what I think it is due to the change in the input functions as Michael said.
Thanks,
Dave Leverton
09/11/2009 (1:57 pm)
Has anyone found out the new input functions? My onMouseDragged is not getting called, at least thats what I think it is due to the change in the input functions as Michael said.
Thanks,
Dave Leverton
#109
I reverted my input handling methods to Dave's original implementation for the time being. I'm trying to release this weekend so can't afford to debug it right now.
09/11/2009 (2:26 pm)
@John having the same problem here. I reverted my input handling methods to Dave's original implementation for the time being. I'm trying to release this weekend so can't afford to debug it right now.
#110
Another note, I'm getting that dreaded "TGBGame has exited with status 5" for a MacOSX build after I modify the source. Only in this case, I can't seem to shake the error. :(
Edit: Fixed the status 5 problem. It wasn't linking to OpenAL correctly. :)
09/11/2009 (2:33 pm)
Also seeing onMouseDragged not working.Another note, I'm getting that dreaded "TGBGame has exited with status 5" for a MacOSX build after I modify the source. Only in this case, I can't seem to shake the error. :(
Edit: Fixed the status 5 problem. It wasn't linking to OpenAL correctly. :)
#111
@Luke: Thanks, that clears some things up :)
09/11/2009 (5:39 pm)
@Bret: You seem to be using 1.2. SoundEngine.mm compiles without issue in T2Di Beta 1.0 (the engine formerly known as iTGB 1.3).@Luke: Thanks, that clears some things up :)
#112
09/11/2009 (5:45 pm)
@ronny i'll check again tonight to see if I failed to merge something from 1.3 but 99% sure it doesn't compiler with GCC 4.2. Are you sure your using GCC 4.2 and SDK 3.0/3.1? 
#113
09/11/2009 (5:46 pm)
I'm able to compile with GCC 4.2. Had to set the link to dynamic, though.
#114
09/11/2009 (5:53 pm)
An official blog from me (my last) concerning 1.3 and the future of the iPhone engines will be released tomorrow.
#115
09/11/2009 (5:55 pm)
I'm positive I'm using GCC 4.2 and SDK 3.1, yes. Tried 3.0 for good measure, but 3.1 is a superset. Snow Leopard, latest Xcode (the one where they stupidly bundle the SDK again). There is ONE goto in the entire SoundEngine.mm, so you should just copy the one from a pristine T2Di Beta. It's guaranteed to work. Honest :)
#116
09/11/2009 (9:05 pm)
Actually i am seeing pretty fast build + compile times from iTGB, but unfortunately can not get past the startup screen . Either freezes or crashes back to the springboard in simulator or once deployed. on Osx 10.5.8. 
#117
09/12/2009 (9:52 am)
@Michael Perry: Your last?!
#118
09/13/2009 (10:16 am)
When I compile in simulator work correctly but if I compile on device... xCode found 134 errors... Why? 
Torque Owner Michael Savarese
We have a game that uses tilemaps and they pop in and out. The game runs from the compiler, but when launched straight off the device they crash and exit on load.
Anyone have ideas on how to overcome these problems?