Sprites As Tiles On The 7800 - Revision history

MSaarna at 13:46, 10 April 2020

2020-04-10T13:46:06Z

MSaarna at 03:11, 10 April 2020

2020-04-10T03:11:03Z

MSaarna at 02:43, 10 April 2020

2020-04-10T02:43:57Z

MSaarna: Created page with "==Overview== The 7800 has two kinds of display objects, namely sprite objects and character objects (aka tiles). Each of these object types has different advantages and disad..."

2020-03-29T18:15:35Z

Created page with "==Overview== The 7800 has two kinds of display objects, namely sprite objects and character objects (aka tiles). Each of these object types has different advantages and disad..."

New page

==Overview==

The 7800 has two kinds of display objects, namely sprite objects and character objects (aka tiles). Each of these object types has different advantages and disadvantages, when compared to the other.

Character graphics allows for quick update of displayed graphics by simply modifying the character index at a particular character position. The main disadvantage when using character objects, is they take longer for Maria to render than sprites, and so using a lot of character objects may limit the overall number of objects you can display. Since any particular character object can only be in one palette, you either you wind up with a less colorful screen of graphics, or you reduce your render time even more by using multiple character objects whenever you need different palettes.

Maria can render sprite objects much quicker than character objects, and while sprites aren't character tiles, you can create display lists with many sprites tiled across the screen. This technique can allow you to create very colorful "tiled" game screens, which maximize the number of moving display objects.

==DMA Cost Analysis of Sprites Vs Tiles==

There are two factors to consider when weighing sprites vs tiles.

The first factor to consider is the cost of the DMA object setup - i.e. the processing required by Maria to parse the DL structure, prior to fetching any graphics. This overhead only happens once per object, but since we need to replace our single character object with multiple sprite objects, it imposes a cost to sprite-tile DMA time. For a 5 byte object (sprite or tile) the DMA object setup cost is 10 cycles, and for a 4 byte object (sprite) the cost is 8 cycles.

The second factor is the cost of fetching consecutive bytes of graphics. Maria uses 3 cycles for each byte of sprite graphics it fetches, and 6 cycles for each byte of character graphics it fetches. One wrinkle here is that in double-wide mode, Maria will use 9 cycles for each set of bytes, instead of the usual 12.

For the following analyses we'll compare sprite tiles vs character tiles. We'll look at the 4-byte sprites, 5-byte sprites, single-wide characters, and lastly double-wide characters, and see where the DMA advantage is in each scenario.

===scenario 1... 1 sprite-tile = 1 byte of graphics data===

The DMA cost for 30 bytes worth of graphics, using single-width character-tile graphics is (10 cycles) + (30 * 6 cycles), or 190 cycles.

The DMA cost for 30 bytes worth of graphics, using double-width character-tile graphics is (10 cycles) + (30 * 4.5 cycles), or 145 cycles.

The DMA cost for 30 bytes worth of graphics, using 4-byte sprite-tiles of width=1 byte is (30 * 8 cycles) + (30 * 3 cycles), or 330 cycles.

The DMA cost for 30 bytes worth of graphics, using 5-byte sprite-tiles of width=1 byte is (30 * 10 cycles) + (30 * 3 cycles), or 390 cycles.

Clearly sprite-tiles lose vs character-tiles, if you require that each tile width be 1 byte of graphics data.

===scenario 2... 1 sprite-tile = 2 bytes of graphics data===

The DMA cost for 30 bytes worth of graphics, using single-width character-tile graphics is (10 cycles) + (30 * 6 cycles), or 190 cycles.

The DMA cost for 30 bytes worth of graphics, using double-width character-tile graphics is (10 cycles) + (30 * 4.5 cycles), or 145 cycles.

The DMA cost for 30 bytes worth of graphics, using 4-byte sprite-tiles of width=2 byte is (15 * 8 cycles) + (30 * 3 cycles), or 210 cycles.

The DMA cost for 30 bytes worth of graphics, using 5-byte sprite-tiles of width=2 byte is (15 * 10 cycles) + (30 * 3 cycles), or 240 cycles.

sprite-tiles are still losing vs character-tiles, but the gap appears to be closing rapidly.

===scenario 3... 1 sprite-tile = 3 bytes of graphics data===

The DMA cost for 30 bytes worth of graphics, using single-width character-tile graphics is (10 cycles) + (30 * 6 cycles), or 190 cycles.

The DMA cost for 30 bytes worth of graphics, using double-width character-tile graphics is (10 cycles) + (30 * 4.5 cycles), or 145 cycles.

