New BUILD map format: Difference between revisions
Jump to navigation
Jump to search
Hendricks266 (talk | contribs) No edit summary |
Helixhorned (talk | contribs) ideas... |
||
| Line 2: | Line 2: | ||
== | ==Current proposal== | ||
===map- | ===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[] .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 | * sector[].cfbunch[2], to keep xpanning free | ||
* (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? | |||
===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 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 wall ''w'', .nextwall is relative to sector[''s''].wallptr. | |||
Revision as of 09:41, 8 July 2012
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
- (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?
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 wall 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.