Lamoot wrote:- How does the engine handle different ground types and transitions between them? Do you have a complete set of all possible transitional tiles between two ground types, or do you use some more advanced methods like Texture splatting? (if they can even be adapted to 2d that is)
- Would it be possible to post a picture of a single tile from Eschalon - an image can tell more than a thousand words.
- How does the engine handle character sprites. The weapons are the only equipment that show on the character sprite. Do you use a new sprite altogether for this, or is the weapon a separate sprite attached to the main character sprite.
Hopefully I'm not posting info that BW wouldn't want out there, but I can at least tell you how the images are stored inside the main graphics archive.
To draw a single tile, you'd first grab a 52x26 bitmap of the base tile (which has an alpha channel, for transparency) - the non-transparent areas make up the diamond that you'd expect for an isometric tile. Then on top of that, you'd grab a 52x26 "decal" image which would get overlaid on top, which could be a blood splatter, or a "transition" overlay (like going from sand to grass, etc) - this one's mostly transparent, so you just composite the two together, basically. Then on top of that you'd grab whatever object happens to be on that square (door, wall, chest, monster, what have you) and do a similar composite, and then there's an object decal which goes on top of that (for windows, torch posts, etc). The map files simply define which floor, decal, object, object decal, or creature is present on each square. How the actual game engine itself handles all this I'm not sure; I'd imagine that the composites of floor+decal+object+objectdecal are cached somehow so it's not constantly regenerating the images. It's a very quick process to load in a whole map this way - I can do it in pure Python (which isn't the speediest) in just a few seconds (though of course the game engine takes into account lighting effects like torches, etc, so clearly it's got to go through another level there).
As for your avatar, it looks like a similar process, at least datawise. I'm pretty sure that BW uses 3D models to construct them, but by the time the game loads them in, they've been exported to a similar kind of bitmap. You have a base avatar image file which is a grid with a render of your avatar in all stages of its animation (it looks like fifteen frames), facing all eight directions. Then on top of that your armor, weapons, shields, torches, et are composited in, from separate pre-rendered files (so one file has a 15x8 grid of the shield, one has a 15x8 of the sword, etc). Again, I don't know how the game engine itself handles it, but I'd guess that it caches a composite of your currently-activated equipped-inventory set and then just updates those caches when you swap equipment. Just a guess though. Enemies' sprites are a bit simpler since the weapons are pre-rendered onto their main graphics files, so there's just the one 15x8 grid for each enemy.
(Edit: Well, I guess I shouldn't really say "Pure Python" there, since the actual graphics compositing happens via PyGTK, which runs stuff that's C and Assembly, in the background. Still, I'm guessing that to run at decent speeds you don't really need more than one pass at compositing and then caching the results.)