WF16 Video Architecture - Revision history

WF: /* Tiles */

2026-08-13T02:24:14Z

Tiles

← Older revision		Revision as of 22:24, 12 August 2026
Line 224:		Line 224:
	Need to ensure that tile layers are max 65536 pixels wide/tall, since that's what the scroll layers deal with.		Need to ensure that tile layers are max 65536 pixels wide/tall, since that's what the scroll layers deal with.

	Enable meta-tiles, define the meta-map size x/y tiles. So each "tile" is a tilemap itself, can make huge worlds easily without using large ~~tilemap~~ pixel ~~sets~~. The metatile set is laid out one metatile at a time, which is X-length rows Y times, then the next metatile starts. Each axis should be a power of 2, doesn't have to be square? 3 bits each for x/y lets you choose 2/4/8/16/32/64/128/256? The attributes would likely be in this metalayer, the selection of metatiles probably wouldn't have any attributes? The toplevel metatile selection would simply be 16-bit metatile number. TODO - Would have to reconsider how to parameterize attributes from that selection, if at all.		Enable meta-tiles, define the meta-map size x/y tiles. So each "tile" is a tilemap itself, can make huge worlds easily without using large tile pixel sizes. The metatile set is laid out one metatile at a time, which is X-length rows Y times, then the next metatile starts. Each axis should be a power of 2, doesn't have to be square? 3 bits each for x/y lets you choose 2/4/8/16/32/64/128/256? The attributes would likely be in this metalayer, the selection of metatiles probably wouldn't have any attributes? The toplevel metatile selection would simply be 16-bit metatile number. TODO - Would have to reconsider how to parameterize attributes from that selection, if at all.

	For DDR3 tilemaps, it reads an entire row into a buffer. For SRAM, it fetches each tilemap entry as it becomes visible, then fetches the pixels separately, and caches them.		For DDR3 tilemaps, it reads an entire row into a buffer. For SRAM, it fetches each tilemap entry as it becomes visible, then fetches the pixels separately, and caches them.

WF: /* Tiles */

2026-08-13T01:33:20Z

Tiles

← Older revision		Revision as of 21:33, 12 August 2026
Line 223:		Line 223:

	Need to ensure that tile layers are max 65536 pixels wide/tall, since that's what the scroll layers deal with.		Need to ensure that tile layers are max 65536 pixels wide/tall, since that's what the scroll layers deal with.

			Enable meta-tiles, define the meta-map size x/y tiles. So each "tile" is a tilemap itself, can make huge worlds easily without using large tilemap pixel sets. The metatile set is laid out one metatile at a time, which is X-length rows Y times, then the next metatile starts. Each axis should be a power of 2, doesn't have to be square? 3 bits each for x/y lets you choose 2/4/8/16/32/64/128/256? The attributes would likely be in this metalayer, the selection of metatiles probably wouldn't have any attributes? The toplevel metatile selection would simply be 16-bit metatile number. TODO - Would have to reconsider how to parameterize attributes from that selection, if at all.

	For DDR3 tilemaps, it reads an entire row into a buffer. For SRAM, it fetches each tilemap entry as it becomes visible, then fetches the pixels separately, and caches them.		For DDR3 tilemaps, it reads an entire row into a buffer. For SRAM, it fetches each tilemap entry as it becomes visible, then fetches the pixels separately, and caches them.
Line 320:		Line 322:

	Neo Geo has auto-animating tiles/sprites. 4 or 8 tiles in a row in the tileset can be cycled through for animation. (cycling through low 2 or 3 bits of tile index). Global or layer-specific config for how may frames per step.		Neo Geo has auto-animating tiles/sprites. 4 or 8 tiles in a row in the tileset can be cycled through for animation. (cycling through low 2 or 3 bits of tile index). Global or layer-specific config for how may frames per step.

	~~Meta-tilemap mode, so the tilemap holds entries that are 2×2 or 4×4 hardware tilemap entries.~~

	Priorities aren't all that often use, but might be a good feature to have, especially to save on tilemap layers and scads of empty entries in those additional layers. Place the "background" in front of the sprite layer, with the tile either high priority drawing, or deferring to the sprite layer below it. If the priority is low, it passes the color to the sprite layer, and if the sprite layer has no pixel, it draws that bg pixel. If the tile pixel is transparent, then transparent behavior applies regardless of priority and nothing is different.		Priorities aren't all that often use, but might be a good feature to have, especially to save on tilemap layers and scads of empty entries in those additional layers. Place the "background" in front of the sprite layer, with the tile either high priority drawing, or deferring to the sprite layer below it. If the priority is low, it passes the color to the sprite layer, and if the sprite layer has no pixel, it draws that bg pixel. If the tile pixel is transparent, then transparent behavior applies regardless of priority and nothing is different.

