Track file - Revision history

Cas: /* Metadata */ Text split format

2020-10-22T06:20:31Z

Metadata: Text split format

← Older revision		Revision as of 08:20, 22 October 2020
Line 394:		Line 394:

	Colouring information, when included, is to be read as follows: read one byte, which is the count, then two words, which correspond to the border and background colours respectively in 16bit colour (RRRRRGGGGGGBBBBB). Then assign as these two colours to as many tiles as the count going from left to right, then from top to bottom. Repeat until the whole grid has been covered. The transparent colour is represented with 1111100000011111b. When the border or background colour is set to this value, it means it is not present for that tile.		Colouring information, when included, is to be read as follows: read one byte, which is the count, then two words, which correspond to the border and background colours respectively in 16bit colour (RRRRRGGGGGGBBBBB). Then assign as these two colours to as many tiles as the count going from left to right, then from top to bottom. Repeat until the whole grid has been covered. The transparent colour is represented with 1111100000011111b. When the border or background colour is set to this value, it means it is not present for that tile.

			===Bliss text-based split metadata format===
			When this format is selected, Bliss will store the data in a separate file with extension ".smd". From the perspective of Bliss, this is still a binary file, as the structure completely disregards the operating system.

			The file must start with the text "[smdf]" plus a character 0Ah or "[smdf]" plus a character 0Dh to be considered valid. This is equivalent to saying the first line must be "[smdf]" in ASCII or UTF-8, but other encodings may not work and a BOM at the beginning of the file would render it invalid. From that point onwards, all bytes 0ah and 0dh are stripped out of the stream, except that one or more of those characters will stop line formation. This means that any combination of whatever number of bytes 0ah and 0dh will be interpreted as an end of line. Therefore, Bliss sees no empty lines in these files. Lines that do not contain an equal sign will be ignored (comments). For lines that do contain an equal sign, everything to the left of the equal sign is the property name and everything to the right of it is the value. Spaces at the end of the property name or at the beginning of the value are removed and the property name is case-insensitive within the ASCII threshold. When producing one of these files, Bliss will use 0d0ah as separators, as is common in DOS and supported by most OSs.

			Following are the recognised property names:
			* "title" or "titl" - Track title
			* "author" or "autr" - Track author's name
			* "comment" or "comm" - General comment
			* "tour_info" or "chmp" - Tournament information
			* "creation_date" or "date" - Date of creation of the track in YYYY-MM-DD format
			* "tool" - Name of the tool used to create the track (without the version number)
			* "tool_version" - Version number in the form v.s.d or v.ss.dd
			* "editing_time" or "etim" - Number of seconds used to edit the track

			The text format does not support colouring information.

	==Overlaying==		==Overlaying==

Cas: /* Bliss binary metadata format */

2020-10-22T06:01:45Z

Bliss binary metadata format

← Older revision		Revision as of 08:01, 22 October 2020
Line 387:		Line 387:
	* "Tool" - Editor or tool used to create the track		* "Tool" - Editor or tool used to create the track
	* "Etim" - Editing time in seconds		* "Etim" - Editing time in seconds
			* "Colr" - Colouring information

	"Etim" is a little-endian dword. "Tool" is a UTF-8 string representing the name of the tool, except that the last four bytes are a dword containing the tool version in decimal ''xxyyzz'' for ''xx.yy.zz''. "Date" is a word for the year, a byte for the month and another byte for the day. The rest are UTF-8 strings. Unknown chunks are skipped.		"Etim" is a little-endian dword. "Tool" is a UTF-8 string representing the name of the tool, except that the last four bytes are a dword containing the tool version in decimal ''xxyyzz'' for ''xx.yy.zz''. "Date" is a word for the year, a byte for the month and another byte for the day. "Colr" is a RLE compressed string containing the colouring information on the grid if any. The rest are UTF-8 strings. Unknown chunks are skipped.

	There was an argument in the past over whether the metadata format should be binary or text, with [[Cas]] being the promoter of binary and [[Dreadnaut]] defending text. Ultimately, binary was chosen for both split and overlay, ~~but Cas~~ is ~~considering switching~~ to ~~text~~ for ~~split~~.		There was an argument in the past over whether the metadata format should be binary or text, with [[Cas]] being the promoter of binary and [[Dreadnaut]] defending text. Ultimately, binary was chosen for both split and overlay at that time. For version 2.5.5, a text-based split file format was introduced as an alternative. Binary split was preserved and Bliss still defaults to one-file binary format. Text format is only available as split.

			Colouring information, when included, is to be read as follows: read one byte, which is the count, then two words, which correspond to the border and background colours respectively in 16bit colour (RRRRRGGGGGGBBBBB). Then assign as these two colours to as many tiles as the count going from left to right, then from top to bottom. Repeat until the whole grid has been covered. The transparent colour is represented with 1111100000011111b. When the border or background colour is set to this value, it means it is not present for that tile.

	==Overlaying==		==Overlaying==

