Hello.
I want to code using c++/opengl. I mostly want to code for windows, but: how should I organize my code, or more precise, how should an architecture of my program look if I want to be able to easily convert my c++/opengl program from one platform to another ?
Thanks.
write your program under linux.
so, by programming under linux, my programm will be more “cross-platform”. I want my programs to work under windows, and also do conversions to the uder platforms. You are saying that by programming under linux I can achieve that , right?
Originally posted by Tetsuo:
so, by programming under linux, my programm will be more “cross-platform”. I want my programs to work under windows, and also do conversions to the uder platforms. You are saying that by programming under linux I can achieve that , right?
This is definetly FALSE.
There are various ways to have portability. The one I raccomand is to use SDL. GLUT is much more basical, I would say there’s no point in using it.
The other way is to use syscalls which are OS-specific and then wrap them around. In this case, you really want to start with win32 and THEN port to linux. Why? Because the linux cake is still to small to be interesting when compared to the win32 cake. There are also other issues i’ve stumbled across while developing on linux but this is The Primary Reason to start from win32.
Unless you need advanced functionalities, you really want to stay happy with SDL.
You can, as you can too with programming under Windows: it mainly depends on how you program, what are your habits, what you know, how you respect main standards and so on. It also depends on which OS you target on.
For beeing portable, Linux is a good starting point because it is Unix and Posix compliant, almost all other Unicies will compile generally fine: one Makefile and only single source code.
But if you’re not familiar with that, that might not be the fastest solution just because everyone needs time to understand.
If you start with Windows, with some specific compiler, you’ll generally find that your sources might not compile under Unix or even MacOS without having several changes. More, if you managed your program around the W32 API, you’ll go into several non-compatible stuffs.
Again, if you’re not familiar with Linux, that might effectively not be the best solution. But remember that few codes compile from one OS to another one, almost if they’re effectively different (Windows and Linux, Linux and Mac…).
You can, and it’s fine, choose portable libraries like effectively SDL or glut. This is obvious. But using portable libraries doesn’t mean that you make portable code. But as you spoke of architecture, I think you’ll simply forgot glut.
Hope that helps.
As a general rule, wrap “everything”. Be modular. Don’t use non-portable elements in the middle of your code - centralize it so that you only have to change things in one place when porting your code.
It is also important to know what is portable and what’s not.
Plain C/C++ code is usually portable. Here it can be useful if you can use a compiler that works on all your intended target systems, such as GCC. If not, make sure that both your code and your compiler(s) follow the same standards.
Standard functions/classes (such as string manipulation, file handling etc) are less likely to be portable. Once again, check how well your compiler environments support these standards.
OS functions are almost always not portable (except if you find some nice wrapper library that you can use - e.g. a POSIX thread library for Windows). Functions that are often OS specific are file handling, timing, graphics, sound, input, threading, memory management, etc. For most (if not all) of these things you can usually find nice portable libraries that make your code more portable.
I still remember porting Doom I/II from the open source Linux port to AmigaOS. ID Software did a very nice job making the source code very portable (taken that writing cross-platform games was something pretty rare back then). Everything that was considered non-portable (i.e. system specific) was put in sepearate modules, making the porting work easy.