Jump to content
  • Advertisement
  • entries
    422
  • comments
    1540
  • views
    490899

TinyXML

Sign in to follow this  
jollyjeffers

162 views

Had another exam this morning, so I've been on the go for over 11 hours already today. It's only just past 5pm [headshake]

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:

"1.0"?>






DefaultTileSet.fx
NormalTileRendering






























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).
  • Each 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]
Sign in to follow this  


2 Comments


Recommended Comments

Went a whole lot better than I was expecting [smile]

I reckon I might actually get a decent mark rather than just a pass-mark, which is nice.

Cheers,
Jack

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!