Cas: /* Extra byte */

2020-10-22T05:45:24Z

Extra byte

← Older revision		Revision as of 07:45, 22 October 2020
Line 373:		Line 373:
	Probably thought of as a reserved byte or just a padding byte to make the file length even at the time of its inception, the last byte of a raw track file (at zero-based location 0709 hexadecimal) is unused by Stunts. When a track is created with the internal editor, it is generated as a 1,802-byte file with this last byte being null. When Stunts or the internal editor read a track file, this byte is loaded into memory together with the rest of the file, but is at all times ignored by the game. Later, modifying the track and saving it again will keep the value stored in this byte. [[Track Blaster]] behaves in the exact same manner with respect to the extra byte.		Probably thought of as a reserved byte or just a padding byte to make the file length even at the time of its inception, the last byte of a raw track file (at zero-based location 0709 hexadecimal) is unused by Stunts. When a track is created with the internal editor, it is generated as a 1,802-byte file with this last byte being null. When Stunts or the internal editor read a track file, this byte is loaded into memory together with the rest of the file, but is at all times ignored by the game. Later, modifying the track and saving it again will keep the value stored in this byte. [[Track Blaster]] behaves in the exact same manner with respect to the extra byte.

	[[Bliss]] takes advantage of how this byte is handled by Stunts and uses it to try to recognise tracks that have been built with it. Tracks created with Bliss will store a 153 instead of a 0, but tracks edited with Bliss will preserve their current value. Values 2, 150, 151, 152 are also found sometimes, although they are no longer produced. This led to the [[Bliss format byte controversy]]~~. It is projected that future versions of the editor will cease to use this byte completely~~.		[[Bliss]] takes advantage of how this byte is handled by Stunts and uses it to try to recognise tracks that have been built with it. Tracks created with Bliss will store a 153 instead of a 0, but tracks edited with Bliss will preserve their current value. Values 2, 150, 151, 152 are also found sometimes, although they are no longer produced. This led to the [[Bliss format byte controversy]].

	==Metadata==		==Metadata==

Cas: /* Bliss binary metadata format */

2019-03-26T03:43:18Z

Bliss binary metadata format

← Older revision		Revision as of 05:43, 26 March 2019
Line 379:		Line 379:

	===Bliss binary metadata format===		===Bliss binary metadata format===
	Bliss stores its metadata right after the 1,802 bytes of the raw track file if in overlay or in a separate file with the same name as the track file and an extension '.smd'. The first four bytes contain the text "smdf", followed by four null bytes. After that, the metadata consists of chunks. For each chunk, there's an alphanumeric four-byte chunk ID and a word representing the length of the chunk. Finally, as many bytes as this length will contain the value for that chunk parameter. The following chunks IDs are recognised by Bliss:		Bliss stores its metadata right after the 1,802 bytes of the raw track file if in overlay or in a separate file with the same name as the track file and an extension '.smd'. The first four bytes contain the text "smdf", followed by four null bytes. After that, the metadata consists of chunks. For each chunk, there's an alphanumeric four-byte chunk ID and a little-endian word representing the length of the chunk. Finally, as many bytes as this length will contain the value for that chunk parameter. The following chunks IDs are recognised by Bliss:
	* "Titl" - Track title		* "Titl" - Track title
	* "Autr" - Track author		* "Autr" - Track author
