TGB to iPhone

#1 It's doable. First you need to redesign for 480x320 (or 320x480 if you like to do it in portrait mode). They're also different aspects, so a little tweaking of the camera ratio is needed.

Graphics should be scaled down, and spritesheets used as much as possible. When you load things might need to be delayed, and you should actively drop unneeded graphics to make room for more.

Next you see where it slows down...everything will be slower, and some scripts will be massively slower. The included source code shows you how to make C++ versions of them.

There are sticky threads in the iTGB forums which give you further information if you buy it.

#2 I can't change the design resolution into (480 x 320) in TGB. it automatically reset into (640 x 480). How can i change it for iPhone.

#3 You can set the iPhone resolutions in iTGB.

#4 Hi Ronny do you mean that if i want to run my game properly on iPhone i'll haveno other choice than to code in c++ ?

#5 That has nothing to do with it. You need iTGB anyway to do the iPhone port, and iTGB's editor supports the smaller resolutions. Import the TGB project into iTGB, adjust resolutions and fix any graphics, then test on the device.

#6

Quote:Next you see where it slows down...everything will be slower, and some scripts will be massively slower. The included source code shows you how to make C++ versions of them.

As somebody planning to upgrade to iTGB in the next few weeks, this comment really worries me.

Are you talking about really complex scripts, or will even the sorts of "simple" scripts in the TGB tutorials be "massively" slower?

Is it significantly harder to drive TGB from C++ instead of Torquescript? I guess I'm thinking that, if it's not, why everyone wouldn't just use C++ all the time?

Thanks,
Lindsay

#7 You'll still use some script to glue things together, but you want to avoid harder math and loops in script. Also stay away from onUpdate() type functions. On a desktop/laptop computer, things are so fast the engine idles much of the time. On the iPhone, you're keeping the CPU completely occupied most of the time.

I'm going to spend some time this weekend to investigate completely ignoring script, just to see what happens. How would framerates be if main.cs and the DSOs didn't even exist? Maybe I'll find out :)

Loading time is slow because of scripts that are loaded one at a time and executed as they're found, and because of datablocks being preloaded before even seeing the menus.

If you defer loading as much as possible, but keep the preload flag on, you load the chunks you need exactly when you need it. The user needs feedback every so often to not think it has crashed, and the iPhone OS has an active watchdog which kills your app if it takes too long not responding.

As evidenced by the AppStore, games are being released based on iTGB all the time. They just need more care and work than on the desktop (bug request #1: Make Game button is still not implemented).

#8 I would like to continue this thread, for I have a few questions:

1. What would you suggest to improvise an onUpdate() function?
2. What do you mean by "harder math"? I have a single script with a LOT of math in it, here is an example:

function convertAngle()
{
      %xSlope = ($dX - $rX);
      %ySlope = ($dY - $rY);

      %temp = ((mRadToDeg(mAtan(%xSlope, %ySlope)) + 90) * -1) + 180; //Get the arctan of the slopes. Then convert it to degrees.
	  $angle = mDegToRad(%temp);
}

I don't plan on using much more math through my game, but is that too much? I need it to process it everytime a player drags their finger on the screen.
3. Let's say I want to turn the main.cs file into a C++ file. What would it look like? Where would it be placed, and what would it be called?

#9 Turn your calculations into C/C++ and expose them as TorqueScript functions. Any math can be hard for scripts, so it doesn't hurt to be prepared :)

Every drag can be many calls - it depends on how much movement starts a new call, or if the calculation keeps running as long as the finger is touching.

I've been digging into the code a bit, and the functions which call main.cs are all over the place. No luck splitting it up yet, and I have other things I want to finish first. Like making my codebase compile or run again ;)

#10 The same as Lindsay really, am looking at getting iTGB in the next month or so once all of my assets have been made, and the comment about needing C++ script is very worrying for me also (scripting I can do, C++ programming i dont think i can).

I was hoping to use TGB and scripting of course to make the game, are people saying this would be way to slow? If thats the case, thats not going to be very good for me at all.

#11 The script conversions aren't all that hard, really. Any "heavy" code can usually translate 1:1 from TScript to C. You're not really writing anything C++ specific beyond making a class and methods, but just plain C. Math and loops of any sort are prime candidates.

There are included examples you can massage. Example dummy component:

class MyWonderfulComponent : public DynamicConsoleMethodComponent
{
	typedef DynamicConsoleMethodComponent Parent;

public:
	//Your methods, variables to hold other iTGB objects etc.
}

After that, define some default methods like in the examples, and wrap any functions you want exposed to the glue scripts in ConsoleMethod() macros. The actual scripts should just pass objects, and the heavy lifting be done by C code.

But first you make the game with script, and like I mentioned in my first post, see where it slows down. You might be lucky and have a nice framerate. Sometimes it's not actually the scripts slowing you down, but some images which were "optimised" by iTGB because they were an odd size (540x540 image "optimised" to 1024x1024, for example). Or maybe you're unloading unnecessarily and reloading constantly. Little, annoying things like that which happen on any mobile platform :)

The problems aren't unique to iTGB; iPhone OS is a platform where 32MB of RAM usage is seen as excessive.

As always, I recommend Bruce Eckel's "Thinking in C++" book(s), because you'll learn the lowlevel C-stuff far too many authors forget in the midst of their fascination with classes and inheritance :)
(It's also a free download, and optional physical tome to purchase!)

#12

Quote:As always, I recommend Bruce Eckel's "Thinking in C++" book(s)

Hey, thanks for that, I need to get the dust off my C++ :-)

Now, talking of C++ ... I'm on a Mac, using XCode ... will I still be using C++, or do I have to use Objective-C?

Thanks,
Lindsay

#13 Still C++ likely
ObjC is something you touch to talk to the iphone API

#14 I was lucky that my game concept is fairly simple. only 10 sprites(like 12 animations) and 5 guis, with no more than 6-8 objects on a level and only one object moves...

all my images for buttons, backgrounds, objects, and guis do not take up any more than 2mb.

I still take a very noticeable hit on the FPS, but I am only coding through script not C++

a note for you to keep in mind:

Is everything needs to be optimized.

- the way you load assets

- loading of levels and guis
- etc ( the rest you will figure out through frustration ;))

@lindsay mostly C++ unless you are making function calls to iphone API's as Marc suggested.

@ronny: i disagree about the problems being unique to iTGB. Other engines seem to preform a bit better than iTGB. The major benefits of iTGB are as follows:

- You get to fix the source files

- you can port your existing TGB game without going from two completely different languages

- the community seems to be more on the ball than some

- easier for your artists /testers to test the game without having to install xcode, or have a mac.

#15 My tip for people considering making an iTGB game is don't try to port a windows/mac game to iTGB. Start with a new design specifically for iPhone. Your game should have as few moving objects and as few collisions as possible. It should re-use graphics often and not require multiple levels. Keep music and large images to a minimum.

#16 I'll follow up on Conor's comment... if your game for PC/Mac is super light on the script and primarily C+, porting is a breeze. I did it with Mini Shogi in a week. If your game is script heavy, however, good luck. I've been porting Xeno Sola for a month!