PDA

View Full Version : Game Programming for multiple OS



mpirkle
10-30-2006, 11:51 AM
Salutations!

My goal is to create a game that will run on all major operating systems. Eventually I plan on having players interact over the internet. I'm working in Microsoft Visual C++.

Is this possibe?
If so, What is required? How do I make an application that is platform independent? Now that I'm thinking about it, java sounds appropriate. Thoughts?

What sorts of things do I need to keep in mind when programming for internet activity? Are there any good resources for beginners?

I know I'm asking a lot. I appreciate your response!

Overmind
10-30-2006, 12:08 PM
About platform independance:

One solution would be using Java or C#. You can use OpenGL with both. Then the program runs without modification directly on most operating systems. Of course then you can't use Visual C++ ;)

Using C++, it's not very hard to write platform independant programs, when you only use platform independant libraries. OpenGL itself is no problem. For creating the window and input/output I would suggest using SDL.

Of course you'll have to compile the game for all operating systems, but it should not be very hard to write the source code so that it works without change on any platform.

For developing, of cource you can use Visual C++. But I would suggest that you get either cygwin or mingw for testing. Better would be a full Linux installation. The Microsoft compiler is not very standards compliant, it's very easy to write a program that will work with VC++ and not with gcc, or the other way round.

Korval
10-30-2006, 01:07 PM
I'm working in Microsoft Visual C++.Not while you're using a compiler that only exists on the Windows platform.

If you're serious about cross-platform development, you need a build system that allows it. This means you should invest in Make, Boost.Jam, Premake, or some other build system that is cross-platform.


The Microsoft compiler is not very standards compliantBoldface lie.

All free Microsoft compilers are very standards compliant. The VCToolkit one and the Visual C++ 2005 Express Edition. Both of them are about as ANSI-C++ as compilers get.

Only the older compilers weren't ANSI-C++. And that's because most of them were written before there was an ANSI-C++.

Overmind
10-30-2006, 11:54 PM
They *support* ANSI-C++, that is, they will compile any ANSI-C++ program. But they will compile programs that contain errors, too, especially when it comes to templates. Mainly to be compatible with their older compilers.

I know, there are compiler switches for 100% compilance. But I wouldn't rely on such things, they also give you only 99%, and you're always going to use exactly that 1% feature that breaks things. Better just test it with more than one compiler.

The same advice applies of course to gcc. If you're targeting both compilers, you should test on both compilers, because both have "extended" the standard a bit.

tesla
11-08-2006, 03:26 PM
Working in MSVC++ is certainly possible, but I don't think I could recommend it. There are essentially three major points to consider when writing portable programs:

1) Libraries

Selecting cross-platform libraries will make the whole endavour much easier. At the moment I think SDL (with support libraries, e.g. SDL_image), OpenAL (if needed) and OpenGL might be the best choices.

2) Code

Writing cross-platform code is mostly a matter of not assuming that everything works the same way everywhere. One way to achieve this is to test your application on different platforms. If it runs on both 32-bit x86 and 64-bit SPARC, it will likely run equally well on any other CPU. Don't forget to test cross-interoperability so that your game running on say x86-32/Windows works with a version running on e.g. PPC-32/MacOS X.

The main sources of problems are in my experience assumptions about endianness, 32/64-bit ints and unaligned memory access.

3) Building

Test your build mechanism on several different platforms if possible. Using a single-platform IDE for building will make it harder to test and might hide false assumptions. (e.g. how dynamically loaded objects can be built. Under GNU/Linux or Solaris a so (dll in Windows) can link against the program loading it, but under Windows those functions have to be moved to an external library)

I hope this helps.