C++ equivalents to TorqueScript
by baylor wetzel · in Torque Game Builder · 08/02/2009 (4:11 pm) · 6 replies
In the iPhone forum, the consensus is that you should use C++ rather than TorqueScript for most things (iPhones being a bit slower). So i'm going to try that with our game (which is both PC and, hopefully one day, iPhone)
Is there a guide on how to do in C++ things one often does in TorqueScript?
The most important one to me is creating an object. In TorqueScript, you could do something like:
(made the code up, could have gotten some of the names wrong)
Another thing that might be important is event handling, specifically things like onLevelLoaded and onMouseDown. That might be less important, though, in that i could always have the events in script calling the event handling code
Is there a guide on how to do in C++ things one often does in TorqueScript?
The most important one to me is creating an object. In TorqueScript, you could do something like:
%image = new t2dImageMap() { image = "myImage"; };
%sprite = new t2dStaticSprite() { imageMapName = %image; };
$imageSimSet.add(%sprite);(made the code up, could have gotten some of the names wrong)
Another thing that might be important is event handling, specifically things like onLevelLoaded and onMouseDown. That might be less important, though, in that i could always have the events in script calling the event handling code
About the author
#2
i need to be able to delete objects (technically, i need to be able to free memory; a related question on how to do this is in the iTGB forum but was never answered :( ). Specifically, i have a lot of graphics and need to be able to unload pictures when i go to a new level (more important on the iPhone than PC but still probably important). My thought was to create an image manager that does lazy loading and unloads on command. i now know how to create a t2dImageMapDatablock in C++. i assume creating it makes it available to the t2dStaticSprites. i can delete the image the standard C++ way
When i delete my t2dImageMapDatablock in C++, do i need to tell some other system about this? For example, is there an object manager in TGB that i need to unregister the object with?
08/02/2009 (6:33 pm)
OK, so in many (all?) instances, call ConsoleObject::create("className"). And i see now that the T2D folder in VC++ has the names of all the objects i'm thinking ofi need to be able to delete objects (technically, i need to be able to free memory; a related question on how to do this is in the iTGB forum but was never answered :( ). Specifically, i have a lot of graphics and need to be able to unload pictures when i go to a new level (more important on the iPhone than PC but still probably important). My thought was to create an image manager that does lazy loading and unloads on command. i now know how to create a t2dImageMapDatablock in C++. i assume creating it makes it available to the t2dStaticSprites. i can delete the image the standard C++ way
When i delete my t2dImageMapDatablock in C++, do i need to tell some other system about this? For example, is there an object manager in TGB that i need to unregister the object with?
#3
If you really intend to go for the iPhone, I would start doing so as early as possible through the process as you stand much better chances that it will:
1) run at all on iTGB
2) run with acceptable performance on the iPhone
assuming that you can do it on TGB and then just move over will pretty surely put you in a very unpleasant position, at worst you will do it twice.
Also the things mentioned here would still be done through script likely. you do the calc on the C++ end, not the basic setup ... (its a large pain with little gain)
08/02/2009 (6:34 pm)
There are things though you won't be able to do the iphone way on the desktop just because those iTGB related things (different additions and a few optimizations) are not present at all.If you really intend to go for the iPhone, I would start doing so as early as possible through the process as you stand much better chances that it will:
1) run at all on iTGB
2) run with acceptable performance on the iPhone
assuming that you can do it on TGB and then just move over will pretty surely put you in a very unpleasant position, at worst you will do it twice.
Also the things mentioned here would still be done through script likely. you do the calc on the C++ end, not the basic setup ... (its a large pain with little gain)
#4
In my case, though, i haven't been able to get the iPhone version working at all (it's been really bad; the debug version in Xcode refuses to run, the release version won't compile, the iPhone hangs and there's no way we know to get error messages, we're fairly sure we're out of texture memory but can't figure out how to unload objects, iTGB and only iTGB causes my PC to reboot, etc.). We have a deadline and frankly my lack of knowledge of the mac and Xcode, combined with the rough start iTGB's had and the fact that apps have to be written fairly differently for iTGB (in TGB, it's easy to write an app without modifying source; in iTGB, modifying the engine is often necessary) means that we've decided to stop iPhone development for now, focus on the PC and in a couple of months check back on the iPhone (hopefully by then iTGB 1.3 will be out, maybe even based on the new T2D source). Frankly, we're productive in TGB right now making games and we're not in iTGB. Once we conquer the hefty learning curve, maybe, but not right now - we're spending time on tech, not games
So we (now) know it won't be as easy as recompiling in iTGB (i remember the days 3 months ago when we believed that) but time limitations being what they are, we're going to make the PC game now with an eye on the iPhone (hence the texture/memory manager here; memory was our biggest problem on the iPhone) and worry about the iPhone port after December
08/02/2009 (6:57 pm)
Marc, that's excellent advice. We've already hit problems with resources such as music (ogg vorbis not working on the iPhone, mp3 not working on the PC) and art (shrinking to fit in memory on the iPhone makes it look awful on the PC). We have the standard frame rate problems. Our UI approach didn't work on the iPhone (where our buttons were to hard to read or push; sizing them correctly on the iPhone makes them look ridiculous on the PC). And obviously the PC version can't use the iPhone-specific feature (e.g., multi-touch and acclerometers)In my case, though, i haven't been able to get the iPhone version working at all (it's been really bad; the debug version in Xcode refuses to run, the release version won't compile, the iPhone hangs and there's no way we know to get error messages, we're fairly sure we're out of texture memory but can't figure out how to unload objects, iTGB and only iTGB causes my PC to reboot, etc.). We have a deadline and frankly my lack of knowledge of the mac and Xcode, combined with the rough start iTGB's had and the fact that apps have to be written fairly differently for iTGB (in TGB, it's easy to write an app without modifying source; in iTGB, modifying the engine is often necessary) means that we've decided to stop iPhone development for now, focus on the PC and in a couple of months check back on the iPhone (hopefully by then iTGB 1.3 will be out, maybe even based on the new T2D source). Frankly, we're productive in TGB right now making games and we're not in iTGB. Once we conquer the hefty learning curve, maybe, but not right now - we're spending time on tech, not games
So we (now) know it won't be as easy as recompiling in iTGB (i remember the days 3 months ago when we believed that) but time limitations being what they are, we're going to make the PC game now with an eye on the iPhone (hence the texture/memory manager here; memory was our biggest problem on the iPhone) and worry about the iPhone port after December
#5
there are a few common reasons for that, the most common one beeing that you didn't compile TGB and TGBGame with the same compiler defines as the iphone (if you use script_optimize then you must have both PUAP flags set and rebuild tgbgame and tgb, and then copy tgbgame over to the project from the corresponding tgb subfolder) should you want to be able to test it standalone.
running it with that flags is a must, otherwise the scripts are compiled against the wrong core and will just crash it on the iphone as no cs, uft, t2d compilation happens on the iphone, all must happen on the mac / win side
08/02/2009 (7:16 pm)
As for not beeing able to get it to run at all: would post on that on the itgb boards, should you decide to give it another go :)there are a few common reasons for that, the most common one beeing that you didn't compile TGB and TGBGame with the same compiler defines as the iphone (if you use script_optimize then you must have both PUAP flags set and rebuild tgbgame and tgb, and then copy tgbgame over to the project from the corresponding tgb subfolder) should you want to be able to test it standalone.
running it with that flags is a must, otherwise the scripts are compiled against the wrong core and will just crash it on the iphone as no cs, uft, t2d compilation happens on the iphone, all must happen on the mac / win side
#6
Creating and destroying t2dsceneobjects all the time is a pretty performance impacting operation on the iphone.
08/02/2009 (7:37 pm)
Before I forget it: one of the most important things you will likely add for iphone usage is object pooling.Creating and destroying t2dsceneobjects all the time is a pretty performance impacting operation on the iphone.
Associate Phillip O'Shea
Violent Tulip
To edit the properties of the object you will need to call the methods by hand, or just edit the fields:
Obviously using the direct method is a better way of updating the properties of an object, as it is much faster.