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.
#22
*3.x compiling against Apple's iPhone SDK
*Drastic load time reduction
*PVR on spritesheets
*Multiple fixes gathered from the bug section
*Editor stabilizations
*Better exposure of "usesPhysics". Most likely a checkbox in the editor when modifying a sprite in the scene
*Some memory leak fixes
*Melv May's updated memory reduction fix
*Better iPhone keyboard integration
*Pinch/Zoom
*Vibration
*File save/load
*Full regression test
*Xcode targets reduced to 1 or 2
*As many sample behaviors converted to C++ components as possible, providing a pseudo-library of examples that you can use or modify.
*Device library access
One big change is that we are rebranding our iPhone engines to match our desktop solutions, and keep up with the iPhone SDK versioning.
We have been told several times that it is confusing to have TGB, Torque 2D, and iTGB. Also, new users have to ask around to figure out what iPhone SDK is supported by 1.2.x or 1.3 (etc).
So, when the release comes out it will most likely be called:
Torque 2D for the iPhone. If a version number system is used, it will coincide with the base SDK (so 3.1).
ETA? August time frame.
The big features, such as Push Notification and Store Kit integration are probably going to be handled after this next release. However, at that point my involvement in iTGB may be reduced back to just documentation.
08/06/2009 (11:21 am)
It looks like we are managing to get a few things in for the next update that were not planned. Here's my running list, which basically combines what we were going to do for 1.2.x and 1.3:*3.x compiling against Apple's iPhone SDK
*Drastic load time reduction
*PVR on spritesheets
*Multiple fixes gathered from the bug section
*Editor stabilizations
*Better exposure of "usesPhysics". Most likely a checkbox in the editor when modifying a sprite in the scene
*Some memory leak fixes
*Melv May's updated memory reduction fix
*Better iPhone keyboard integration
*Pinch/Zoom
*Vibration
*File save/load
*Full regression test
*Xcode targets reduced to 1 or 2
*As many sample behaviors converted to C++ components as possible, providing a pseudo-library of examples that you can use or modify.
*Device library access
One big change is that we are rebranding our iPhone engines to match our desktop solutions, and keep up with the iPhone SDK versioning.
We have been told several times that it is confusing to have TGB, Torque 2D, and iTGB. Also, new users have to ask around to figure out what iPhone SDK is supported by 1.2.x or 1.3 (etc).
So, when the release comes out it will most likely be called:
Torque 2D for the iPhone. If a version number system is used, it will coincide with the base SDK (so 3.1).
ETA? August time frame.
The big features, such as Push Notification and Store Kit integration are probably going to be handled after this next release. However, at that point my involvement in iTGB may be reduced back to just documentation.
#23
08/06/2009 (11:43 am)
I'd say Push is one of the least useful kits for games. No hurry with that. StoreKit is more useful, but still requires mainly backend work so is not for everyone. StoreKit was dropped from one of the better iPhone programming books soon in stores simply because there is too much product-specific about each case.
#24
Btw, we are getting help from Luma, which is going to make this release the best yet.
Also, is there any interest in an optional integration for advert-software? As in, we can provide the integration code if you wish to use it to get advertisements in your games to make more money?
I have several offers from companies to do so.
08/06/2009 (11:53 am)
@Ronny - Thanks for the feedback on the kits. If anyone else would like to weigh in on the value of those, please do so now.Btw, we are getting help from Luma, which is going to make this release the best yet.
Also, is there any interest in an optional integration for advert-software? As in, we can provide the integration code if you wish to use it to get advertisements in your games to make more money?
I have several offers from companies to do so.
#25
08/06/2009 (12:41 pm)
Ads aren't of big interest to me. Feature list and ETA sound great. :)
#26
AdWhirl is the one I think looks most promising, as in literally being the one promising the most :)
They're supposed to work with damn near any ad provider, including yourself if you want to cross-promote your own games.
08/06/2009 (1:56 pm)
About the ad integration: All we need are some easy guidelines on what UIView to connect the ad banner to. That seems to be a problem people are having with any engine, when they didn't make the basic app window themselves.AdWhirl is the one I think looks most promising, as in literally being the one promising the most :)
They're supposed to work with damn near any ad provider, including yourself if you want to cross-promote your own games.
#27
08/06/2009 (9:49 pm)
The option of ads is good for the free light versions of games. I think it would be a plus.
#28
I would rather see OpenFeint integration working rather than some sort of advert-software (although it would never hurt to have that as well)
08/07/2009 (5:48 am)
sounds great Mich. Great news about the PVR spritesheets and reduced loading times! I would rather see OpenFeint integration working rather than some sort of advert-software (although it would never hurt to have that as well)
#29
08/07/2009 (5:08 pm)
Can we get a beta version that we can test?
#30
Please give more details since it is very important to know if 1.3 will fix the memory leaks in my games.
Thanks,
Mike
08/08/2009 (3:35 pm)
August is here... that means 1.3 is close to be released?Please give more details since it is very important to know if 1.3 will fix the memory leaks in my games.
Thanks,
Mike
#31
I'm really excited about the features you listed. They really reflect what people have been asking for which shows your listening to us!
08/08/2009 (4:48 pm)
Everything in the feature list looks great! I'm not real interested in Push notification, I'm definitely interested in store kit but not for a while yet as I have more important items and also want to give iPod touch users more time to upgrade to OS 3.0 before I lock them out with store kit integration.I'm really excited about the features you listed. They really reflect what people have been asking for which shows your listening to us!
#32
I'll see if I can hack up something, as supporting 2.x while still allowing 3.x features is something we'll all need soon. NEED, I tell ya!
The implementation should go like this:
1.Weak links to 3.x frameworks
2.Dynamic loading, test if objects respond to signals etc.
3.Booleans available to TorqueScript to indicate whether Push, StoreKit, GameKit is available
4.Use fancy functions if true
Push, as I said, is fairly useless in games. So we can probably ignore that for now. I'd find it annoying if half my games used it, anyway. Leave notification for when I launch the game, and never earlier.
StoreKit will become a nice extra source of income, so it's vital.
GameKit has both the peer-to-peer networking (which could replace regular networking) and voice comms (which is available over wi-fi too). P2P could be activated instead of wi-fi if the game finds another instance of itself via GameKit.
The final thing to check for would be OpenGL ES 2.0. There is no direct support yet, but it would be nice to have the stubs in place now. You can also push more polygons when new hardware is detected - the capabilities would change drastically.
08/08/2009 (6:40 pm)
StoreKit can be supported on 3.0 devices in the same binary that works on 2.x devices. Numerous hints have been made by Apple people on the official forums, but it might be tricky if you're new to Cocoa.I'll see if I can hack up something, as supporting 2.x while still allowing 3.x features is something we'll all need soon. NEED, I tell ya!
The implementation should go like this:
1.Weak links to 3.x frameworks
2.Dynamic loading, test if objects respond to signals etc.
3.Booleans available to TorqueScript to indicate whether Push, StoreKit, GameKit is available
4.Use fancy functions if true
Push, as I said, is fairly useless in games. So we can probably ignore that for now. I'd find it annoying if half my games used it, anyway. Leave notification for when I launch the game, and never earlier.
StoreKit will become a nice extra source of income, so it's vital.
GameKit has both the peer-to-peer networking (which could replace regular networking) and voice comms (which is available over wi-fi too). P2P could be activated instead of wi-fi if the game finds another instance of itself via GameKit.
The final thing to check for would be OpenGL ES 2.0. There is no direct support yet, but it would be nice to have the stubs in place now. You can also push more polygons when new hardware is detected - the capabilities would change drastically.
#33
08/09/2009 (8:53 pm)
Until Apple comes up with a better solution such as encrypting published apps, how about anti-piracy methods? I know it's been talked about in other threads, but what if T2D4iP was the first product to come up with a moderate piracy deterrent. Even if it means CRC and file integrity checking, encrypting DSOs, or whathaveyou.
#35
Also, I'll note because I've seen a lot of people saying they have no use for push notification, I have a lot of really cool ideas that require it to work.
08/10/2009 (1:23 pm)
Just curious, how much of that list are things that are already done and how much of it is still being worked on? Or is 1.3 mostly done and more in the testing phase?Also, I'll note because I've seen a lot of people saying they have no use for push notification, I have a lot of really cool ideas that require it to work.
#36
08/11/2009 (8:09 pm)
Will version 1.3 work with the Platformer Starter Kit (PSK)?
#37
@Zeinad: What cool things are you going to do with Push? I see Push as a problem for not-so-lightweight games. Push needs to launch your app, so perhaps iTGB needs a special case init for when it's launched like that, not starting up all its subsystems. Otherwise I can see a Push-enabled app sitting there while somebody's distracted from responding to it, draining batteries ;)
08/12/2009 (8:26 am)
I think it's more a matter of PSK working with iTGB - Phil said it can be made to work, if you're willing to do some work on your own. He also mentioned something about a proper iPhone port. I hope he does, because that moves it up on my long list of cool stuff to buy.@Zeinad: What cool things are you going to do with Push? I see Push as a problem for not-so-lightweight games. Push needs to launch your app, so perhaps iTGB needs a special case init for when it's launched like that, not starting up all its subsystems. Otherwise I can see a Push-enabled app sitting there while somebody's distracted from responding to it, draining batteries ;)
#38
08/18/2009 (10:12 am)
@Michael: I'm with Geoff on OpenFeint. If we could have that integrated already that'd be real nice. Adverts aren't as interesting to me.
#39
08/24/2009 (10:36 am)
Found this thread, looking for a brief status update if one is forthcoming :)
#40
Seemed a bit odd when looking through the code that while you catered for the PVR compressed texture formats, there was nothing there for the palette formats.
While in most cases RGB / PVR are fine, i've actually found the palette formats to be quite fast (when testing streaming video frames); not as fast as PVR granted, but still faster than RGB. Plus it can work better for line drawings and such.
08/24/2009 (1:56 pm)
Any chance you guy's are going to implement palette texture support? Seemed a bit odd when looking through the code that while you catered for the PVR compressed texture formats, there was nothing there for the palette formats.
While in most cases RGB / PVR are fine, i've actually found the palette formats to be quite fast (when testing streaming video frames); not as fast as PVR granted, but still faster than RGB. Plus it can work better for line drawings and such.
Torque 3D Owner Chris Jorgensen
Cascadia Games LLC