[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A question to everyone...

"Adam D. Moss" wrote:

> Does anyone have experience with taking a GCC+OpenGL+Linux
> game over to MacOS and Win32?  Is GCC a workable solution
> on MacOS[X] and Win32 in conjunction with OpenGL

There is no problem at all in porting games (GCC or otherwise)
from Linux to Windoze - so long as you use one of the porting
layers (SDL, PLIB, GLUT, FLTK, etc) that hides the calls to
the underlying windowing system.  GLUT+PLIB is known to work
on Linux, Windoze, MacOS-9 and MacOS-X...I would expect the others
to be able to do that too - but be sure to check before you
commit to using them.

You also need a cross-platform audio solution.  My own PLIB
does that for fairly simple requirements - or you could look
at OpenAL.  I don't know enough about SDL to speak to it's
audio portability - it's probably OK.

OpenGL is absolutely standard between all platforms (although
the Windoze version is OpenGL 1.1 with all the 1.2 and 1.3 stuff
added as extensions by the driver writers).

GCC exists on both Linux (as 'gcc') and Windoze (as 'Cygwin')
and it's pretty much identical on the two platforms.

If you use the (free) cygwin setup on your windoze machine,
you can even run the Linux configure mechanism pretty much
unchanged and you get almost all of the glibc functionality
so you can call 'sleep' instead of 'Sleep' and so on.

If you use MSVC under Windoze, there are a few nasty compiler
differences that bite you - but nothing that an hour's work
won't fix.  The worst (if you are writing C++) is:

   for ( int i = 0 ; i < 10 ; i++ )
   { whatever }
   for ( int i = 0 ; i < 20 ; i++ )
   { whatever_else }

...will get you a 'multiple definition of i' error under MSVC,
but the alternative:

   for ( int i = 0 ; i < 10 ; i++ )
   { whatever }
   for ( i = 0 ; i < 20 ; i++ )
   { whatever_else }

...will not compile under G++ (correctly BTW).  So you have to
fall back on:

   int i ;
   for ( i = 0 ; i < 10 ; i++ )
   { whatever }
   for ( i = 0 ; i < 20 ; i++ )
   { whatever_else }

...yuck.  This can *possibly* get you into trouble:

   int i = 1234 ;

   for ( int i = 0 ; i < 10 ; i++ )
   { whatever }

   if ( i != 1234 )
     printf ( "Welcome to the *wonderful* world of MSVC!\n" ) ;
     printf ( "GCC is good.\n" ) ;

...prints different things depending on whether you compile with GCC/Cygwin
or MSVC.

Using Borland C compilers under Windoze seems to cause endless difficulties.
Even though Borland have announced that they are releasing their compilers
under Linux, I wouldn't touch them under Windoze.

MacOS-9 is considerably harder to deal with - everything about
it is weird - you'll really need a MacOS expert to help you port

Mac OS-X is basically just BCD with a Mac-ified windowing system.
Problems include things like that they moved all the header files

Mac's also have opposite byte ordering to PC's - although if you
are doing a good job of writing a Linux game, you should already
have dealt with that (Linux != PC).  Mac users almost never seem
to own joysticks - so make sure your game has good keyboard/mouse
controls and nobody seems to know how to interface them.

Also, if you are reading text files, remember that lines end in
'\n' under Linux, '\r' under MacOS and '\r\n' under Windoze. <grrrr>
However, I generally open *all* files for reading with "rb" and
for writing with "wb" and use Linux-style line endings on *all*
platforms.  That's OK for your own game files, high score tables
or whatever.  The only place you may have problems is with files
that your end user can edit with whatever funky text editor they
may have.  Then you'll find your '\n's being replaced with who-knows-what
combinations of \n and \r.   I advise you to treat any character
with codes less than or equal to ASCII ' ' as 'white space' and
devise file formats that don't depend on newlines.

> (ie. on Win32 is there a distinction between a 'developers
> OpenGL' and a 'runtime OpenGL' where the former comes
> as some horrible VC++-specific binary lump)?

I don't think that's a problem with Cygwin - it's not a problem
if you bought MSVC either.

> Err, another question -- how does one get hold of the
> appropriate headers for OpenGL development on Win32 or
> MacOS?

You can download them from www.opengl.org

>  I presume that they don't come with the libraries
> themselves like they typically do on UNIX.

Get Cygwin - I think that solves all those problems.

>  I know that
> SDL now includes a 'universal' GL.h -- was this in
> answer to that question?

I don't know about that - but the universal gl.h that's on
www.opengl.org is the "right" one to use because it's updated
to reflect all the latest OpenGL extensions and follows the
OpenGL ABI for Linux.  It also works for Windoze.  MacOS needs
it's own headers - things are *weird* in Mac-land.

Well, if you are trying to cross-compile for Windoze under Linux,
you have some considerable difficulties to surmount.

* If you are writing a commercial game - just suck it up and buy
  a Windoze machine to do compiles on.

* If you are writing an OpenSource game - wait for a windoze
  enthusiast to show up on your mailing list - they'll have no
  problem fixing any problems that show up.

* If you are writing closed source freeware then you have a problem -
  but I have little sympathy!

I know that the FlightGear team have successfully built a copy of
their package (and hence my PLIB libraries) on a Linux PC and run
the resulting binary on Windoze machines - so I know that it's possible
with the right combinations of cross-compilers build into GCC.  However,
to do it legally, you have to own a copy of Windoze in order to get all
the library and header files that you'll undoubtedly need.

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net