Preping for cross-platform development
So about a week ago I started thinking. Being that we are going to remake The Sphere and Claudius with OpenGL, why not take it a step further and provide cross-platform support to all those *nix systems out there? I mean, it seems like a pretty cool idea and it would allow us to gain a lot of experience, scars, and (hopefully) customers. Plus it would be cool to show some love to the undervalued Linux community. With this idea stuck in my head, CJ and I went on a search for all the different applications and code stuffs that we will need to undertake this task and work cross-platform effectively. I also started reading a bit into OpenGL and all the stuff that it includes (or rather lacks.)
When coming from DirectX, OpenGL can seem a bit…bare I suppose. OpenGL lacks texture loading capabilities, sound playback abilities, input capabilities, and, what gets me the most, it lacks any sort of vector math library. It just seems inane to me to have an API of this sort without a decent math library to help you actually get the graphics on the screen. Still, I suppose this is necessary for OpenGL to be as cross-platform as possible, however painful that may be. Overall though, I love what I have seen of the actual library so far; it feels much more natural and streamlined than DirectX does.
Thankfully, CJ and I were able to get a pretty good list together of all our cross-platform necessities. The first item on the list was the IDE(s) (the application we use to program and compile our programs in) that we are going to be using. I really wish Microsoft Visual Studio was cross platform, because that is what we are both familiar with (I have been using it since the 2003 edition!) and we both just really like it. Instead, we begrudgingly decided to use the next best thing: CodeBlocks (which really is worlds away from the holy grail that is Visual Studio but we don’t have much of a choice.) I’m also looking into using MonoDevelop in case I get a C# fancy while running my newly installed Ubuntu partition.
With that out of the way, we had to pick some software libraries that could fill some of the gaps of OpenGL. CJ suggested I look into SDL for the window management stuff, as it handles all the nasty, extremely gritty, low-level stuff required to create a window. Better yet, it does it all in a cross-platform way, so if you are careful about things you can get a window up and running across multiple platforms. Which, *surprise surprise*, I have already done!
I am trying my hardest to make Claudius as smart as possible when it comes to this low-level stuff. If I don’t set everything up correctly now, it will be nearly impossible to do so once a game has been built on top of it. So far I have got it to where Claudius can return a list of supported resolutions and automatically clamp your resolution request to the bounds of these supported resolutions. It worked fine under Win7, but it failed initially under Linux. Apparently the backbuffer I was requesting had too high a bit depth for the Linux OpenGL driver. My next step then is to make sure the backbuffer parameters are queried and set to something legal if the requested one doesn’t exist. After that, the next significant thing that needs set up is an event system so that buffers can be notified when the device is lost or reset (I assume this can happen under OpenGL) so they can rebuild themselves without user intervention.
For sound we plan to use OpenAL, which seems like it could be a nice replacement to XAudio2. I believe CJ wanted to take advantage of SDL’s media features as well. For texture loading there exists both DevIL and FreeImage, but their licenses aren’t all that clear so this is still up in the air. For general stuff we plan to take advantage of the Boost C++ library, which should prove extremely useful, esp. in the threaded areas of the engine. The math library is something I’m not so sure on at the moment. There is glm, which looks great, but I might end up writing my own library so I can fool around a bit with lady SIMD. For those who don’t know, SIMD is the ability for an x86 processor (an Intel or Intel Clone (AMD)) to execute a single instruction on multiple pieces of data simultaneously. This can be used to make 3D math execute crazy fast. I think it will be a good learning experience.
This was a very long winded post, but I had a lot of stuffs to cover. Hope to see you back next time!