The DMA cost for 30 bytes worth of graphics, using 4-byte sprite-tiles of width=3 byte is (10 * 8 cycles) + (30 * 3 cycles), or 170 cycles.

The DMA cost for 30 bytes worth of graphics, using 5-byte sprite-tiles of width=3 byte is (10 * 10 cycles) + (30 * 3 cycles), or 190 cycles.

Here we see either flavor of sprite-tiles having advantage over single-width character-tiles, and creeping up to double-wide character-tiles.

===scenario 4... 1 sprite-tile = 4 bytes of graphics data===

Note: we switch here to 32 bytes worth of graphics, for easier division by 4 bytes

The DMA cost for 32 bytes worth of graphics, using single-width character-tile graphics is (10 cycles) + (32 * 6 cycles), or 202 cycles.

The DMA cost for 32 bytes worth of graphics, using double-width character-tile graphics is (10 cycles) + (32 * 4.5 cycles), or 154 cycles.

The DMA cost for 32 bytes worth of graphics, using 4-byte sprite-tiles of width=4 byte is (8 * 8 cycles) + (32 * 3 cycles), or 160 cycles.

The DMA cost for 32 bytes worth of graphics, using 5-byte sprite-tiles of width=4 byte is (8 * 10 cycles) + (32 * 3 cycles), or 176 cycles.

@@ Line 5: / Line 5: @@
 Character graphics allows for quick update of displayed graphics by simply modifying the character index at a particular character position. The main disadvantage when using character objects, is they take longer for Maria to render than sprites, and so using a lot of character objects may limit the overall number of objects you can display. Since any particular character object can only be in one palette, you either you wind up with a less colorful screen of graphics, or you reduce your render time even more by using multiple character objects whenever you need different palettes.
-Maria can render sprite objects much quicker than character objects, and while sprites aren't character tiles, you can create display lists with many sprites tiled across the screen. This technique can allow you to create very colorful "tiled" game screens, which maximize the number of moving display objects.
+Maria can render individual sprite objects much quicker than individual character objects, and while sprites aren't character tiles, you can create display lists with many sprites tiled across the screen. This technique can allow you to create very colorful tiled game screens, while maximizing both the number of display objects and the cycles available to the 6502.
-==DMA Cost Analysis of Sprites Vs Tiles==
+==DMA Cost of Sprites Vs Tiles==
-There are two factors to consider when weighing sprites vs tiles.
+There are two factors that need to be considered when when weighing  consider when weighing sprites vs tiles.
 The first factor to consider is the cost of the DMA object setup - i.e. the processing required by Maria to parse the DL structure, prior to fetching any graphics. This overhead only happens once per object, but since we need to replace our single character object with multiple sprite objects, it imposes a cost to sprite-tile DMA time. For a 5 byte object (sprite or tile) the DMA object setup cost is 10 cycles, and for a 4 byte object (sprite) the cost is 8 cycles.
@@ Line 16: / Line 16: @@
 The second factor is the cost of fetching consecutive bytes of graphics. Maria uses 3 cycles for each byte of sprite graphics it fetches, and 6 cycles for each byte of character graphics it fetches. In double-wide mode, Maria will use 9 cycles for each pair of bytes, instead of the usual 12.
-The following table shows the comparitive DMA cost for fetching 24 bytes worth of graphics, using one single-wide character object vs. one double-wide character object vs. sprites of varying byte widths. Bear in mind that each sprite object can have an independent palette, which the characters in the character object must all be of the same palette.
+The following table shows the comparative DMA cost for fetching 24 bytes worth of graphics, using one single-wide character object vs. one double-wide character object vs. sprites of varying byte widths. Bear in mind that each sprite object can have an independent palette, which the characters in the character object must all be of the same palette.
 [[File:DMA Comparison.png]]

← Older revision		Revision as of 03:11, 10 April 2020
Line 17:		Line 17:

	The following table shows the comparitive DMA cost for fetching 24 bytes worth of graphics, using one single-wide character object vs. one double-wide character object vs. sprites of varying byte widths. Bear in mind that each sprite object can have an independent palette, which the characters in the character object must all be of the same palette.		The following table shows the comparitive DMA cost for fetching 24 bytes worth of graphics, using one single-wide character object vs. one double-wide character object vs. sprites of varying byte widths. Bear in mind that each sprite object can have an independent palette, which the characters in the character object must all be of the same palette.
		+
		+	[[File:DMA Comparison.png]]