I figured I owed myself some "time off for good behaviour" so I decided to have a play with my mini game project.
Given that I want to port it over to Direct3D 10 at some point it's not going to be using the fixed function pipeline for anything if I can help it. Well, even if I didn't port it to D3D10 I'm quite content with going SM2+/FX only - it's a pleasure to be working with [smile]
I also want it to be a data-driven application where possible. To make things realistic it won't be purely data-driven (although, that would make for a nice reason to use GameMonkey Script), rather it's going to have the key parts exposed as data. The overall structure/capabilities will be hardcoded into the software.
I thought I'd cover an example of this for you guys to comment on. Or, possibly, it'll be of interest to anyone trying to attempt something similar [smile]
Today I was focusing on the tile set component. It's the part responsible for applying a texture to each tile that makes up the basic grid. You've seen bits of it in previous journal entries.
Basically all the data is going to be loaded via an XML document. The XML document will contain all the vital information and the engine will take it from there. The XML document contains all of the properties that the engine uses, and then links to the necessary graphics files.
As with the general theme of this project, I'm making it up as I go along - so the format might change as/when I discover its limitations:
The above is the basic structure of the XML document (being parsed in by ~300 lines of C++/TinyXML).
I've not stress-tested it yet, but TinyXML seems to not only be simple but fairly robust. I took the "I'm a MAN!!" approach and skipped straight past the manual - managed to blunder around for a bit, but ultimately managed to get it working with very little hassle. I like that in an API.
So, a basic outline of what this XML file can actually represent:
- Rendering is based on D3D9's effects framework. Thus a key property of the XML file is the
tag - it specifies the effect file AND it's entry point. The application will be responsible for determining hardware support - it's possible that, at a later date, I'll add in a set of fallback entry points.
- The input textures contain a grid of tiles. A column or row of tiles is just a special case of a grid. The actual dimensions are determined at runtime by examining the textures.
- Tiles must have a designated height/width and be evenly placed. A confusing quirk of this is that the tiles actually use (width+2)x(height+2) pixels. As described in my previous journal entries, a 1px border is required so I can compensate for filtering errors.
- The rendering of a tile is divided into a number of layers - each layer is a texture (an error is flagged if they aren't the same size). The number of layers aren't strictly limited by the XML document, but the parser will cut off after 16 (a warning, not an error). Direct3D limits (for SM2/SM3) us to 16 texture samplers, thus it makes no sense to use nor load more than that. Arguably I could implement multi-pass rendering, but I can't think of any situation to use it.
- Each layer is defined by a semantic and filename. The filename is obvious, but the semantic may not be... Via effect file reflection (and DXSAS) I intend to hook up the effect (defined earlier) against these layers via a semantic name. I've not tried much with D3D9's SAS/semantics, so this might need some work. From my playing around, it should work fine with FX10's semantics system.
- Animations are defined in rows. Thus any tileset that has animations must be rectangular/square - not allowing for columns/rows anymore. Animations progress from the left-most tile (0) through to the right-most tile (n).
block defines some obvious params - these will be connected up internally and then updated accordingly.
I'm open to any comments on the above structure. As I originally stated, this is mostly off the top of my head so I could be missing things [wink]