WF: /* Sprites */

2026-08-06T20:37:43Z

Sprites

← Older revision		Revision as of 16:37, 6 August 2026
Line 330:		Line 330:
	H-flip at the very minimum. If V-flip and 90° (since all sprites/tiles are square sized), then all 8 orientations and flips are possible. Rotation is only available in SRAM.		H-flip at the very minimum. If V-flip and 90° (since all sprites/tiles are square sized), then all 8 orientations and flips are possible. Rotation is only available in SRAM.

	16-bit sprite image selection from base pointer, based on bpp & size. Flip bits might be at MSBs of the word. 3 flip bits means 8192 sprite images.		16-bit sprite image selection from base pointer, based on bpp & size. Flip bits might be at MSBs of the word. 3 flip bits means 8192 sprite images. The top 2 bits of sprite number should be a bank number. 4 sprite base pointers should be available. This allows to switch out individual sprite banks while keeping others active.

	Sprite sheet mode (kinda like square for tilesets), with a declared stride.		Sprite sheet mode (kinda like square for tilesets), with a declared stride.

WF: /* Sprites */

2026-04-15T01:12:09Z

Sprites

← Older revision		Revision as of 21:12, 14 April 2026
Line 338:		Line 338:
	Need to figure out something for 8bpp color, to have palette swaps for limited ranges. The layer could have a color range/mask where all colors less than that use the sprite color. But this can probably be done with just an OR mask (or XOR for fun?). 8bpp sprites would normally have a 0 'color', palette swaps would leave a range of bits open and use the individual sprite color to set that, but we don't want that done on all bits, only those that are in "palette range", hence the layer setting. Maybe also only when the color is nonzero? or non-FF? Or if the color is 0-16, then it has 16 color selections as a 4bpp color? Colors 17-255 would be normal. Use the top bit of the color byte to select this coloring mode.		Need to figure out something for 8bpp color, to have palette swaps for limited ranges. The layer could have a color range/mask where all colors less than that use the sprite color. But this can probably be done with just an OR mask (or XOR for fun?). 8bpp sprites would normally have a 0 'color', palette swaps would leave a range of bits open and use the individual sprite color to set that, but we don't want that done on all bits, only those that are in "palette range", hence the layer setting. Maybe also only when the color is nonzero? or non-FF? Or if the color is 0-16, then it has 16 color selections as a 4bpp color? Colors 17-255 would be normal. Use the top bit of the color byte to select this coloring mode.

	8×8, 16×16, 32×32, 64×64 sizes (2 bit selection, forget 24×24) TG16 had ~~64×64~~ and did interesting pseudo-layer and huge enemy stuff with it.		8×8, 16×16, 32×32, 64×64 sizes (2 bit selection, forget 24×24) TG16 had 64px tall (though 32px wide max) and did interesting pseudo-layer and huge enemy stuff with it.

	1,2,4,8 bpp (2 bit selection)		1,2,4,8 bpp (2 bit selection)

WF: /* Bitmaps */

2026-04-15T00:04:53Z

Bitmaps

← Older revision		Revision as of 20:04, 14 April 2026
Line 208:		Line 208:

	DDR3 suits bitmaps the best, ensure that gets supported. A 640×480×8bpp (+307,200 $4B000 bytes) single layer mode would also be nice for GUI and PC game ports, especially with blitter support. Scrolling can still be supported, maybe more than 1 layer might be doable as well.		DDR3 suits bitmaps the best, ensure that gets supported. A 640×480×8bpp (+307,200 $4B000 bytes) single layer mode would also be nice for GUI and PC game ports, especially with blitter support. Scrolling can still be supported, maybe more than 1 layer might be doable as well.

			Scrolllable (requires stride or power-of-2 width/height etc) vs fixed (320x240\|200 linear)

			RLE vs uncompressed. If RLE is scrollable, it'll need the line index. If RLE is fixed, then spans can cross scanlines and it's basically a continuous 1d compression

	== Tiles ==		== Tiles ==

