New BUILD map format

From EDukeWiki
Revision as of 04:58, 26 August 2012 by Helixhorned (talk | contribs)
Jump to navigation Jump to search

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


Current proposal

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?
  • sector[].cfbunch[2], to keep xpanning free; wall[].ynextwall[2], because packing TROR nextwalls into lotag and extra is ugly.
  • (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.
  • Proposed 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.

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.

Retrieved from "https://wiki.eduke32.com/w/index.php?title=New_BUILD_map_format&oldid=11140"