Lachlan's misadventures in games programming

Tuesday, 3 May 2011

My wrestles with OpenGL

5/03/2011 12:09:00 am Posted by Lachlan , , No comments

I've spent the last week in Tasmania, so haven't done massive amounts.

What I was doing before I left, and have been doing since, is slowly wrestling OpenGL into submission. This is what I've managed to do so far:

Hmmm... How Exciting. I should probably clarify, they don't move. In fact, all they are is 50 textured polygons (quads) that don't do anything. The extent that you can do in the program is push ESC to exit, or F12 for a not quite correct screenshot.

What I've primarily discovered, is that I don't like OpenGL.  On my first day with it, I find myself with slowdown problems. For rendering a single textured polygon on the screen. Because, unlike DirectX, the general rule is that OpenGL cards 'fake it till they make it' - anything the graphics card can't do, simply means the OS will do in response. Which still didn't explain my slowdown.

Which got queerer. It seemingly disappeared again and went back to the kind of frame rates it should have. Then, slowed down again. The only actual fix I've found is to run the program in full screen.

You can follow my struggle with the speed at

But you may ask why I'm bothering with OpenGL? My answer is simple: I want Hardware Rotation and Scaling. SDL is fantastic for what it is, but its graphics side struggles. Specifically, to rotate or scale sprites are very costly CPU operations. I wanted to learn OpenGL so I can have a retro looking game, without eating a modern processor to bits. It also works really well with SDL. Instead of learning DirectX, I can apply the SDL I already know for events (Key, Mouse, Joystick etc), sounds, windowing* and timing. Finally, SDL+OpenGL is platform agnostic, and I should be able to go to Mac or Linux with almost no, if any changes. Except in the first case, having to purchase a Mac.
*OpenGL doesn't make its own window by default. You either do it yourself with ugly windows code, use the very outdated GLUT or (as I did), SDL.

The other issue I'm finding in learning OpenGL is the sheer lack of resources as to what modern OpenGL is. And what is seeming to be the phasing out of older features - when I ran my program through a profiler to try to figure out what was holding it up, it told me 90% of my calls were depreciated. Instead of doing anything the way I was, I was supposed to do it in 'Fragment Programs' (DirectX calls them 'Shaders'). I'm trying to do basic things in the API, and I need to separately program the GPU? And, not to mention, require people have a relatively modern (Post 2005) video card to play a 2D space-invaders style game? It seems a wee bit ridiculous. Even the industry standard 'The OpenGL Programming Guide' (The Redbook) starts by teaching you how to program in a way that is completely out of date, and depreciated. Gah!

Work is slow, but steadily moving forward. Watch this space!



Post a Comment