Lachlan's misadventures in games programming

Sunday, 29 May 2011

Lachlan's Adventures into C++

5/29/2011 10:53:00 am Posted by Lachlan No comments
So far, I've really finished only two basic things in the Space Invaders clone. Firstly, I can display an arbitrarily long series of images, each for a certain time, each skippable or not. This provides the way to show logos etc. This will be reusable, and is reasonably general so if more complex then it needed to be. Secondly, the menu screen completely works, and plays sounds as you select items with Keyboard or Mouse. Like the first thing, it can show an arbitrary amount of menu items, put anywhere on the screen. This also involved writing a basic sound manager which associates sounds with a string, and can play them using SDL_Mixer. So - it can work thusly:

  1. //Load the sound
  2. Sound::Instance()->AddSound("Shoot", "\\data\\sounds\\shoot.wav");
  3. //Play the sound
  4. Sound::Instance()->PlaySound("Shoot");

Each subsequent reference only needs the PlaySound command. The Sound class manages the WAV files, and deallocates them at the end of the program.

These have, whilst sounding trivial in the scheme of making a playable game, taught me some things I will need to know, and provided code and classes that I will use in the game proper. So far, I have learned to use:

  • Sound in SDL
  • std::map
  • std::vector
  • The singleton pattern
  • Putting types in classes
Now, I'm up to programming some actual gameplay. I sense that the std::map and std::vector containers are going to prove helpful

Thursday, 26 May 2011

Martians Update

5/26/2011 12:19:00 am Posted by Lachlan , No comments
I'm not a fan of OpenGL. At least not for what I need it for. And I'm finding it rather discouraging to have very little clue what the example code I'm using does. And I don't seem to be getting anywhere. I'd rather program gameplay then wrestle OpenGL into submission.


So, I'm giving up delaying the ambitious initial design to make 'The (lite) Night The Martians Came'. My less ambitious, less lofty goals to achieve in the short term:
- Basic space invaders gameplay (with only one weapon, but with a slightly different layout of Martians - as you can see in the mockup)
- Locked 640x480 resolution screen (with a toggle for full screen)
- Maybe include bunkers, maybe not
- SDL for Graphics 'cause I've used it before

Mockup only

I've made a mockup for the purposes of working out my sprite scalings that I thought I might as well share.

My goal to make it the slightly-less light version would be to use OpenGL Frame Buffers so I could still make a fixed resolution SDL game, and then scale it to the monitors native resolution, and make it handle different aspect ratio screens.

Finally, my goal to make it the full fat version would be to ascend to my lofty goals prescribed earlier.

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 http://gamedev.stackexchange.com/questions/11533/opengl-insanely-slow.

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!


Lachlan