Worth going through the effort with Xcode 2.5?

[monteboyd]

Hi iDevGames!

Some of you may remember me, I developed Slope Rider (http://www.monteboyd.com/) years ago and have slowly slipped out of OSX development since then, doing mostly Flash stuff recently.

Anyway, as with most of us I'm excited about the prospect of developing for the iPhone but before I get to that I'm thinking of bringing Slope Rider up-to-date as a Universal Binary. At this stage I'm still using Tiger and was wondering if there is much point downloading Xcode 2.5 and updating Slope Rider to UB in that environment before eventually upgrading to Leopard and moving up to Xcode 3.xxx at that stage?

Or should I hold off on updating it until I upgrade to Leopard?

I should probably point out that Slope Rider is quite an old beast now and actually uses Carbon - this is probably the main thing that needs changing.

Hopefully I won't drop off the side of planet again and this will actually happen, I'm cautiously optimistic at this stage. ;)

[AnotherJake]

Good to see you again monteboyd! Hope all is going well. :)

I don't think there is anything wrong with building it for Tiger, being as how Tiger seems to still have a solid number of users, but it seems to me that Slope Rider might be a good candidate for a cool iPhone game. Maybe you should forget about Tiger, upgrade to Leopard immediately and get right to iPhone development instead! It seems to me that there may be a good opportunity waiting for you there, and as more games crowd the iPhone market that opportunity begins to diminish somewhat, so Tiger looks like a distraction in that light.

Plus, as time moves on, obviously Tiger will shrink in marketshare. Although that seems like it's happening a little more slowly than previous versions, according to http://update.omnigroup.com/

[monteboyd]

Thanks AnotherJake! :)

Yeah, I was thinking of Slope Rider on the iPhone. I guess I thought it might be a smoother path, maybe less of a learning curve, if I took a more gradual approach. Since this will actually be my first foray into Cocoa. But if you think jumping to iPhone development would be just as appropriate then I might do that. Of course that would mean I won't be able to ask any questions here atm because of the NDA!

[AnotherJake]

I hadn't thought about it in terms of having to learn Cocoa. Yes, working around the NDA is definitely a *major* problem in that case. So then, yeah, I guess it would indeed make sense to go ahead and build it for Tiger and move up from there when you get a chance.

A few things I can think of off the top of my head right now which you will want to keep in mind, in preparation for porting to iPhone later on, which shouldn't be NDA violations:

