How to make games cross platform?

Greetings,

I would like to know how exactly i can make my game cross platform?
Do i just get a mac + linux on virtual machine, compile my code with these versions of BlitzMax, and thats it?
Or do i need to add all kinds of fancy stuff?

Im currently only using Max2D DX7 and OpenGL drivers for Max2D.

There's not a massive amount to it.

Use Max
Use .png for your graphics
Don't use system specific dlls or command line calls
I had no problem just letting Blitz choose the gfx driver
If you're reading and/or writing binary files, choose either big or little endian and stick to it
Yeah you need to compile the code on the target architecture. Not sure if anyone's tried it with virtual machines.

You'll need to definitely support OpenGL because Mac and Linux don't have DirectX - but you could give Window's users the DirectX option.

You will of course have to use BlitzMax as Nomen said.

It doesn't matter what format you use for your graphics but PNG is good especially if you like to preserve the full quality of your graphics.

You can't use any dll's whatsoever unless it's your Windows version. You can look at using the ? compiler directive to make pieces of your code compile specifically for a given platform. Note that Mac has both X86 and PPC.

You need a machine with the o/s on it for each o/s that you want to make an executable for. Depends what you go with but for example on a Mac you can run OSX + Linux + Windows and make binaries for all three, whereas on most PC's you could do Windows + Linux. You just have to have the o/s installed and be IN that o/s to compile. Also if you want to compile for PPC Mac at the moment it seems you need a PPC Mac, you can't do it from an Intel Mac.

I don't think there's a lot more that you have to do specifically to make things work on all three platforms unless you start to do things with storing files to a user's folder or something like that which is o/s specific. Also if I recall there may be some case-sensitivity in filenames and certain characters which are not allowed, that type of thing. But in terms of behavior `within` the BlitzMax environment everything should work as soon as you compile it.

BlitzMax is actually pretty good at being compatible cross-platform without much modification. I was able to get a smallish application running right away just be compiling it on Windows with no changes to the code at all.

Hey guys, thank you very much for the support! Sounds very good.

Whats with the big or little endian tough? I heard of it before but have no idea what it is really. I also now Windows uses big endian.
I happen to be reading and storing files in the game folder. Should that be a problem? I write binary (bytes).

I believe the only problem is say you write a file on the PC (say like a level made with your own level editor) and then you read the file on a Mac it won't read in properly because the integers will be stored in the wrong order for the OS.

It's actually that the bytes are in the opposite order, not the integers, but yeah.

What? That is so messed, I am definitely going to have a problem there eventually. So you're saying that if I write a text file on a PC, that file won't be read correctly when I port the game to Mac?

Um, not quite.

I forget which platform does what but one of them is little-endian and one of them is big-endian. In other words, one of them writes the four bytes that are a part of an integer as byte3 byte2 byte1 byte0 (normal) and the other write it as byte0 byte1 byte2 byte3 which of course means that you have bits 7..0 followed by 15..8 then 23..16 then 31..24, which is obviously a bit weird. If you were to write data to a file (other than purely byte data values) on one platform and then read that file in on the other platform the other platform would basically rearrange the data and scramble your numbers.

How you *prevent* this is you force the read/write stream(s) to be one specific `endianness`. All you have to do is decide on an `endianness` and then specifically convert all of your read or write streams to that `end`. So long as you set the stream to be a specific endianness before you do any reading or writing, it will force the data to be read/written in a specific byte order. So long as you use the same endinaness for reading the data as you use for writing it the format won't get scrambled. It really just comes down to one single command but I forget the exact syntax.

With other words, scrap the streams, and use BIG or Little endian streams isntead?

You don't have to scrap the streams at all, just make sure you define them as one of the endian's.

Oh okay, I'd already read about the endian thing in other threads, I thought what was brought up here was something new. Thanks for the info!

PPC uses Big Endian, Intel uses Little Endian, therefore if you are using an Intel Mac, a binary data stream will appear the same as one on Windows.
Interestingly, images internally on the Mac are of the same byte order on PPC and Intel..


Not entirely true. As was mentioned above, you can run some of the OSes in a Virtual environment, to build/test you apps that way.
I have both XP and Linux running in a VM on my Intel Mac, which I use to build modules for release to those platforms as well as testing. No problems whatsoever.

As for the PPC/Intel Mac thing, I believe it is possible to run the PPC BlitzMax on Intel and have it compile PPC code - although I haven't tried it yet, I don't see why it wouldn't . Since I already have a PPC laptop it hasn't been top priority for me to get it working.

But even if you're running in a virtual environment you're still actually running within that o/s to make the exe, and I think I was quite careful not to say that you need the hardware in order to make it work, knowing that you can run different os's on the same hardware in different ways.

I think the PPC thing is not easy to do, or at least haven't heard of anyone able to do it so far from an Intel Mac. Something to do with xcode versions and all that.

[quote]It's actually that the bytes are in the opposite order, not the integers, but yeah. [quote]Yeah I know that, the 32bit integer (4 bytes) is stored one way on the Intel chips and this is the wrong way (backwards) for PPCs. Using streams with just text files (which I often do so they can be edited manually if need be) is totally safe (although I wonder about Unicode files which store each char as 2 byes - anyone know (I could test it at some point but not right now)).

So instead of using an TEndianStream I think you can just put "littleendian::" before the filename you are reading in and then it knows what to do. This is best if most of your development is done on a PC.

So, by just putting "littleendian::" or "bigendian::" before all my file streams that use the OpenStream command, i have this problem solved? And you suggest "littleendian::"is there a reason for that? Windows uses "bigendian::" , i can use "bigendian::" instead too, right?

x86 uses littleendian, doesn't it? In which case I would go for this and optimise for the latest Macs and PCs.

X86 is little, PPC is big and a large chuck of the installed user base on Mac is still PPC.

and half of that large chunk will not have serious fun with BM due to the missjudgement of Apple on "3D hardware even on the home user machines is needed" ... ie 16 - 32MB VRAM "3D cards" till the X86 Apples came.
hard to target that market as it is not possible to find such a crappy card for Windows systems, even if you have intel onboard ...