Line 388:		Line 388:
	* "Etim" - Editing time in seconds		* "Etim" - Editing time in seconds

	"Etim" is a dword. "Tool" is a UTF-8 string representing the name of the tool, except that the last four bytes are a dword containing the tool version in decimal ''xxyyzz'' for ''xx.yy.zz''. "Date" is a word for the year, a byte for the month and another byte for the day. The rest are UTF-8 strings. Unknown chunks are skipped.		"Etim" is a little-endian dword. "Tool" is a UTF-8 string representing the name of the tool, except that the last four bytes are a dword containing the tool version in decimal ''xxyyzz'' for ''xx.yy.zz''. "Date" is a word for the year, a byte for the month and another byte for the day. The rest are UTF-8 strings. Unknown chunks are skipped.

	There was an argument in the past over whether the metadata format should be binary or text, with [[Cas]] being the promoter of binary and [[Dreadnaut]] defending text. Ultimately, binary was chosen for both split and overlay, but Cas is considering switching to text for split.		There was an argument in the past over whether the metadata format should be binary or text, with [[Cas]] being the promoter of binary and [[Dreadnaut]] defending text. Ultimately, binary was chosen for both split and overlay, but Cas is considering switching to text for split.

Cas: /* Fillers */

2019-03-26T03:36:46Z

Fillers

← Older revision		Revision as of 05:36, 26 March 2019
Line 329:		Line 329:
	Filler tiles are necessary for multi-part track elements to be built correctly. The proper positioning of such tiles will be described using a 2x2 grid of tiles in which the NW tile contains the value of the actual track element. For 2x1 elements (loops and corks l/r), the track element tile is either the top or the left one (depending on orientation), and so the correct fillers are either SW or NE respectively. For 2x2 elements (corks u/d, chicanes and large corners) all three fillers should be used.		Filler tiles are necessary for multi-part track elements to be built correctly. The proper positioning of such tiles will be described using a 2x2 grid of tiles in which the NW tile contains the value of the actual track element. For 2x1 elements (loops and corks l/r), the track element tile is either the top or the left one (depending on orientation), and so the correct fillers are either SW or NE respectively. For 2x2 elements (corks u/d, chicanes and large corners) all three fillers should be used.

	Editing track files with external tools such as [[Track Blaster]] gives the user liberty to ''omit'' filler tiles, either leaving the other tiles blank or filling them with other elements. That is the main trick deployed to build [[illusion tracks]], as the space where the fillers would be will appear to contain the full NW tile track element except at very short viewing distances and yet the physical behaviour will be set by whatever element the designer put in its place.		Editing track files with external tools such as [[Track Blaster]] or [[Bliss]] gives the user liberty to ''omit'' filler tiles, either leaving the other tiles blank or filling them with other elements. That is the main trick deployed to build [[illusion tracks]], as the space where the fillers would be will appear to contain the full NW tile track element except at very short viewing distances and yet the physical behaviour will be set by whatever element the designer put in its place.

	=== Other track element codes ===		=== Other track element codes ===

Cas: /* Scenery */

2019-03-26T03:35:47Z

Scenery

← Older revision		Revision as of 05:35, 26 March 2019
Line 313:		Line 313:
	\|}		\|}

	The ghost cars were not intended to be actual scenery elements and thus are not available form the [[in-game editor]]. [[Track Blaster]] is able to insert the player ghost car as a regular track piece.		The ghost cars were not intended to be actual scenery elements and thus are not available form the [[in-game editor]]. [[Track Blaster]] is able to insert the player ghost car as a regular track piece. [[Bliss]] track editor can produce both the player's and the opponent's ghost cars.

	=== Fillers ===		=== Fillers ===

Cas: /* Track codification */

2019-03-13T06:29:33Z

Track codification

