Next-gen console argument wars have been on the rise on the last few months. I find it weird that some people argue over choices of consoles with a greater fervour than politics or religion. Although I can understand the need to crush those heretics who think Nintendo is just for kids [grin].
...although it's pretty close. I've got a prototype font made from my own handwriting that looks a bit slapdash but is suitable for debugging and prototyping. The text system now supports single lines of text scaled to different widths and heights. At present coloured fonts and any justification other than left is not supported, but those additions are pretty easy to add. It also doesn't support multiple lines of text (without using more than one text object), but I'm not sure whether I'll need that functionality for Ice Slider. The interface is also very clumsy due to its creation as I added on each individual feature, but I'll wait until I get a good idea of how I want to use the text within the game before I rework that.
One thing I've noticed when browsing the OpenGL forum here for tips is there's a big warning against using OpenGL immediate mode. At present due to my limited knowledge of OpenGL I'm using immediate mode for my sprite rendering, and I'm not sure if this will end up crippling the graphics system if the internal design depends on it too much. I don't know that much about vertex buffers or lists, and frankly I'm not sure if I need to know about them; given my engine is 2D all I'm wanting to use OpenGL for is textured quads, occasionally with some colour or alpha effects. Given I'm not using any complex geometry (just quads) I doubt I need to worry that much, and I'm certainly not going to deal with performance issue now. But I would be interested in knowing how well OpenGL deals with sprite quads in immediate mode. I doubt I'll need to render more that 10,000 sprites at any one time (and that's probably an overestimate), so I'll rig up some sort of test case in the near future to see if that would be a problem. I hope that vibe I'm getting from the forum is just down to the tendency of programmers to overly chase high framerates.
Controlling the Input
The next big system I need to add is input/control so I can start doing stuff with the engine. I'm using SDL, so this shouldn't be too difficult. The main choice is the paradigm I use for communicating the input to the main part of the program. There's several ways to go about this:
- Have the Input class act like a big data structure, and let game objects read which buttons are being pressed as part of their update cycle. This approach is pretty easy to implement, but the resulting system could get messy; every object is in charge of managing its own input.
- Have game objects register an input reading function with an Input manager. This is similar to the first approach but gives more control to the input manager about what receives input. Would be easier to switch input for objects on and off.
- Store a function pointer for each key which is called upon a key press. Most keys map to a null function that does nothing. This is a pretty neat approach, although it makes it hard to assign multiple functions to a single key or to allow combinations of key presses.
I'll figure out what I like the best and roughly plan how the system works, but I'd be interested if anyone has any recommendations. I'm sure there's many approaches I haven't listed too (this is all just off the top of my head).