Image Formats - Revision history

Nyamoru: /* Tall patches */

2025-06-07T07:06:53Z

Tall patches

← Older revision		Revision as of 03:06, 7 June 2025
Line 110:		Line 110:

	=== Tall patches ===		=== Tall patches ===
	''Tall patches'' are a backwards-compatible hack to allow ~~doom~~ pictures larger than 256 pixels in height. Since Doom pictures can theoretically be up to 65536x65536 pixels large, yet posts can only be up to 254 pixels long (with the byte value <code>255</code> serving as a terminating byte per-post), vanilla Doom pictures can practically only be 65536x508 pixels large. Tall patches hack around this limit by placing posts beyond <code>y=255</code> relatively to one another, theoretically allowing for an infinite vertical size.		''Tall patches'' are a backwards-compatible hack to allow Doom pictures larger than 256 pixels in height. Since Doom pictures can theoretically be up to 65536x65536 pixels large, yet posts can only be up to 254 pixels long (with the byte value <code>255</code> serving as a terminating byte per-post), vanilla Doom pictures can practically only be 65536x508 pixels large. Tall patches hack around this limit by placing posts beyond <code>y=255</code> relatively to one another, theoretically allowing for an infinite vertical size.

	In a Doom engine supporting tall patches, whenever a post's top delta is less than it's predecessor's top delta, an overflow is detected and both values are added together for the new top delta to allow for the tall patch. This makes top offsets beyond 254 effectively relative to one another, rather than absolute as before.		In a Doom engine supporting tall patches, whenever a post's top delta is less than it's predecessor's top delta, an overflow is detected and both values are added together for the new top delta to allow for the tall patch. This makes top offsets beyond 254 effectively relative to one another, rather than absolute as before.

Nyamoru: /* Tall patches */

2025-06-07T06:23:12Z

Tall patches