← Older revision		Revision as of 08:29, 13 March 2019
Line 330:		Line 330:

	Editing track files with external tools such as [[Track Blaster]] gives the user liberty to ''omit'' filler tiles, either leaving the other tiles blank or filling them with other elements. That is the main trick deployed to build [[illusion tracks]], as the space where the fillers would be will appear to contain the full NW tile track element except at very short viewing distances and yet the physical behaviour will be set by whatever element the designer put in its place.		Editing track files with external tools such as [[Track Blaster]] gives the user liberty to ''omit'' filler tiles, either leaving the other tiles blank or filling them with other elements. That is the main trick deployed to build [[illusion tracks]], as the space where the fillers would be will appear to contain the full NW tile track element except at very short viewing distances and yet the physical behaviour will be set by whatever element the designer put in its place.

			=== Other track element codes ===
			While codes B6h through FCh are not used by the editors, they do have some strange effects on Stunts, but there doesn't seem to be a good way of taking advantage of them. Most of these codes appear like a variety of track element combinations with terrain when looking at the perspective display of the track at the menu before entering the internal editor. Some appear as coloured dots and even a few cause a crash. But even if there is no crash, once the game starts or the internal editor is opened, all these turn to vertical paved roads, even the ones that appeared like plain grass.

			This behaviour seems to suggest that these values are used internally by Stunts as it renders the track before one is allowed to play. Some track codes translate to different 3D objects depending on the terrain. For example, the straight paved road is very different when on a slope. So Stunts transforms editor codes to game codes to be able to render more quickly during the race.

			Here is a list of the values and their effects:
			* 00 -> B5 - Normal track elements
			* B6 -> B9 - Paved slopes (up north, up west, up south, up east)
			* BA -> BD - Dirt slopes
			* BE -> C1 - Ice slopes
			* C2 -> C5 - Strange slopes (grey/green)
			* C6 -> D3 - Grass
			* D4 -> D5 - Dot (sign?)
			* D6 -> D7 - Grey line at north wall (fence?)
			* D8 - Water square
			* D9 - Water North-East
			* DA - Water North-West
			* DB - Water South-West
			* DC - Water South-East
			* DD - Empty slope (west?)
			* DE -> DF - Hill top or maybe east slope
			* E0 -> E9 - Hill sides and corners
			* EA -> ED - Coloured dots (pink, dark pink, whitish, black)
			* EE -> F5 - Grass
			* F6 - Strange small object
			* F7 -> FA - Stunts crashes!
			* FB - Another strange small object
			* FC - Corner slope
			* FD -> FF - Fillers

	==Horizon codification==		==Horizon codification==

Cas: /* Terrain codification */

2019-03-13T05:56:59Z

Terrain codification

← Older revision		Revision as of 07:56, 13 March 2019
Line 47:		Line 47:
	\|\| \|\| 11 \|\| 12 \|\| 0F \|\| 10		\|\| \|\| 11 \|\| 12 \|\| 0F \|\| 10
	\|}		\|}

			Using any byte value higher than 12h in the terrain is almost guaranteed to cause Stunts to crash when loading the track file.

	==Track codification==		==Track codification==

Cas at 05:48, 13 March 2019

2019-03-13T05:48:14Z

@@ Line 346: / Line 346: @@
 Storing additional data for a track is possible in several ways, although all of them have their shortcomings. The most reliable is the extra byte, but it's only one byte. Another option is to use an external, parallel file, but it would tend to get lost and would have to be renamed whenever the track file is renamed, just like what happens with [[Highscore File Format|.HIG files]]. A very restrictive way of adding more information within the first 1802 bytes is to use some track element codes that are not normally used, but this is highly problematic. Finally, perhaps the most desirable option, albeit with a couple of limitations, is to add a binary overlay. [[Bliss]] allows for both the overlay and parallel file methods of storing metadata.
-When using an overlay, the maximum track file length is 13,802 bytes, that is, 12,000 bytes more than the size of a raw track file.
+===Bliss binary metadata format===
 ==External links==

Cas: /* Metadata */

2019-03-13T05:08:44Z

Metadata

← Older revision		Revision as of 07:08, 13 March 2019
Line 344:		Line 344:

	==Metadata==		==Metadata==
	Storing additional data for a track is possible in several ways, although all of them have their shortcomings. The most reliable is the extra byte, but it's only one byte. Another option is to use an external, parallel file, but it would tend to get lost and would have to be renamed whenever the track file is renamed, just like what happens with [[.HIG files]]. A very restrictive way of adding more information within the first 1802 bytes is to use some track element codes that are not normally used, but this is highly problematic. Finally, perhaps the most desirable option, albeit with a couple of limitations, is to add a binary overlay. [[Bliss]] allows for both the overlay and parallel file methods of storing metadata.		Storing additional data for a track is possible in several ways, although all of them have their shortcomings. The most reliable is the extra byte, but it's only one byte. Another option is to use an external, parallel file, but it would tend to get lost and would have to be renamed whenever the track file is renamed, just like what happens with [[Highscore File Format\|.HIG files]]. A very restrictive way of adding more information within the first 1802 bytes is to use some track element codes that are not normally used, but this is highly problematic. Finally, perhaps the most desirable option, albeit with a couple of limitations, is to add a binary overlay. [[Bliss]] allows for both the overlay and parallel file methods of storing metadata.

			When using an overlay, the maximum track file length is 13,802 bytes, that is, 12,000 bytes more than the size of a raw track file.

	==External links==		==External links==