Games and game development on Linux.

This week I found some time to dabble with development on Linux. The O2 engine and the Doofus game both have been written to be cross-platform with full ANSI C++ compatibility. It was one of the stated objectives when we first began on the development of the engine that it would be portable across platforms. I must admit I have done all the development of the engine under Windows and with Visual Studio Express. However, I do intend to port the engine and the game to Linux and Mac OS’. So last week I fired up the Fedora Core 6 installation just to have a feel of what changes Linux has had over the years.

Its been about 4 years since I did any serious development on Linux and I was kinda surprised that things haven’t changed much. FC6 comes bundled with KDevelop and Eclipse. I tried both and found both to be wanting. I mean I use the free VC Express edition under windows and both these IDEs were nowhere near to even the free version of VC. I had expected more, unfortunately I was disappointed. Then I downloaded Code::Blocks, one of the IDEs that I have a keen interest in because of its close relationship with wxWidgets. The IDE is kinda neat. I am impressed, because I am completely at home on it. It also has a great feature where you can just import VC project files in it, cool! Though it is nowhere near as good as the Pro versions of VC, I found it much better than KDevelop and Eclipse. In my college days I use to program using emacs, but I have gotten lazy over the years, especially after joining the dark side ;)) . I like IDEs and I always hated the Automake system, it seems like too much work.

My next adventure was trying to run a sample OpenGL application. I wrote an application that renders a simple cube on the screen using OpenGL. Hmm.. setting up OpenGL under X is almost as painful as setting it up in Windows. But, after about an hour’s work I was there, only to find that the application’s was running at a measly 50 FPS! I mean, I run my game on this m/c under Windows and it runs at about 40 FPS with everything from stencil-shadows to environment bloom turned on. A simple cube application like this should run at about 1000 FPS. After much searching on the internet, I found that I, in fact, needed to update the display drivers. The application was using default Mesa drivers, which fall back on software under OpenGL. I did download and install NVIDIA drivers and I would like to say its not as trivial as setting the drivers up under Windows, and finally the application ran at about 1000 FPS as expected.

I did dabble more with Linux. Also installed and tried the famous Ubuntu distribution. Did some python programming also and I must say that it was easier to work with than I had expected. As a development platform Linux seems to be a good, I had expected more but it’s not quite there yet. Eclipse seems promising, though it needs some more work. Code::Blocks is good and I am sure the team will do a good job with their upcoming release. On the whole, Gnome and KDE have also grown up, so its kinda nice to see good and fast GUI under Linux. Administration has also become a breeze with so many applications around. There is almost no need to go to the console to get things done, well almost.

As a platform for gaming, it seems to whole another issue. I can see there are a lot of problems that have to be addressed. Why are there no accelerated display drivers on Linux? Even if I did manage to port my game to Linux, for my game to run on a Linux system, the player must download my game first. Then he must download and install NVIDIA/ATI drivers. Then install the game and then finally play it. How on earth do you expect a non techie to do that? I mean I know people who do not even understand what a driver is. Do you expect them to download and install a Linux driver just to play a game! To my surprise, none of the Linux distributions I saw have NVIDIA or ATI drivers, they all have Mesa drivers! Holy cow! I mean Linux is such a great platform for games, but the setup of even the most noted Linux distributions fail to address simple issues. The gaming market is huge and I am very very surprised that the Linux community and distributors have no interest or are simply ignoring vital issues. Yes there have been game that are natively released under Linux. Some major development houses do release games for Linux regularly. But what is Linux’s market share in the gaming business? After Loki went bust, gaming on Linux has been on a decline. Why? According to me there is no reason. The platform is solid and has gotten better. There is nothing fundamentally wrong with Linux. There is a lot of potential to grow if some simple issues are addressed.

OpenGL Longs Peak. Sooo Loong!

I am an avid follower of OpenGL news as it was the first graphics API (other being Direct3D) I ever picked up. So I must confess I have a little bit of a soft corner when it comes to OpenGL. I thoroughly dislike comparing the two APIs because I consider them equivalent in functionality. However, recent developments in DirectX have put it at a clear advantage as compared to OpenGL. Direct3D implementations (DirectX 10) already support SM 4 with cards like the 8800 (Geforce 8800 GTS from NVIDIA) already hitting the market. That in itself shows how far behind OpenGL is. I have been hearing Longs Peak for too long and either the ARB committee is sleeping or just too lazy off their a** to get anything done. Either way OpenGL has a lot of catching up to do, which is a pity since OpenGL was better designed initially.

The longs peak update does promise a few changes and improvements. For example the buffer objects finally have the necessary improvements like

  • mapping only a specified range of a buffer
  • strict write-only access
  • explicit flushing of altered/written regions
  • whole-buffer invalidation
  • partial-buffer invalidation
  • non-serialized access

most of which are a part of Direct3D implementation already and are available in Direct3D 9.0. These should have been done a long time back.

Longs peak has also introduced an object model. No its not a direct OO approach, but something of an OO approach wrapped inside an C API. While OpenGL can’t be convented directly into an Objec-Oriented library, the committee came to a conclusion that it was impossible to move further without having to work on some kind of object model. I can understand their concerns, but the object model thing looks kinda overly complicated. Whist the exact implementation details will only be known when longs peak is released and the drivers come out, we have to hope that we are not in for a any nasty surprises.

Thats not to say everything is bad. I mean, in the end this may just look like a rant in a couple of months, maybe the spec is really good. I just hope they release the spec soon.