New BUILD map format

This page serves to collect and discuss ideas about a potential future map format for the BUILD engine.

UPDATE: As of 2013-05-06, there's a prototype implementation supporting saving and loading in the LUNATIC=1 build of EDuke32.
Comments, suggestions and/or criticism welcome!

Current proposal

The two prongs of the new map format are mutually inclusive.

map-int (helixhorned)

The internal, in-memory representation of the map. Pretty much the same thing as now, but with some fields rearranged for convenience, and others added.

• sector[] .ceiling*, .floor* --> sector[].cf*[2], indexed by YAX_CEILING (0) or YAX_FLOOR (1). So that less code is almost-duplicated. Downside: worse readability?
  • DONE: ceiling* and floor* members contiguous (respectively). From Lunatic, we can have e.g.

fl = sector[i].floor
fl.pal = 1

using the anonymous struct/union extension of the LuaJIT FFI (TODO).

• sector[].cfbunch[2], to keep xpanning free; wall[].ynextwall[2], because packing TROR nextwalls into lotag and extra is ugly.
  • DONE: the members are named wall[].upwall and wall[].dnwall.

• (Plagman): for each wall[] (and sector[].cf*?), a 3x3 matrix specifying an affine transformation of the 2D texture coordinates instead of panning/repeat. Base data type: float? Feasible to store only 2x3 submatrix?

• support for 1:N red wall connections? This would help constructing elevators with TROR.

• (Hendricks266): parallax sky projection information for sector[].cf*, like SW (as a starting point)

map-text (TerminX)

Purely textual external map representation, similar to the "Universal Doom Map Format" (UDMF).

Advantage: decouple external representation from in-memory layout.

• Support for additional information (author, per-map settings, ...). The most general way of accomplishing that is packing scripting code that would be run on map entry (near/similar-to EVENT_ENTERLEVEL) into the map

• Support for per-s/w/s variables initialized at map load time instead of overloading existing members. Need to work out interaction with scripting system.

• DONE: Implementation: a map-text file is written in a safe subset of the Lua language (e.g. only assignments and table constructors). Parse that with LPeg, and then simply load into a Lua state, where it is validated and converted to the internal representation. <-- Needs LJ in the engine!

• Desirable: work out the format such that editor changes produce small textual changes, for example by "relativifying" references to nextwalls and the like. Example: s:=wall[w].nextsector is relative to sector sectorofwall(w), .nextwall is relative to sector[s].wallptr.

• The ability to specify whether to toggle certain map compatibility behaviors (such as the old NPOT panning)

• (Hendricks266) Desirable: Inline Lua/Lunatic scripts of some sort.

Behavior of the editor

We'd still want to save old map formats on occasion, like when making test maps that need to be opened in e.g. Duke3D 1.5, and when creating maps for other BUILD games.
DONE: Mapster32 will save V7 or V8 binary formats if there is no TROR, depending on whether V7 limits were exceeded. It will never save V9 (binary TROR) format, though the engine can still read it.