I'm not sure I really see the point for queuing up for several hours in the early morning for a game console on release day, but I am interested in how the PS3 and Wii shape up as gaming machines (especially since they aren't out yet in my neck of the woods). Happy to read about your experiences, whether here, in your own journals or in the Lounge.
Update
Well it's past the weekend, and I'm still not back on task. My mind's a fog right now; I keep feeling like it wasn't a good idea to get out of bed this morning. Unfortunately I've been feeling like that for the last fortnight, so I doubt I can wait until I have a "good day" before getting back stuck into things. This week I'll try to force myself to get my hobby projects back on track (mostly through a heightened sense of guilt). Only trouble is I can't think straight - but hopefully this is a symptom of being inactive and once I get stuck into things with more vigour the damn fog clouding my mind will go away. Damn well hope so, otherwise I'll be stuck forever. I hope I can catch up on my development on Ice Slider while many of you get sucked into playing with your new fangled gaming toys.
I did have a brief look through my code back for Ice Slider though, trying to get my mind back on the next problem at hand. At the moment I'm trying to write the GUI system, attempting to write a bunch of windowing classes to make GUIs relatively easy to mock up. However I have another graphical problem that's arised from my slapdash approach to architecture design in Ice Slider that I'll elaborate on later on in this post.
I also spent some time trying to compose some piratey music for Stompy, but didn't end up with something that really caught my fancy. I've got a few vaguely nautical sounding themes, but they need a lot more refinement to be both piratey (rather than just nautical) and whimscial enough to fit Stompy's style. Plus I'm really peeved that I thought of a great piratey tune while at the supermarket but forgot once I made it back to my keyboard - dagnabit!
Graphic Sysytem
One of the things I'm figuring out right now is the design methodology for the graphics system. At present the method I'm using for displaying sprites is pretty darn simple: every game object has a "draw" method that outputs to the screen by either calling more "draw" methods in child elements or rendering primatives to the screen (at the moment this is done by calling a function that renders a textured 2D quad using OpenGL immediate mode and orthographical projection).
At the moment this works fine, but I see problems with this approach once I get to the game. The problem is this only works if I draw each element from back to front; i.e. using the Painter's Algorithm. But the responsibility on drawing things in the right order is placed on the game code, not within the internals of the graphics system. This defeats the point of making such a system, which is to allow the game to not have to worry about such issues. Plus it will make drawing game objects trickier as the game will have to either calculate or keep track of the display order of each element.
So I'm thinking I should adapt my drawing code to take in a depth argument specifying where each sprite should be relative to the other sprites. However I'm unsure of the best way of tackling the drawing itself. I can see two approaches I could take:
- Just change the 2D OpenGL drawing code to 3D and render each quad at the given distance using immediate mode and let OpenGL sort out the depth. Most likely a trivial change to the code.
- Store all the quads in a data structure internal to the graphics system, sorted in depth order, and then use the present 2D immediate drawing system (or 3D) to render the sprites. A bit more involved to get running, and might require some performance tweaks. Advantage is that this can be more easily modified to send all sprites as a batch lot using vertex buffers (or whatever that advanced graphics processing system is; I'm not a graphics guru and haven't looked that far ahead as of yet!)
My hesitancy between choosing between the two is due to my lack of experience with designing graphics systems and OpenGL; I'm not sure if there's some hidden problems that I haven't considered. The first approach I think is the easiest to make, as it's just a modification of my present code, but it does rely on OpenGL making the right decisions and is less flexible if I want to extend in the future. The second approach is a bit more involved and also requires extra memory (which may or may not be necessary; I don't know if I've picked the best system here!) but can be extended to use more advanced OpenGL techniques in later iterations of the engine.
However I'm also unsure if there's a better and more standard approach to sprite rendering, which is why I've posted all this in my journal. I know a lot of you have spend a lot of time tweaking your own systems and know a fair bit more about good graphics rendering techniques, so I'm happy to read any advice you have on this matter.
