RESOLVED: TGB settings polluting iTGB 1.1 environment
by Eric Holsinger · in iTorque 2D · 03/10/2009 (3:51 am) · 14 replies
Bug marked resolved by Michael Perry. Please post a new bug if issue persists in 1.2
I'm using a MBP. In my Applications folder, I have a TorqueGameBuilder folder with TGB. I also have an iTBG_1_1 folder with iTGB.
The iTGB seems to be getting some settings from the TGB installation.
For example, every time I open iTGB with the "load last project" setting on, it opens the last TGB project. I then cannot load any other project. If the flag is on, and I open iTGB and try closing the project and opening another one, it still reloads the last project I had in TGB. Every time. This is a drag, but I can live with not opening the last project.
However, if I go into TGB and turn off the flag to load the last project, then go back to iTGB and try to open a project, it starts in the last folder opened in TGB. This is a total PITA.
Even worse, the default resolution for the project gets lost on save. Creating a brand new project in iTGB right now starts at 640x480 for me. If I change this to 480x320 for a landscape app, save the level, close iTGB and reopen, the level is 640x480 again. This is just wrong. 1) it should not default to 640x480 for an iPhone tool. 2) it should be able to persist the changes I make in the project.
I'm using a MBP. In my Applications folder, I have a TorqueGameBuilder folder with TGB. I also have an iTBG_1_1 folder with iTGB.
The iTGB seems to be getting some settings from the TGB installation.
For example, every time I open iTGB with the "load last project" setting on, it opens the last TGB project. I then cannot load any other project. If the flag is on, and I open iTGB and try closing the project and opening another one, it still reloads the last project I had in TGB. Every time. This is a drag, but I can live with not opening the last project.
However, if I go into TGB and turn off the flag to load the last project, then go back to iTGB and try to open a project, it starts in the last folder opened in TGB. This is a total PITA.
Even worse, the default resolution for the project gets lost on save. Creating a brand new project in iTGB right now starts at 640x480 for me. If I change this to 480x320 for a landscape app, save the level, close iTGB and reopen, the level is 640x480 again. This is just wrong. 1) it should not default to 640x480 for an iPhone tool. 2) it should be able to persist the changes I make in the project.
About the author
#2
03/10/2009 (8:37 am)
You're right. I guess I was just getting ticked off and wanted to throw my own tantrum. 
#3
03/10/2009 (9:06 am)
When 1.2 drops, remove all other instances of TGB and iTGB, otherwise you are going to face similar problems.
#4
03/10/2009 (9:08 am)
So am I not supposed to have TGB and iTGB coexist?
#5
Answer: No, they do not coexist and if they do they are going to fight.
03/10/2009 (9:10 am)
They both try to access the same set of application data folders that are stored on the OS. iTGB was built on TGB 1.7.4, so there is not much reason to have TGB installed as well.Answer: No, they do not coexist and if they do they are going to fight.
#6
03/10/2009 (9:12 am)
Ah. This point may clear up some of my frustration. 
#7
I don't intend to use iTGB for desktop development as I expect iTGB to get iPhone required optimizations added which will make it pretty much unusable on the desktop as the iphone GPU works elementally different.
03/10/2009 (10:05 am)
Can this error in the data path please be solved with the next release then?I don't intend to use iTGB for desktop development as I expect iTGB to get iPhone required optimizations added which will make it pretty much unusable on the desktop as the iphone GPU works elementally different.
#8
The system internally handles OS rendering, input, audio, etc via the global variable $platform.
03/10/2009 (10:09 am)
@Marc - The way the platform layers have been set up will not affect desktop development. Just to be safe, you can disable the preproc definitions.The system internally handles OS rendering, input, audio, etc via the global variable $platform.
#9
03/10/2009 (1:32 pm)
One of the changes that will be in 1.2 is different settings folders are usedfor iTGB, and the default resolution has been changed(setting the proper res for portrait/landscape will be a one-click deal).
#10
Why do you use compiler flags if the iphone os codeblocks that are added are as broken, inoptimal and slow as the TGB code they replace.
What I'm talking about is for example the totally iPhone unfriendly t2dSceneObject renderObject code (and the renderObject code of any descendant class), which in 1.1 floods the iphone GPU to death by creating single quads for each scene object and therefor distinct vertexarrays. This even holds for the particle emitters and tilemap layers where every quad (particle, tilefield) is an own vertexarray. I've to say that I was more than shocked to find out that even there the plain stupid TGB approach was continued, althought especially those two cases would be simple to fix.
That just can not be meant serious for a technology that is advertised as professional iPhone technology.
TGB only runs usefully because PCs are totally overpowered. this shows up very well on systems which are not overpowered or where the drivers do not compensate for the inexistant optimization in TGB, where TGB nearly dies and becomes totally unusabled.
Its really no wonder that iTGB games like the behavior shooter suffer that badly performance wise even thought there are only very few polygons and even less textures alive.
The iphone accepts a few dozen distinct vertexarray before the performance drops seriously, because there is no spare CPU power for the graphics driver to solve your broken rendering code as on the pc.
I expect that this massive missbehavior in the rendering handling is handled as top priority issue and is finally solved.
Batch rendering is not an option but a basic requirement on the iphone and thats pretty much known.
Even the OpenGL ES base specifications point out why things like Quads and alike do not exist on those devices. I can't understand how a professional game render technology developer like GG failed to realize that even by now although different parts of that have been mentioned several times in the past 4 months.
Its exactly this kind of stuff which I meant when I said that I don't understand why I should show your logo in a iTGB game if I have to do your work and make it an iPhone technology myself.
03/11/2009 (4:27 am)
Michael: I fail to see how the platform code helps to compensate for the totally anti iphone rendering handling of TGB / iTGB 1.1Why do you use compiler flags if the iphone os codeblocks that are added are as broken, inoptimal and slow as the TGB code they replace.
What I'm talking about is for example the totally iPhone unfriendly t2dSceneObject renderObject code (and the renderObject code of any descendant class), which in 1.1 floods the iphone GPU to death by creating single quads for each scene object and therefor distinct vertexarrays. This even holds for the particle emitters and tilemap layers where every quad (particle, tilefield) is an own vertexarray. I've to say that I was more than shocked to find out that even there the plain stupid TGB approach was continued, althought especially those two cases would be simple to fix.
That just can not be meant serious for a technology that is advertised as professional iPhone technology.
TGB only runs usefully because PCs are totally overpowered. this shows up very well on systems which are not overpowered or where the drivers do not compensate for the inexistant optimization in TGB, where TGB nearly dies and becomes totally unusabled.
Its really no wonder that iTGB games like the behavior shooter suffer that badly performance wise even thought there are only very few polygons and even less textures alive.
The iphone accepts a few dozen distinct vertexarray before the performance drops seriously, because there is no spare CPU power for the graphics driver to solve your broken rendering code as on the pc.
I expect that this massive missbehavior in the rendering handling is handled as top priority issue and is finally solved.
Batch rendering is not an option but a basic requirement on the iphone and thats pretty much known.
Even the OpenGL ES base specifications point out why things like Quads and alike do not exist on those devices. I can't understand how a professional game render technology developer like GG failed to realize that even by now although different parts of that have been mentioned several times in the past 4 months.
Its exactly this kind of stuff which I meant when I said that I don't understand why I should show your logo in a iTGB game if I have to do your work and make it an iPhone technology myself.
#11
@PC game vs iPhone game - I've tested this myself, and I know I can create a fully functional (non-broken) TGB game which runs on a desktop using the iTGB release. As I said before, currently the iPhone platform is treated similarly to the other OS options which is how the engine runs on multiple platforms.
@Rendering Code - Not my area of expertise, as it was developed by Paul and his team.
03/11/2009 (9:48 am)
@Logo - Because of the license you agreed to upon purchase.@PC game vs iPhone game - I've tested this myself, and I know I can create a fully functional (non-broken) TGB game which runs on a desktop using the iTGB release. As I said before, currently the iPhone platform is treated similarly to the other OS options which is how the engine runs on multiple platforms.
@Rendering Code - Not my area of expertise, as it was developed by Paul and his team.
#13
But the license covers iTGB, which is not will be used. It would be something that I have to create using iTGB as the initial base of it to get the iPhone targeted technology I payed the $500 for 6 months ago.
I already mentioned that several times but will do so again: I couldn't care less if I can create fully functional desktop games with iTGB. My reason to use it is to create performant 2D iPhone games, which is the very thing it currently fails to do.
Because the only thing it creates thats performant is a desktop game, the iphone code is by far not performant for the platform it is meant to run on. It only works because all are aware that it is that dead slow that nobody really tries to push even complex simplistic stuff through it. With the hard but fair reputation that iTGB already has on the web as "instable and slow technology", I struggle to see why there is a focus on iTGE instead of first getting iTGB optimized, as it is far simpler in 2D than it is in 3D. Also estabilishing the brand iTorque is likely of great importance to you I assume so you should see that you get some real games on the store. Games that use the tech without modifying the underlying engine code, games that only optimize it through using Components.
Would it be possible to get a quote by someone who did and does the decisions on the rendering related code on why it was done in the way it is done, if there is a specific reason related to the rendering that enforces it?
I've theories but I want to know the real reasons.
I also would like to give clear quotes on what I see as things that have to change in iTGB to get really good performance, those points will also show why I commonly bring up the point that iTGB should focus on beeing an iphone tech instead of beeing a TGB -> iPhone deployment path.
1. A single tile layer can only use 1 texture. That allows to batch render the whole tile layer as one vertex array instead of numOfTiles in view distinct quads. a single 256x256 can hold up to 64 tiles, more than enough, so there definitely should not be any problem.
The editor could even support several textures and then combine the required tiles at build time into a dynamic layer texture for example or having the iphone game do that. Packing code is already present so this should be trivial, its the dynamic asset loading that needs to adapt to it.
2. The media handling, especially dynamic load and unload, need to be optimized / fixed. It seems to share the position as "bad poor child" together with the physics.
If I enable dynamic load and unload I expect that the media is loaded as the first object using it is created and expect that it is gone when the last object using it is destroyed. Templates must not affect this load & unload system, that means that templates will not trigger a texture load / unload.
I like the features TGB has and I would really love to see iTGB to become an as powerfull technology for the iPhone, because it is flexible and for its purpose, 2D game development, it would really shine if it worked iPhone friendly.
Thats why I invest the time I do in answering questions and pointing out the problems. If I just hated it I wouldn't spend 30+ mins on a posting like this one here.
But as you also see, I can get pretty harsh as well from time to time, commonly after I worked with the sources and struggle upon things where my the only possible thought is wtf. I'm by no means an AAA expert C++ developer, but I am able to identify algorithmic bottlenecks & deadends as well as graphical suicide attempts and I assume the same holds for the GarageGames developers from my experience the past years.
03/11/2009 (1:59 pm)
I'm aware of the license.But the license covers iTGB, which is not will be used. It would be something that I have to create using iTGB as the initial base of it to get the iPhone targeted technology I payed the $500 for 6 months ago.
I already mentioned that several times but will do so again: I couldn't care less if I can create fully functional desktop games with iTGB. My reason to use it is to create performant 2D iPhone games, which is the very thing it currently fails to do.
Because the only thing it creates thats performant is a desktop game, the iphone code is by far not performant for the platform it is meant to run on. It only works because all are aware that it is that dead slow that nobody really tries to push even complex simplistic stuff through it. With the hard but fair reputation that iTGB already has on the web as "instable and slow technology", I struggle to see why there is a focus on iTGE instead of first getting iTGB optimized, as it is far simpler in 2D than it is in 3D. Also estabilishing the brand iTorque is likely of great importance to you I assume so you should see that you get some real games on the store. Games that use the tech without modifying the underlying engine code, games that only optimize it through using Components.
Would it be possible to get a quote by someone who did and does the decisions on the rendering related code on why it was done in the way it is done, if there is a specific reason related to the rendering that enforces it?
I've theories but I want to know the real reasons.
I also would like to give clear quotes on what I see as things that have to change in iTGB to get really good performance, those points will also show why I commonly bring up the point that iTGB should focus on beeing an iphone tech instead of beeing a TGB -> iPhone deployment path.
1. A single tile layer can only use 1 texture. That allows to batch render the whole tile layer as one vertex array instead of numOfTiles in view distinct quads. a single 256x256 can hold up to 64 tiles, more than enough, so there definitely should not be any problem.
The editor could even support several textures and then combine the required tiles at build time into a dynamic layer texture for example or having the iphone game do that. Packing code is already present so this should be trivial, its the dynamic asset loading that needs to adapt to it.
2. The media handling, especially dynamic load and unload, need to be optimized / fixed. It seems to share the position as "bad poor child" together with the physics.
If I enable dynamic load and unload I expect that the media is loaded as the first object using it is created and expect that it is gone when the last object using it is destroyed. Templates must not affect this load & unload system, that means that templates will not trigger a texture load / unload.
I like the features TGB has and I would really love to see iTGB to become an as powerfull technology for the iPhone, because it is flexible and for its purpose, 2D game development, it would really shine if it worked iPhone friendly.
Thats why I invest the time I do in answering questions and pointing out the problems. If I just hated it I wouldn't spend 30+ mins on a posting like this one here.
But as you also see, I can get pretty harsh as well from time to time, commonly after I worked with the sources and struggle upon things where my the only possible thought is wtf. I'm by no means an AAA expert C++ developer, but I am able to identify algorithmic bottlenecks & deadends as well as graphical suicide attempts and I assume the same holds for the GarageGames developers from my experience the past years.
#14
Flagging this as resolved.
05/08/2009 (7:03 pm)
1.2 has been released. The 1.2 Release Details thread mentions the fix and instructs you on how to start cleanly.Flagging this as resolved.
Torque Owner Ee
They promised that it should be fixed by 1.2, so the only advice I can give you is to wait and pray that it'll be 100% fixed.