← Older revision		Revision as of 02:23, 7 June 2025
Line 24:		Line 24:
	''Reference: [https://doomwiki.org/wiki/Picture_format Picture format on Doom Wiki]''		''Reference: [https://doomwiki.org/wiki/Picture_format Picture format on Doom Wiki]''

	''Doom pictures'' are used for UI graphics, patches, sprites and wall textures. The file format is ''column-oriented,'' with each column being composed of zero or more ''posts'', which are basically arrays of pixels. These posts are assembled into a column based on their ~~lenghts~~ and offsets. Each column starts at an offset defined in the header and is terminated by a byte containing <code>0xFF</code>.		''Doom pictures'' are used for UI graphics, patches, sprites and wall textures. The file format is ''column-oriented,'' with each column being composed of zero or more ''posts'', which are basically arrays of pixels. These posts are assembled into a column based on their lengths and offsets. Each column starts at an offset defined in the header and is terminated by a byte containing <code>0xFF</code>.

	=== Headers ===		=== Headers ===
Line 110:		Line 110:

	=== Tall patches ===		=== Tall patches ===
	''Tall patches'' are a backwards-compatible hack to allow doom pictures ~~to be~~ larger than 256 pixels in height. Since ~~doom~~ pictures can theoretically be up to 65536x65536 pixels large, yet posts can only be up to 254 pixels long (with the byte value <code>255</code> serving as a, hack to ~~allow~~ for ~~Doom Pictures larger than 256 pixels in height~~.		''Tall patches'' are a backwards-compatible hack to allow doom pictures larger than 256 pixels in height. Since Doom pictures can theoretically be up to 65536x65536 pixels large, yet posts can only be up to 254 pixels long (with the byte value <code>255</code> serving as a terminating byte per-post), vanilla Doom pictures can practically only be 65536x508 pixels large. Tall patches hack around this limit by placing posts beyond <code>y=255</code> relatively to one another, theoretically allowing for an infinite vertical size.

	~~Whenever~~ a post's top delta is less than it's predecessor's top delta, an overflow is detected and both values are added together for the new top delta to allow for the tall patch. This makes top offsets beyond 254 effectively relative to one another, rather than absolute as before.		In a Doom engine supporting tall patches, whenever a post's top delta is less than it's predecessor's top delta, an overflow is detected and both values are added together for the new top delta to allow for the tall patch. This makes top offsets beyond 254 effectively relative to one another, rather than absolute as before.

	~~When~~ a Doom engine ~~does~~ not ~~support~~ tall patches, the posts in question will simply wrap and draw over the existing sprite space.		In a Doom engine ''not'' supporting tall patches, the posts in question will simply wrap and draw over the existing sprite space.

	Many tools like [https://slade.mancubus.net/ SLADE] and [https://github.com/liquidunderground/pk3make PK3Make] will also automatically insert zero-length pseudo patches at top delta 254 during image conversion to guarantee a reliable detection of tall patches.		Many tools like [https://slade.mancubus.net/ SLADE] and [https://github.com/liquidunderground/pk3make PK3Make] will also automatically insert zero-length pseudo patches at top delta 254 during image conversion to guarantee a reliable detection of tall patches.
	[[Category:Technology]]		[[Category:Technology]]

Nyamoru at 06:11, 7 June 2025

2025-06-07T06:11:55Z

← Older revision		Revision as of 02:11, 7 June 2025
Line 19:		Line 19:
	When rendered in-game, only the red channel is considered when dereferencing colors, with the value of the red channel serving as transparency or ''alpha channel'' for rendering the screen transition. For convenience, most artists prefer to draw screen fades as paletted grayscale images.		When rendered in-game, only the red channel is considered when dereferencing colors, with the value of the red channel serving as transparency or ''alpha channel'' for rendering the screen transition. For convenience, most artists prefer to draw screen fades as paletted grayscale images.

	When importing screen fades into your [[PK3]], it must be rendered into individual frames ~~and in-order under <code>Fades/</code>. The~~ file ~~name must match~~ <code>FADExxyy</code>, with <code>xx</code> standing for the screen fade number and <code>yy</code> standing for the frame.		When importing screen fades into your [[PK3]], it must be rendered into individual frames matching the file names <code>FADExxyy</code>, with <code>xx</code> standing for the screen fade number and <code>yy</code> standing for the frame number. All frames must then be placed <u>in a contiguous, numerically ordered list</u> under <code>Fades/</code>. Not maintaining continuity and/or numerical order will result in errors.

	== Picture Format ==		== Picture Format ==

Nyamoru: /* Picture Format */

2025-04-08T13:50:45Z

Picture Format

← Older revision		Revision as of 09:50, 8 April 2025
Line 41:		Line 41:
	\|2		\|2
	\|0		\|0
	\|Graphic width		\|Graphic width (Little Endian)
	\|-		\|-
	\|height		\|height
Line 47:		Line 47:
	\|2		\|2
	\|2		\|2
	\|Graphic height		\|Graphic height (Little Endian)
	\|-		\|-
	\|leftoffset		\|leftoffset
Line 53:		Line 53:
	\|2		\|2
	\|4		\|4
	\|Pixel offset from the left side		\|Pixel offset from the left side (Little Endian)
	\|-		\|-
	\|topoffset		\|topoffset
Line 59:		Line 59:
	\|2		\|2
	\|6		\|6
	\|Pixel offset from the top		\|Pixel offset from the top (Little Endian)
	\|-		\|-
	\|columnofs		\|columnofs
Line 65:		Line 65:
	\|4 * width		\|4 * width
	\|8		\|8
	\|Array of column offsets relative to the beginning of this header		\|Array of column offsets relative to the beginning of this header (Little Endian)
	\|}		\|}

Nyamoru at 12:59, 7 April 2025

2025-04-07T12:59:22Z

← Older revision		Revision as of 08:59, 7 April 2025
Line 117:		Line 117:

	Many tools like [https://slade.mancubus.net/ SLADE] and [https://github.com/liquidunderground/pk3make PK3Make] will also automatically insert zero-length pseudo patches at top delta 254 during image conversion to guarantee a reliable detection of tall patches.		Many tools like [https://slade.mancubus.net/ SLADE] and [https://github.com/liquidunderground/pk3make PK3Make] will also automatically insert zero-length pseudo patches at top delta 254 during image conversion to guarantee a reliable detection of tall patches.
			[[Category:Technology]]

Nyamoru: /* Picture Format */

2025-04-07T12:58:22Z

Picture Format

← Older revision		Revision as of 08:58, 7 April 2025
Line 22:		Line 22:

	== Picture Format ==		== Picture Format ==
			''Reference: [https://doomwiki.org/wiki/Picture_format Picture format on Doom Wiki]''

			''Doom pictures'' are used for UI graphics, patches, sprites and wall textures. The file format is ''column-oriented,'' with each column being composed of zero or more ''posts'', which are basically arrays of pixels. These posts are assembled into a column based on their lenghts and offsets. Each column starts at an offset defined in the header and is terminated by a byte containing <code>0xFF</code>.

			=== Headers ===
			Each Doom picture starts with a header, indexing the offsets of each column. When a picture is rendered, the engine starts drawing each column at the offset given in <code>columnofs</code> and draws all posts it finds until the next column starting with <code>0xFF</code> (column terminator byte).
			{\| class="wikitable"
			\|+
			Patch header data structure
			!Field
			!Type
			!Byte size
			!Byte offset
			!Description
			\|-
			\|width
			\|uint16_t
			\|2
			\|0
			\|Graphic width
			\|-
			\|height
			\|uint16_t
			\|2
			\|2
			\|Graphic height
			\|-
			\|leftoffset
			\|int16_t
			\|2
			\|4
			\|Pixel offset from the left side
			\|-
			\|topoffset
			\|int16_t
			\|2
			\|6
			\|Pixel offset from the top
			\|-
			\|columnofs
			\|uint32_t[]
			\|4 * width
			\|8
			\|Array of column offsets relative to the beginning of this header
			\|}

			=== Posts ===
			''Posts'' are one-dimensional strips of palette indices with a length and a top offset or ''top delta'' attached:
			{\| class="wikitable"
			\|+Post data structure
			!Field
			!Type
			!Byte size
			!Byte offset
			!Description
			\|-
			\|topdelta
			\|uint8_t
			\|1
			\|0
			\|Post offset from top
			\|-
			\|length
			\|uint8_t
			\|1
			\|1
			\|Post length
			\|-
			\|''padding''
			\|uint8_t
			\|1
			\|2
			\|Unused padding byte.
			\|-
			\|data
			\|uint8_t[]
			\|length
			\|3
			\|Array of palette indices
			\|-
			\|''padding''
			\|uint8_t
			\|1
			\|3 + length
			\|Unused padding byte
			\|}

			=== Tall patches ===
			''Tall patches'' are a backwards-compatible hack to allow doom pictures to be larger than 256 pixels in height. Since doom pictures can theoretically be up to 65536x65536 pixels large, yet posts can only be up to 254 pixels long (with the byte value <code>255</code> serving as a, hack to allow for Doom Pictures larger than 256 pixels in height.

			Whenever a post's top delta is less than it's predecessor's top delta, an overflow is detected and both values are added together for the new top delta to allow for the tall patch. This makes top offsets beyond 254 effectively relative to one another, rather than absolute as before.

			When a Doom engine does not support tall patches, the posts in question will simply wrap and draw over the existing sprite space.

			Many tools like [https://slade.mancubus.net/ SLADE] and [https://github.com/liquidunderground/pk3make PK3Make] will also automatically insert zero-length pseudo patches at top delta 254 during image conversion to guarantee a reliable detection of tall patches.

Nyamoru: Created page with "Weissblatt uses custom image formats for it's sprites, graphics and textures, which it inherited and extended from Doom (1993). All of these formats are ''paletted'', meaning they require a Color Palette to be rendered properly. == Flat == ''Flats'' are textures used for floors and ceilings. The file format is a simple dump of palette indices. Doom originally required these to be 64x64 pixels in size, but Weissblatt supports any..."

2025-04-07T12:14:08Z

Created page with "Weissblatt uses custom image formats for it's sprites, graphics and textures, which it inherited and extended from Doom (1993). All of these formats are ''paletted'', meaning they require a Color Palette to be rendered properly. == Flat == ''Flats'' are textures used for floors and ceilings. The file format is a simple dump of palette indices. Doom originally required these to be 64x64 pixels in size, but Weissblatt supports any..."

New page

Weissblatt uses custom image formats for it's sprites, graphics and textures, which it inherited and extended from [[wikipedia:Doom_(1993_video_game)|Doom (1993)]]. All of these formats are ''paletted'', meaning they require a [[Color Palette]] to be rendered properly.

== Flat ==
''Flats'' are textures used for floors and ceilings. The file format is a simple dump of palette indices. Doom originally required these to be 64x64 pixels in size, but Weissblatt supports any square size between 1x1 and 2048x2048.

=== Fade ===
The screen fade format is identical to flats; a simple dump of palette indices. Sizes are required to be one of the following:
{| class="wikitable"
!Image Size
|-
|80x50
|-
|160x100
|-
|320x200
|-
|640x400
|}
When rendered in-game, only the red channel is considered when dereferencing colors, with the value of the red channel serving as transparency or ''alpha channel'' for rendering the screen transition. For convenience, most artists prefer to draw screen fades as paletted grayscale images.

When importing screen fades into your [[PK3]], it must be rendered into individual frames and in-order under <code>Fades/</code>. The file name must match <code>FADExxyy</code>, with <code>xx</code> standing for the screen fade number and <code>yy</code> standing for the frame.

== Picture Format ==