Portable API's?
Author
Hey all,
In my current project, the problem of portability has come up. I want to be able to have my game available on Mac, *nix, and Windows. I am developing on windows, and currently using win32. I ported the game to GLUT, but then realized GLUT only works on linux and windows. I looked up SDL later on and it says it works on everything, so would that be my answer, to use OpenGL and SDL? And for sound would you recommend SDL, or OpenAL. I think you need to use GLUT to init OpenAL, as the initliaze code for it is alutInit();, so I was wondering if OpenAL is only as portable as GLUT. also, is OpenGL/SDL as portable as you can get, or what would you recommend for distributing to different OS's, especially windows and mac.
Thanks,
--Nathan
--
GLUT works with OSX. I believe it includes it's own version, but everything should work just the same.
As for OpenAL and SDL, each can be ported to Mac OSX and Windows. My best advice would be though to worry about getting the game written first before worrying too much about portability. Even Windows to Windows is sometimes not portable if you compile on GCC and try making it on Visual C++. Just keep things loosely coupled, and when you're ready to port, it will be much easier.
As for OpenAL and SDL, each can be ported to Mac OSX and Windows. My best advice would be though to worry about getting the game written first before worrying too much about portability. Even Windows to Windows is sometimes not portable if you compile on GCC and try making it on Visual C++. Just keep things loosely coupled, and when you're ready to port, it will be much easier.
I also wanted to mention OpenAL and GLUT are entirely unrelated. Personally I would use SDL for sound as well. That way you only have to worry about one library working or not.
Quote:Original post by Nytegard
GLUT works with OSX. I believe it includes it's own version, but everything should work just the same.
As for OpenAL and SDL, each can be ported to Mac OSX and Windows. My best advice would be though to worry about getting the game written first before worrying too much about portability. Even Windows to Windows is sometimes not portable if you compile on GCC and try making it on Visual C++. Just keep things loosely coupled, and when you're ready to port, it will be much easier.
I'm not so sure I second that advice. Not disagreeing, but giving it some thought upfront and testing it along the way can keep things from getting to the point it cant be ported without great pains.
Personally I use OpenGL and SDL using windows and linux gcc for my current game and it doesn't need a single line of code changed. Its been helpful for me to do it that way and I would say been a very simple process so far.
Quote:Original post by Goober KingQuote:Original post by Nytegard
GLUT works with OSX. I believe it includes it's own version, but everything should work just the same.
As for OpenAL and SDL, each can be ported to Mac OSX and Windows. My best advice would be though to worry about getting the game written first before worrying too much about portability. Even Windows to Windows is sometimes not portable if you compile on GCC and try making it on Visual C++. Just keep things loosely coupled, and when you're ready to port, it will be much easier.
I'm not so sure I second that advice. Not disagreeing, but giving it some thought upfront and testing it along the way can keep things from getting to the point it cant be ported without great pains.
Personally I use OpenGL and SDL using windows and linux gcc for my current game and it doesn't need a single line of code changed. Its been helpful for me to do it that way and I would say been a very simple process so far.
Fair enough. It's just been my experience that when people worry about small details, and yes, porting is a small detail, they tend to put more emphasis on it than actually getting the project finished.
Having a program structure that includes pure Win API where the actual API is separated from the actual game is going to be far easier to port, even after the game is completely finished, than trying to rely on a cross platform library that tightly couples things. I've personally yet to find one language or major API that is 100% cross platform.
Heck, even 100% valid C & C++ code won't always produce the same results on different machines. And I'm not talking about endian issues, floating point issues, nor Washu's little programing tests of undefined behaviours.
And sometimes, certain features just are not available on different platforms. Why should you have to punish your core audience to allow a minor audience the compatibility of your game?
Quote:Original post by Nytegard
Heck, even 100% valid C & C++ code won't always produce the same results on different machines. And I'm not talking about endian issues, floating point issues, nor Washu's little programing tests of undefined behaviours.
What are you talking about, then?
Quote:For helping people learn how to use source tags:
[source][/source] = [source][/source]
Bah, too complicated. I'll just type [source][/source] ;)
Quote:Original post by ToohrVyk
Bah, too complicated. I'll just type [source][/source] ;)
Sneaky...
Quote:Original post by ToohrVykQuote:Original post by Nytegard
Heck, even 100% valid C & C++ code won't always produce the same results on different machines. And I'm not talking about endian issues, floating point issues, nor Washu's little programing tests of undefined behaviours.
What are you talking about, then?
Note, I only stated undefined behaviours in Washu's tests, not all undefined C++ behaviours!
But seriously, there's another gritty world of C & C++ of the implementation defined behaviour that gets people in trouble.
And before you go stating that some implementation defined could also be undefined, let's take the following program.
#include <stdio.h>int main(){ int i = 5; printf("%d \n", sizeof(i)); }This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
