[jeffd1830]

Here's a sample of HQ4X applied to a section of the overworld map:



We went on a brief hiatus while I got some real work done and enjoyed the holidays. I've got the map editor exporting to a very terse format now, which the MOAI-based client is actually downloading, unpacking, and beginning to interpret now. It loads all the assets and is displaying a grid of random textures. I think I'll have it showing an actual section of the map within a few more days.

[DeveloperX]

Hey man, that looks great!
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[Verious]

Looks good... keep the updates coming.

[jeffd1830]

I have upgraded our level editor to now have a very complete concept of layering.

Each level can have up to 255 layers of block data. These are stored as a sort of linked list at each given X,Y coordinate, so the data structure is not wasteful. Within the editor, there is a lot of extra semantic information that is optimized out when the level is exported for the game engine. For example, each layer can be named.

Think of these layers like photoshop layers more than like specific height elevations on the map. They can be rearranged dynamically, and hidden or shown separately.

At any given time, the player is considered to be inside of a certain viewing context. A viewing context defines which layers of background tiles are drawn and in what priority order. As for sprites, it also defines which other contexts' sprites are visible, and at what height they are considered in relation to the background tile layers.

The level editor allows you to define these viewing contexts, and to choose a context to determine the view while editing. It only takes one click to switch contexts, and once selected, the layers within that context are shown in another list, and you can click any time to switch the current drawing layer. Once contexts have been defined, layers DO have a height associated with them, since the context specifies which order the layers are rendered in. So, in the editor, blocks on the current layer appear at full brightness, and blocks on lower layers appear 50% transparent. Blocks on higher layers are not shown (as they could interfere with editing the current layer due to overlap.)

In the game engine itself, the screen has to be painted by calculating which background tiles have priority (highest height in the current context) and the corresponding texture is assigned to the appropriate prop in the array of 2D props (our substitute for the NAM table.)

When scrolling, only one row or column needs to be painted at a time. The rest of the textures stay the same as they were (unless animated...)

A whole screen has to be painted only in the following circumstances:

• Initial level entry (or re-loading a saved game in progress,)
  
• When the player's context has changed and this results in a change of the tile layering (i.e., entering the front door of a building whose ceiling breaks away to reveal the interior)
  
  • If I want to be very retro, I may figure out a way to animate this transition by doing some sort of flood-fill algorithm outward from the coordinate of the player. This animation was necessary on the NES because updating the entire screen of NAM table memory took more than one vertical refresh on a NES and would have introduced a pause in the frame-rate anyway, so rather than make it jump slightly, they played it up so that the roof (or darkness, etc) would appear to peel-back off of a room.
  
  

[jeffd1830]

Finally, I got the game engine to actually render a screen! Well, the background tiles, with no sprites.

I put up the screenshot as well as the raw map and asset data here for anyone who is interested in taking a look:

http://legendsoffairwind.com/dev/mapdata/

If you look in the unzipped/data/9 subfolder, pretty much every file in there was necessary to render the screen you see in the screenshot.

The only one that isn't utilized right now is idents. chr, manifest, and revisions are only used during downloading and verification of the level data, and the initial loading of textures into memory.

"blocks" is converted into an asset filename by looking the first byte up in "pal" and the other four in "chr", and "revisions"

Once preloading is done...

Entries in "map" point to "plates". "contexts" determines which plates are visible at the moment. "plates" point to "cells".

To get an individual texture reference, we take one entry from "cells" plus a lookup into a palette conversion table that was generated during the initial load by cross referencing "settings" with "palettes"