[Ohrrpgce] New map format

Ralph Versteegen teeemcee at gmail.com
Sat Dec 12 02:18:49 PST 2009


Whoops, I forgot to start this discussion as I said I would.


(Prelim: I think changing the map lump naming scheme, if at all
desirable (I don't see the point) is a separate issue and can be done
just as easily independently; more interesting would be to lump up all
the lumps for each map into a single lump named something like map#.lmp)

Map lumps survey/proposal:

.N## - NPC definitions. This lump is currently fine as it is, no
changes required.

.T##, .E##, ,P## - tilemaps, foemap, passmap. Suggestion: replace; see below
.MAP - General map data. Suggestion: replace; see below
.MN - Map names. Suggestion: replace; see below

.M## - a new main map data lump:

I like that idea that each map could be stored in a self contained
lump or set of lumps, so I'd like to replace the .MAP general map data
lump with a lump per map. More importantly, a fixed length .MAP
doesn't allow a flexible number of map layers and per-layer settings.
Also, it should be combined with .MN mapnames. I think RELOAD is the
right tool for the replacement.

I suggested a little while ago that the tilemap data for each layer
could be stored in a binary blob inside the RELOAD document. I am now
starting to think that this would be more of a nuisance, and the tile
data for each layer would be better off in its own lump.

Tilemaps, the passmap, the foemap, and in future, user-defined
datamaps are all basically the same, so I propose storing them all in
the same way. Each could be described by a 'tilemap' node in .M##. A
'maplayer' node would contain a 'tilemap', along with various things
like the tileset and transparency. A 'tilemap' could have the
following attributes:
-width, height
-format: a string indicating the binary encoding. The specifics aren't
important, but for example there'd be one (maybe "1Blegacy") for 1
byte/tile with 160 tiles + 2 animation patterns, and one ("4Bint") for
4 bytes/tile, for signed 32 bit integers for data.
-file: the name of the lump containing the tile data.

Then the tilemap lumps themselves would be headerless binary blobs. We
could lump them up into a new lump to keep things clean, eg
"map#.lmp". However, I don't like the fact that they wouldn't be self
describing.

Alternatively, we could move some of that stuff into a header on each
tilemap lump. I expect the header would be variable length and need a
version id. But now we have just what RELOAD is meant to supersede.

Anyway, the .M## RELOAD tree would look something like this:

<map>
  <name="...">
  ... existing .MAP map not otherwise mentioned
  <autorun=#>
    <argument=#>
  <layers>
    <maplayer>
      <tilemap>
        ...
      <tileset>
      ...etc
    <maplayer>
      ...
    <npclayer>
    <herolayer>
    <maplayer>
      ...


.D## - Door links. A mess, but there's no need to change it in the
near future. It should contain only actual existing doors instead of a
fixed number of 200. In future might like to add a script to trigger
on use. Maybe a candidate for RELOAD.

.L## - NPC locations. Needs to be changed to complete the removal of
the 300 NPC limit. Better think ahead and make coordinates in pixels.
.DOX - Door locations. All maps are in the same lump. Could also be
split out to one lump per map, but no pressing need. Also want to
switch to pixel positions eventually... actually, I don't see why
doors should be exactly 20x20 pixels in size. And other data might be
desired in future, like walk off direction.



More information about the Ohrrpgce mailing list