WF: /* Sprites */

2026-04-13T01:13:34Z

Sprites

← Older revision		Revision as of 21:13, 12 April 2026
Line 342:		Line 342:
	Overdraw avoidance eliminates pulling in unseen pixels, which prevents hardware collision detection, which is fine.		Overdraw avoidance eliminates pulling in unseen pixels, which prevents hardware collision detection, which is fine.

	I do like the genesis idea of having a linked list of active sprites, as it can save time scanning the active sprites and finishing early. Question is should there be multiple sprite layers, each with their own list head, or one sprite list with each sprite having its depth independently set with its priority bits?		I do like the genesis idea of having a linked list of active sprites, as it can save time scanning the active sprites and finishing early. Question is should there be multiple sprite layers, each with their own list head, or one sprite list with each sprite having its depth independently set with its priority bits? However, the initial scan of the sprite registers could assemble one linked list per layer. For each sprite, do vertical & horizontal clipping, if it's visible onscreen, then add it to the head of the linked list for its particular layer. 2 writes: update head pointer in layer, update next pointer in BRAM. This can be pipelined if needed. Then on render, multiple sprites can be set up simultaneously, if they don't overlap. So if we have 2 sprite renderer blocks, then if (xMax_Back ≥ xMin_Front) && (xMin_Back ≤ x2Front) then there is overlap and the back sprite stalls waiting for the front sprite to finish. Need to calculate the mask of pixels they need, which based on base pointer plus bit depth, yields a sparse list of addresses that need to be read. Now, I think all graphics need this computation and might be part of the actual ram bus driver to save space?

	For transparency, we probably need 2 sprite linebuffers, one for the transparent part, and one for the solid part. Each holds its own layer in the upper bits. 18 bit entries = 16-bit 4444 RGBA, plus 2 bits layer selection. Now, there's nothing for enabling/disabling the pixel, though. The transparency layer could be enabled by alpha channel, and because of stacked blending of transparent requires the actual full color value. The solid layer could do clut + 8bpp + enable bit, for 13 bits total, or 12bpp plus 2bpp layer plus 1bbp enable, for 15 bits total, since we know that's not transparent. We probably want a flag for the layer/global as to whether sprite transparency stacks or not, since enabling it will blend deeper transparent sprite pixels from being obscured to the topmost transparency layer.		For transparency, we probably need 2 sprite linebuffers, one for the transparent part, and one for the solid part. Each holds its own layer in the upper bits. 18 bit entries = 16-bit 4444 RGBA, plus 2 bits layer selection. Now, there's nothing for enabling/disabling the pixel, though. The transparency layer could be enabled by alpha channel, and because of stacked blending of transparent requires the actual full color value. The solid layer could do clut + 8bpp + enable bit, for 13 bits total, or 12bpp plus 2bpp layer plus 1bbp enable, for 15 bits total, since we know that's not transparent. We probably want a flag for the layer/global as to whether sprite transparency stacks or not, since enabling it will blend deeper transparent sprite pixels from being obscured to the topmost transparency layer.

WF: /* Sprites */

2026-03-13T17:02:52Z

Sprites

← Older revision		Revision as of 13:02, 13 March 2026
Line 505:		Line 505:
	\|2MB		\|2MB
	\|64		\|64
	\|6		\|8
	\| colspan="8" \|Tile Address MSB		\| colspan="8" \|Tile Address MSB
	\|—		\|—

WF: /* Tiles */

2026-02-21T05:48:45Z

Tiles

← Older revision		Revision as of 01:48, 21 February 2026
Line 68:		Line 68:
	\|16-31		\|16-31
	\|		\|
			\|-
			\|'''F256'''
			\|1024
			\|888
			\|4×256
			\|0-3
			\|0-3
			\|No 4bpp, this is all 8bpp
	\|-		\|-
	\|'''CX16'''		\|'''CX16'''
Line 79:		Line 87:
	\|'''Neo Geo'''		\|'''Neo Geo'''
	\|4096		\|4096
	\|~~444~~		\|666
	\|256×16		\|256×16
	\|—		\|—
	\|0-255		\|0-255
	\|Everything is sprites		\|Everything is sprites. RGB channels share low bit, 5551 = 16 bits
	\|-		\|-
	\|'''Commando'''		\|'''Commando'''