- You'll likely want to use OpenAL for your sounds. OpenAL comes standard on Tiger, so that's a plus.
- Any background music you will want to do on Leopard using Audio Queues. Use whatever you want on Tiger because I don't think Audio Queues is available there.
- You'll probably want to keep your game code (drawing and updating) in C/C++, so the only Cocoa you'll need will be for basic system needs like file loading (and OpenGL context creation).
- There is a particularly useful image class for use with OpenGL ES, which you can find in the iPhone SDK code samples. You will more than likely want to try to use that on OS X as well (I don't dare say the name of it, but it should be apparent when you find it in one of the OpenGL ES samples). The problem there is that I don't think it will work on Tiger, but it can be easily ported to Leopard. You can do something similar to it for Tiger if you modify it some. I take that back. It should work on Tiger too. I was thinking Panther prolly woudn't work.
- Speaking of OpenGL ES, convert any of your immediate mode code to be using glDrawArrays or glDrawElements, which means your sprites will be done with four coordinate triangle strips instead of quads.
- Can't use the ol' display list trick for pre-rendered font drawing. It's not hard to do something similar using triangle strips instead of quads though.

That should cover a good percentage of porting concerns for Slope Rider, I would imagine. Performance-wise, I'd wager it'll run great on iPhone if you stay at the same level of geometry detail (as when I played it back in the day that is -- haven't seen it in years).

[ThemsAllTook]

I'd strongly advise against Xcode 2.5, as I've run into unresolvable linking issues with it that don't exist in either 2.4 or 3.0 with the same code. Seems to be a broken version, though unfortunately it's hard to find 2.4 anymore, so if you're on Tiger, you're a bit out of luck.

[OneSadCookie]

It's not hard at all to find 2.4.1, it's right there on http://connect.apple.com where you'd expect it to be...

First I've heard of 2.5 issues, care to elaborate?

[monteboyd]

Thanks for all the advice AnotherJake - very helpful!

- Will definitely have to change the audio - I honestly can't even remember how I handled audio before - it's been that long since I've looked at the code - but I don't don't think OpenAL was around at the time and I definitely didn't use it.
- Yeah I was thinking of probably not touching any of the game code I don't have to (just leaving it as C) and just using Cocoa for the things you mention. I assume I'll need to change my events handling as well, since that's still Carbon.
- I think I was using glDrawArrays for most things so that won't be too much of a problem. Although I was using display lists occasionally and they're not available in OpenGL ES as I understand it. But then that's for later down the track since I'm now thinking I will convert to a UB app before getting onto the iPhone.

I was thinking the same thing in terms of performance - it's dated enough now that it should be about iPhone level! Very handy. :)

ThemsAllTook and OneSadCookie - it doesn't really bother me if I develop on 2.4.1 or 2.5 as long as they're both readily available. But I'll be interested to hear if those issues are common.

[KittyMac]

Don't be put off by moving from Carbon straight to iPhone.

I got Pirate Isle (http://www.littlegenerals.com/fe/games/pirateisle/index.html) running on the iPhone in about a week (which was old OS 9/X Carbon code which was last compiling with CodeWarrior). Very little obj-c code is needed if you are already living in an OpenGL world.

[AnotherJake]

Very little obj-c code is needed if you are already living in an OpenGL world.

So true on iPhone... and also especially with things like event handling and context setup on iPhone being dramatically easier, from what I've encountered (*really* fun to program on). Still, there are so many things to learn about basic Cocoa/Obj-C which can't be discussed publicly when learning them on iPhone, though I definitely agree not to shy away from iPhone right off the bat just because of that. Feet wet with it ASAP is a great direction to take.

[monteboyd]

Hmmm... interesting KittyMac. Well the thing is I'd obviously like to learn Cocoa as well, since it would be where I would go in the future for Mac (not iPhone) games, but the thought of diving more quickly into iPhone dev is obviously appealing. I could always see how I go getting Slope Rider up and running on the iPhone as quikcly as I can manage and then going back and giving myself some time to learn Cocoa.

Of course I'll have to buy Leopard first as I mentioned.

I'm off to Sardinia for a week on Sunday so I'll give it some thought while on the beach!

[monteboyd]

Okay, hope you guys are still reading this. :)

I've decided to try to get Slope Rider converted to UB in Xcode 2.5 for the moment. I'm starting with a simple OpenGL view in Cocoa and then building it back up from there. Now I already have a question: if I have a bunch of utility functions sitting in a C file and header (e.g. util.c, util.h) can I include the header file in a Cocoa class and then call those functions from it?

I tried searching this forum for answers to this but have been stumped so far.

[OneSadCookie]

Yes, Objective C is a strict superset of C (unlike C++, though even for C++, it's usually close enough).

[monteboyd]

Yeah, that's what I thought. But when I tried to #include "util.h" in my ObjC class and then tried to use a function I got an undefined symbol error. I don't have the code at hand at the moment, is there anything else I should be aware of to achieve this?

Sorry for the vagueness of this, I've been developing Actionscript for so long I'm a little rusty on C.

[OneSadCookie]

make sure util.c is in the project

[monteboyd]

I added it to the project, but it was late last night, I'll give it a try again tonight. At least I know I wasn't trying to do something impossible now, thanks Keith.

[monteboyd]

I must be missing something here, if I #include "util.h" I get: "unknown symbol '_testFunc'" and a warning: "'testFunc' is used but never defined". But if I #include "util.c" it compiles and works fine. But shouldn't I be including the header file and not the C file? The code for those files are simply:

util.h

static void testFunc();


util.c

#include <stdio.h> /* Header File For Standard Input / Output */
#include <stdarg.h> /* Header File For Variable Argument Routines */
#include <string.h> /* Header File For String Management */
#include <stdlib.h>
#include "misc.h"

static void testFunc()
{
printf("Hello");
}


Is there an Xcode setting I need to change or something?

[OneSadCookie]

You should not #include the .c file. Just add it to your project (and make sure it's ticked for your target, but that should be the default).

[monteboyd]

Yeah that's what I thought I did to begin with. I might just recreate the files from scratch and see how I go.

[OneSadCookie]

oh oh wait.

"static" is *not* what you want. "extern" or nothing in the header, nothing in the .c file.

[monteboyd]

*Slaps forehead*

Of course! Told you I'd been away from C too long. :)

[monteboyd]

Here's an odd one - with my menu screens now showing up I've found the texture coordinates inverted from my old code. Not a big problem - I can flip them easily but I'm still curious as to why this may be?

[OneSadCookie]

Because you changed how they're loaded :p

[monteboyd]

So with one method of loading (either my old one or now with libpng) they are essentially upside-down in memory?

[OneSadCookie]

That would be my guess. Particularly now you've confessed you are using different code ;)

[monteboyd]

Yep, I'm using your SimpleImage wrapper for libpng OneSadCookie. ;) So easy to use so big thanks!

I was using Quicktime to load the textures before.

[OneSadCookie]

SimpleImage loads the image the normal way up for OpenGL (0,0 in lower left). The simplest way to use QuickTime would load upside down (0, 0 in upper left). If you want things back to upside down (no reason why you shouldn't), there's code in SimpleImage to set the row pointers going upward:

unsigned int row;
for (row = 0; row < height; ++row)
{
PNG_rows[height - 1 - row] = PNG_image_buffer + (row * 4 * width);
}

That can be changed to make 'em go downward:

unsigned int row;
for (row = 0; row < height; ++row)
{
PNG_rows[row] = PNG_image_buffer + (row * 4 * width);
}

[monteboyd]

Cool, thanks for the tip.

That's actually a tough decision because I'd like to get into the headspace of thinking about 0, 0 being lower left since it is the mathematical/opengl way of doing things. But on the other hand I'm so used to thinking about 0, 0 being upper left since that is the screen standard that the other way with texture coords might confuse me.

Either way - thanks again, great to know I have options.

[monteboyd]

Okay, another problem.

My old 3D models are stored in the data fork of the model files. This is not the way I would do this nowadays starting from scratch but if I can still load those files with no problems I'd be happy to leave them as is.

I've brought my model loading code across and I don't get any errors but it seems the numbers I'm getting back in the data are a little crazy. For example, a GLuint to store the width of a texture is coming back as 1073741824 when it should be 128.

I was wondering if this could be a problem with big/little endianess?
Or if not, any clues?

[ThemsAllTook]

Looks like an endianness problem, though the numbers don't quite match up... 1073741824 is 0x40000000, while 128 is 0x00000080. In any case, you'll probably want to use something like this for binary file I/O:
#define swapInt32(int32) ((((int32) >> 24) & 0x000000FF) | \
(((int32) >> 8) & 0x0000FF00) | \
(((int32) << 8) & 0x00FF0000) | \
(((int32) << 24) & 0xFF000000))

#if defined(__BIG_ENDIAN__)

#define swapInt32Big(int32) (int32)
#define swapInt32Little(int32) swapInt32(int32)

#elif defined(__LITTLE_ENDIAN__)

#define swapInt32Big(int32) swapInt32(int32)
#define swapInt32Little(int32) (int32)

#endif

You'll just need to use swapInt32Big on each integer as you read it in.

[monteboyd]

Thanks ThemsAllTook, I think the 1073741824 actually should be 64 now if that makes more sense. I did a quick swap on a different integer earlier and it gave me a much more appropriate number so I think that is the problem.

I haven't had a chance yet to implement the swapping for the loading code, will the code you provided work for shorts and longs? Some other code I had researched was using different functions for the different types.

Thanks for the help.

[ThemsAllTook]

It'll work for longs if you're compiling only a 32-bit binary, but a better solution is to use the types defined in stdint.h (uint32_t, etc.) that are guaranteed to be a particular size regardless of architecture. This way, you don't need to think about having a swap function for a short, an int, and a long, but rather having one for a 16-bit integer, a 32-bit integer, and a 64-bit integer.

Something like this should work:

#define swapInt16(int16) ((((int16) >> 8) & 0x00FF) | \
(((int16) << 8) & 0xFF00))

#define swapInt64(int64) ((((int64) >> 56) & 0x00000000000000FF) | \
(((int64) >> 40) & 0x000000000000FF00) | \
(((int64) >> 24) & 0x0000000000FF0000) | \
(((int64) >> 8) & 0x00000000FF000000) | \
(((int64) << 8) & 0x000000FF00000000) | \
(((int64) << 24) & 0x0000FF0000000000) | \
(((int64) << 40) & 0x00FF000000000000) | \
(((int64) << 56) & 0xFF00000000000000))

[OneSadCookie]

you'll need some "ull" suffixes in there I think...

[monteboyd]

Seems to be working for ints of different sizes, thanks. The other issue is floats. I did some searching and found this code from an old iDevGames post:


float floatSwap(char *value)
{
char buffer[ 4 ];

buffer[ 0 ] = value[ 3 ];
buffer[ 1 ] = value[ 2 ];
buffer[ 2 ] = value[ 1 ];
buffer[ 3 ] = value[ 0 ];

return *( (float *) &buffer );
}


Which seems to work alright. Any reason why this would not be an advisable method?
Sorry for all the questions, when it comes to things like endianess and byte swapping the graphic designer/non-programmer comes out in me. :)

[ThemsAllTook]

Should work fine. You could also do a non-converting typecast to uint32_t, swap, then convert back.

float swapMe;
uint32_t temp;

temp = *(uint32_t *) &swapMe;
swapInt32Big(temp);
swapMe = *(float *) &temp;

[monteboyd]

All working now, cheers guys!