New BUILD map format - Revision history

Hendricks266 at 17:33, 1 June 2014

2014-06-01T17:33:45Z

← Older revision		Revision as of 10:33, 1 June 2014
Line 6:		Line 6:

	==Current proposal==		==Current proposal==

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

	===map-int (helixhorned)===		===map-int (helixhorned)===
Line 39:		Line 41:

	* Desirable: work out the format such that editor changes produce small textual changes<s>, 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.</s>		* Desirable: work out the format such that editor changes produce small textual changes<s>, 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.</s>

			* 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==		==Behavior of the editor==

Helixhorned: /* map-text (TerminX) */ minor correction.

2013-05-06T20:01:32Z

map-text (TerminX): minor correction.

← Older revision		Revision as of 13:01, 6 May 2013
Line 36:		Line 36:
	* 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.		* 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!		* DONE: Implementation: a map-text file is written in a safe subset of the Lua language (e.g. only assignments and table constructors). <s>Parse that with LPeg, and then simply</s> 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<s>, 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.</s>		* Desirable: work out the format such that editor changes produce small textual changes<s>, 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.</s>

Helixhorned: Update.

2013-05-06T20:00:09Z

Update.

← Older revision		Revision as of 13:00, 6 May 2013
Line 1:		Line 1:
	This page serves to collect and discuss ideas about a potential future map format for the BUILD engine.		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.<br/>
			Comments, suggestions and/or criticism welcome!


Line 8:		Line 11:
	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.		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?		* <s>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?</s>
	* sector[].cfbunch[2], to keep xpanning free; wall[].ynextwall[2], because packing TROR nextwalls into lotag and extra is ugly.		** 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).

			* <s>sector[].cfbunch[2], to keep xpanning free; wall[].ynextwall[2], because</s> 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?		* (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?
Line 27:		Line 36:
	* 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.		* 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!		* 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.		* Desirable: work out the format such that editor changes produce small textual changes<s>, 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.</s>

	==Behavior of the editor==		==Behavior of the editor==
Line 35:		Line 44:
	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.		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.
	<br/>		<br/>
			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.

	<br/>		<br/>
	[[Category:Developer's corner]]		[[Category:Developer's corner]]

Helixhorned at 12:58, 26 August 2012

2012-08-26T12:58:16Z

← Older revision		Revision as of 05:58, 26 August 2012
Line 9:		Line 9:

	* 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; 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?		* (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?

Hendricks266 at 08:32, 17 July 2012

2012-07-17T08:32:59Z

← Older revision		Revision as of 01:32, 17 July 2012
Line 14:		Line 14:

	* support for 1:N red wall connections? This would help constructing elevators with TROR.		* 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)===		===map-text (TerminX)===

Helixhorned: /* map-int (helixhorned) */

2012-07-15T10:33:56Z

map-int (helixhorned)

← Older revision		Revision as of 03:33, 15 July 2012
Line 13:		Line 13:
	* (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?		* (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.

	===map-text (TerminX)===		===map-text (TerminX)===

Helixhorned: correct some of my BS

2012-07-08T18:47:15Z

correct some of my BS

← Older revision		Revision as of 11:47, 8 July 2012
Line 26:		Line 26:
	* 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!		* 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.		* 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==		==Behavior of the editor==

Helixhorned: ideas...

2012-07-08T16:41:46Z

ideas...

← Older revision		Revision as of 09:41, 8 July 2012
Line 2:		Line 2:


	==~~Proposals~~==		==Current proposal==

	===map-ng (helixhorned)===		===map-int (helixhorned)===

	~~That is~~, ~~pretty~~ much the same thing as now, but with some fields rearranged for convenience, and others added.		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.

	~~===~~map-text (~~TerminX~~)~~===~~		* 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!

	~~Purely~~ textual ~~format~~, ~~similar~~ to the ~~"Universal Doom Map Format" (UDMF)~~.		* 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.

Hendricks266 at 22:15, 7 July 2012

2012-07-07T22:15:56Z

← Older revision		Revision as of 15:15, 7 July 2012
Line 21:		Line 21:
	==Behavior of the editor==		==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.		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.
	<br/>		<br/>
	<br/>		<br/>
	[[Category:Developer's corner]]		[[Category:Developer's corner]]

Hendricks266 at 22:09, 7 July 2012

2012-07-07T22:09:15Z

← Older revision		Revision as of 15:09, 7 July 2012
Line 24:		Line 24:
	<br/>		<br/>
	<br/>		<br/>
			[[Category:Developer's corner]]