Line 251:		Line 259:
	\| colspan="4" \|Palette (0-15)		\| colspan="4" \|Palette (0-15)
	\| colspan="12" \|Tile (0-4095)		\| colspan="12" \|Tile (0-4095)
			\|-
			\|'''F256'''
			\|—
			\|—
			\|—
			\| colspan="2" \|Palette (0-3)
			\| colspan="3" \|Tileset (0-7)
			\| colspan="8" \|Tile (0-255)
	\|-		\|-
	\|'''CX16'''		\|'''CX16'''
Line 486:		Line 502:
	\| colspan="20" \|		\| colspan="20" \|
	\|-		\|-
	\|'''~~F256K~~'''		\|'''F256'''
	\|2MB		\|2MB
	\|64		\|64
Line 692:		Line 708:
	\|		\|
	\|-		\|-
	\|'''~~F256K~~'''		\|'''F256'''
	\|64 or 128 (no limit)		\|64 or 128 (no limit)
	\|		\|

WF: /* Global settings */

2026-02-20T06:49:57Z

Global settings

← Older revision		Revision as of 02:49, 20 February 2026
Line 2:		Line 2:
	CRT emulation, only for low resolution layers.		CRT emulation, only for low resolution layers.

	640×480 for 4:3 output, or 960×540 for 16:9 output, if bandwidth can run it. Requires 1.6875× the bandwidth.		640×480 for 4:3 output, or 960×540 for 16:9 output, if bandwidth can run it. Requires 1.6875× the bandwidth, which should on its own be feasible.

	~~Non-integer pixel aspect flags~~, ~~again only for low res layers. Match 320×200 and 256×200 non-square aspects blended~~ on ~~a 480p/540p base output. Keep it at 60Hz~~.
	{\| class="wikitable"		{\| class="wikitable"
	!		!
Line 18:		Line 16:
	\|186.625 MHz		\|186.625 MHz
	\|}		\|}
			Non-integer pixel aspect flags, again only for low res layers. Match 320×200 and 256×200 non-square aspects blended on a 480p/540p base output. Keep it at 60Hz.

	Select 50 or 60 Hz in any resolution. Ditch 70Hz, as nothing syncs to that in the PC space for compatibility. 50Hz is much lower priority, but can be done by extending vblank time and keeping pixel clock the same. If 640×400 res is still used, have it at 60Hz, again same pixel clock but longer vblank.		Select 50 or 60 Hz in any resolution. Ditch 70Hz, as nothing syncs to that in the PC space for compatibility. 50Hz is much lower priority, but can be done by extending vblank time and keeping pixel clock the same. If 640×400 res is still used, have it at 60Hz, again same pixel clock but longer vblank.

WF: /* Global settings */

2026-02-20T06:45:43Z

Global settings

← Older revision		Revision as of 02:45, 20 February 2026
Line 4:		Line 4:
	640×480 for 4:3 output, or 960×540 for 16:9 output, if bandwidth can run it. Requires 1.6875× the bandwidth.		640×480 for 4:3 output, or 960×540 for 16:9 output, if bandwidth can run it. Requires 1.6875× the bandwidth.

	Non-integer pixel aspect flags, again only for low res layers. Match 320×200 and 256×200 non-square aspects blended on a 480p/540p base output. Keep it at 60Hz		Non-integer pixel aspect flags, again only for low res layers. Match 320×200 and 256×200 non-square aspects blended on a 480p/540p base output. Keep it at 60Hz.
			{\| class="wikitable"
			!
			!Dot clock
			!HDMI Serializer
			\|-
			\|640x480
			\|25.175 MHz
			\|125.875 MHz
			\|-
			\|960x540
			\|37.125 MHz
			\|186.625 MHz
			\|}
	Select 50 or 60 Hz in any resolution. Ditch 70Hz, as nothing syncs to that in the PC space for compatibility. 50Hz is much lower priority, but can be done by extending vblank time and keeping pixel clock the same. If 640×400 res is still used, have it at 60Hz, again same pixel clock but longer vblank.		Select 50 or 60 Hz in any resolution. Ditch 70Hz, as nothing syncs to that in the PC space for compatibility. 50Hz is much lower priority, but can be done by extending vblank time and keeping pixel clock the same. If 640×400 res is still used, have it at 60Hz, again same pixel clock but longer vblank.