Forums

I'm assuming that everyone knows how to use LDRI to synthesize scaling of 8x8 sprites down to 7x7, 6x6, 5x5, etc. If not, I'll start another thread on that.

When a large group of square sprites need to be rotated some odd number of degrees. We store several lookup tables for +/- 1 and 2 pixels of rotation (or about 3.5 and 7 degrees of rotation), each with a 2KB Rotational LookUp Table. That uses up 8KB but can remain on the cartridge ROM of 1024KB. This would allow objects to rotate a full rotation per second with a single pass, or two rotations per frame for about 1.6 rotations per second... perhaps for a barrel role on After Burner.

Loading objects as large as 32x32 (4x4 sprites, allowing objects with a radius as large as 16 bits without losing pixels) from game ROM, we also load the RLUT (Rotational LookUp Table) into RAM. The large object is 512 bytes (up to 16 sprites), but the RLUT is 1,024 addresses, so that's 2KB. For larger objects (say 6x6 sprites), we would need to keep one large RLUT on the game ROM. Since that's about 5KB each, it makes less sense to keep four different RLUTs at that size.

Since pixels are packed two to a byte (4 bits per pixel), they get rotated around in pairs, so the object may look a bit strange at or near 180 degrees of rotation, but their order is recovered when objects turn back around.

after burner sms snapshot.jpeg (78.36 KB)

Enemy fighters didn't look good leaning slightly in After Burner SMS.

maxxoccupancy wrote

Since pixels are packed two to a byte (4 bits per pixel), they get rotated around in pairs, so the object may look a bit strange at or near 180 degrees of rotation, but their order is recovered when objects turn back around.

You're confusing the way the Megadrive stores tile pixels with the way the Sega Master system stores tile pixels. The way pixels on the Master System are packed together makes that much more difficult.

haroldoop wrote

maxxoccupancy wrote

Since pixels are packed two to a byte (4 bits per pixel), they get rotated around in pairs, so the object may look a bit strange at or near 180 degrees of rotation, but their order is recovered when objects turn back around.

You're confusing the way the Megadrive stores tile pixels with the way the Sega Master system stores tile pixels. The way pixels on the Master System are packed together makes that much more difficult.

I've been checking for online documentation about this, and I'm not finding anything that detailed, even from the undocumented documentation. How does the SMS VDP pack pixels?

And why does this Forum discriminate against robots?

The data format is planar, so each byte holds one bit for each of eight pixels; each sequence of four bytes holds full data for eight pixels.

We discriminate against robots because the majority of them seem to be spambots. Apologies to innocent robots who are brought down by their evil cousins.

maxxoccupancy wrote

haroldoop wrote

maxxoccupancy wrote

Since pixels are packed two to a byte (4 bits per pixel), they get rotated around in pairs, so the object may look a bit strange at or near 180 degrees of rotation, but their order is recovered when objects turn back around.

You're confusing the way the Megadrive stores tile pixels with the way the Sega Master system stores tile pixels. The way pixels on the Master System are packed together makes that much more difficult.

I've been checking for online documentation about this, and I'm not finding anything that detailed, even from the undocumented documentation. How does the SMS VDP pack pixels?

And why does this Forum discriminate against robots?

According to this documentation :
https://www.smspower.org/uploads/Development/richard.txt

Tile definitions can be viewed as consisting of 8 32-bit little endian words,
one for each row of the tile definition. Then, the colour (a 4-bit value) of
each pixel in a tile row is defined by the following bits of the word:

Leftmost pixel 0: bits 31 (msb of colour), 23, 15, 7 (lsb of colour)
1: bits 30, 22, 14, 6
. . .
. . .
Rightmost pixel 7: bits 24, 16, 8, 0

e.g. in order to set the leftmost pixel of a tile row to colour 8, the
rightmost to colour 15, and leave all remaining pixels in colour 0, you would
write the following bytes to VRAM:

bit 7 0 15 8 23 16 31 24
00000001 00000001 00000001 10000001

So, each bit from each pixel is spread among multiple bytes.

So... eight 32-bit words... rather than 32 pairs of pixels? How did I miss that? That makes almost all pixel manipulation in software difficult to nearly impossible.

The entire sprite would have to be bit manipulated into 256 separate locations, moved by a very large LUT, then reassembled manually. You'd be better off just using the full 8 megabits to store all of the rotated and scaled versions of that sprite in the upper 4Mb banks.

I have one trick left up my sleeve for large objects, but that would be the subject of another thread. I'll have to think that one through. Remember how rotation was done in that Sonic level for the Genesis?

maxxoccupancy wrote

I have one trick left up my sleeve for large objects, but that would be the subject of another thread. I'll have to think that one through. Remember how rotation was done in that Sonic level for the Genesis?

In the case of Sonic 1's Bonus Stage, the entire maze is made of sprites.

While this trick can be certainly be used on the SMS, it would be severely limited by the pesky 8 sprites per line limit.

There's a lesser known, largely unused feature where the SMS can use 8x16 sprites. That doesn't help us for building boxes that rotate, but it would let us get around the 80 sprite per screen barrier.

True, but Street Fighter II, Lemmings, and Mortal Kombat would redraw tiles on the fly, giving them just 10-15 fps, but avoiding the flicker problem.

For a large, rotating, Sonic bonus stage, we could allow for very choppy frame rates and just move circular tiles around for the effect. You can also use a color cycling effect (like those used with waterfalls and lava) to get the tiles to move around more quickly.

Since tiles lock into an 8x8 grid, even getting them to move around in 4-pixel increments would result in needing to keep four copies of each tile in VRAM. That's not a big problem if only one or two background tile types are used. You could even get 64 copies of one tile, allowing for smooth, 1-pixel movements by rending every possible image. You could then use palette swapping to get circles of various colors.

However, the real benefit to rotation is getting very large objects and even bosses onscreen and getting them to rotate up and down a bit. The Megadrive has special horizontal and vertical line scrolling registers for the background tiles.

I'm checking the SMS VDP documentation and undocumented features for anything that will get the hardware to move large backgrounds. That's really the most fun that you can get out of the SMS.

Still even using the 8×16 sprites, you can't have more than 8 sprites on a scanline, which limits your horizontal size to 64 pixel max.

sverx wrote

Still even using the 8×16 sprites, you can't have more than 8 sprites on a scanline, which limits your horizontal size to 64 pixel max.

True, but there is also a limitation of 80 sprites on screen at a time. Since most characters onscreen are made up of several sprites, many shmups hit that limit before they ever see flicker. If you have anything clever going on at the top and bottom of the screen, you may have run out before you ship can say PEW PEW.

maxxoccupancy wrote

there is also a limitation of 80 sprites on screen at a time

no, there's a limit of 64 sprites in the SAT, but you could theoretically still display more than that. What you can't do is to show the contents of more than 8 sprites on any scanline (in a single frame)

sverx wrote

no, there's a limit of 64 sprites in the SAT, but you could theoretically still display more than that. What you can't do is to show the contents of more than 8 sprites on any scanline (in a single frame)

I should've looked that one up. For my 3D graphics game, that means that a section of screen equivalent to1/4 the width by 1/3 the height is the maximum that can be covered with textures and animation sprites. To attempt that at 256x224, that would only be 28% of that height with less time between frames to update the VRAM--which is almost full anyway with everything I want to do.

The point that I'm making is that 90% of the screen must be handled in background tiles, each line of which must be drawn from just 16 colors. My other post, "240 out of 343 colors" was meant to show how to break the color barrier and get 16-bit graphics out of the SMS.

Using the rarely used 8x16 sprites, we can still display 64 sprites on screen, and the SMS is still limited to 1/4 of the width used for sprites before flickering occurs. However, instead of only being able to show sprites for 1/3 of the height (at 256x192), those sprites could now build a box that is 2/3 the height of the screen.

There is also the consideration of Z80A CPU time, the main cause of slowdown and lower frame rates. A large area of the screen can be covered in sprite tiles more efficiently using 8x16 sprites.

Finally, for color mixing of still photos/images, color sprites give you access to the full range of 343 colors, and any combination of 16 background colors can be mixed with any combination of 15 colors from the sprite swatch, thereby letting you display 240 out of those 343 colors at once.

Since a game project that I'm working out requires tons of sprites to build textures for 3D graphics, and since most of the VFX considered at at least two sprites high, it makes sense for that one project to use 8x16 instead of 8x8.

Author	Message
maxxoccupancy Joined: 05 Mar 2022 Posts: 129 Location: Seabrook, New Hampshire	proposed method for rotation of sprites on SMS Posted: Sun Mar 06, 2022 4:25 am
	I'm assuming that everyone knows how to use LDRI to synthesize scaling of 8x8 sprites down to 7x7, 6x6, 5x5, etc. If not, I'll start another thread on that. When a large group of square sprites need to be rotated some odd number of degrees. We store several lookup tables for +/- 1 and 2 pixels of rotation (or about 3.5 and 7 degrees of rotation), each with a 2KB Rotational LookUp Table. That uses up 8KB but can remain on the cartridge ROM of 1024KB. This would allow objects to rotate a full rotation per second with a single pass, or two rotations per frame for about 1.6 rotations per second... perhaps for a barrel role on After Burner. Loading objects as large as 32x32 (4x4 sprites, allowing objects with a radius as large as 16 bits without losing pixels) from game ROM, we also load the RLUT (Rotational LookUp Table) into RAM. The large object is 512 bytes (up to 16 sprites), but the RLUT is 1,024 addresses, so that's 2KB. For larger objects (say 6x6 sprites), we would need to keep one large RLUT on the game ROM. Since that's about 5KB each, it makes less sense to keep four different RLUTs at that size. Since pixels are packed two to a byte (4 bits per pixel), they get rotated around in pairs, so the object may look a bit strange at or near 180 degrees of rotation, but their order is recovered when objects turn back around. after burner sms snapshot.jpeg (78.36 KB) Enemy fighters didn't look good leaning slightly in After Burner SMS.

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Sun Mar 06, 2022 9:36 am
	maxxoccupancy wrote Since pixels are packed two to a byte (4 bits per pixel), they get rotated around in pairs, so the object may look a bit strange at or near 180 degrees of rotation, but their order is recovered when objects turn back around. You're confusing the way the Megadrive stores tile pixels with the way the Sega Master system stores tile pixels. The way pixels on the Master System are packed together makes that much more difficult.

maxxoccupancy Joined: 05 Mar 2022 Posts: 129 Location: Seabrook, New Hampshire	Posted: Sun Mar 06, 2022 5:12 pm
	haroldoop wrote maxxoccupancy wrote Since pixels are packed two to a byte (4 bits per pixel), they get rotated around in pairs, so the object may look a bit strange at or near 180 degrees of rotation, but their order is recovered when objects turn back around. You're confusing the way the Megadrive stores tile pixels with the way the Sega Master system stores tile pixels. The way pixels on the Master System are packed together makes that much more difficult. I've been checking for online documentation about this, and I'm not finding anything that detailed, even from the undocumented documentation. How does the SMS VDP pack pixels? And why does this Forum discriminate against robots?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sun Mar 06, 2022 5:20 pm
	The data format is planar, so each byte holds one bit for each of eight pixels; each sequence of four bytes holds full data for eight pixels. We discriminate against robots because the majority of them seem to be spambots. Apologies to innocent robots who are brought down by their evil cousins.

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Sun Mar 06, 2022 5:22 pm
	maxxoccupancy wrote haroldoop wrote maxxoccupancy wrote Since pixels are packed two to a byte (4 bits per pixel), they get rotated around in pairs, so the object may look a bit strange at or near 180 degrees of rotation, but their order is recovered when objects turn back around. You're confusing the way the Megadrive stores tile pixels with the way the Sega Master system stores tile pixels. The way pixels on the Master System are packed together makes that much more difficult. I've been checking for online documentation about this, and I'm not finding anything that detailed, even from the undocumented documentation. How does the SMS VDP pack pixels? And why does this Forum discriminate against robots? According to this documentation : https://www.smspower.org/uploads/Development/richard.txt Tile definitions can be viewed as consisting of 8 32-bit little endian words, one for each row of the tile definition. Then, the colour (a 4-bit value) of each pixel in a tile row is defined by the following bits of the word: Leftmost pixel 0: bits 31 (msb of colour), 23, 15, 7 (lsb of colour) 1: bits 30, 22, 14, 6 . . . . . . Rightmost pixel 7: bits 24, 16, 8, 0 e.g. in order to set the leftmost pixel of a tile row to colour 8, the rightmost to colour 15, and leave all remaining pixels in colour 0, you would write the following bytes to VRAM: bit 7 0 15 8 23 16 31 24 00000001 00000001 00000001 10000001 So, each bit from each pixel is spread among multiple bytes.

maxxoccupancy Joined: 05 Mar 2022 Posts: 129 Location: Seabrook, New Hampshire	proposed method for rotation of sprites on SMS Posted: Sun Mar 06, 2022 7:21 pm
	So... eight 32-bit words... rather than 32 pairs of pixels? How did I miss that? That makes almost all pixel manipulation in software difficult to nearly impossible. The entire sprite would have to be bit manipulated into 256 separate locations, moved by a very large LUT, then reassembled manually. You'd be better off just using the full 8 megabits to store all of the rotated and scaled versions of that sprite in the upper 4Mb banks. I have one trick left up my sleeve for large objects, but that would be the subject of another thread. I'll have to think that one through. Remember how rotation was done in that Sonic level for the Genesis?

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Sun Mar 06, 2022 8:50 pm
	maxxoccupancy wrote I have one trick left up my sleeve for large objects, but that would be the subject of another thread. I'll have to think that one through. Remember how rotation was done in that Sonic level for the Genesis? In the case of Sonic 1's Bonus Stage, the entire maze is made of sprites. While this trick can be certainly be used on the SMS, it would be severely limited by the pesky 8 sprites per line limit.

maxxoccupancy Joined: 05 Mar 2022 Posts: 129 Location: Seabrook, New Hampshire	8 sprites per line Posted: Mon Mar 07, 2022 7:47 pm
	There's a lesser known, largely unused feature where the SMS can use 8x16 sprites. That doesn't help us for building boxes that rotate, but it would let us get around the 80 sprite per screen barrier. True, but Street Fighter II, Lemmings, and Mortal Kombat would redraw tiles on the fly, giving them just 10-15 fps, but avoiding the flicker problem. For a large, rotating, Sonic bonus stage, we could allow for very choppy frame rates and just move circular tiles around for the effect. You can also use a color cycling effect (like those used with waterfalls and lava) to get the tiles to move around more quickly. Since tiles lock into an 8x8 grid, even getting them to move around in 4-pixel increments would result in needing to keep four copies of each tile in VRAM. That's not a big problem if only one or two background tile types are used. You could even get 64 copies of one tile, allowing for smooth, 1-pixel movements by rending every possible image. You could then use palette swapping to get circles of various colors. However, the real benefit to rotation is getting very large objects and even bosses onscreen and getting them to rotate up and down a bit. The Megadrive has special horizontal and vertical line scrolling registers for the background tiles. I'm checking the SMS VDP documentation and undocumented features for anything that will get the hardware to move large backgrounds. That's really the most fun that you can get out of the SMS.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Mar 08, 2022 7:47 am
	Still even using the 8×16 sprites, you can't have more than 8 sprites on a scanline, which limits your horizontal size to 64 pixel max.

maxxoccupancy Joined: 05 Mar 2022 Posts: 129 Location: Seabrook, New Hampshire	Posted: Tue Mar 08, 2022 4:13 pm
	sverx wrote Still even using the 8×16 sprites, you can't have more than 8 sprites on a scanline, which limits your horizontal size to 64 pixel max. True, but there is also a limitation of 80 sprites on screen at a time. Since most characters onscreen are made up of several sprites, many shmups hit that limit before they ever see flicker. If you have anything clever going on at the top and bottom of the screen, you may have run out before you ship can say PEW PEW.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Mar 08, 2022 4:53 pm
	maxxoccupancy wrote there is also a limitation of 80 sprites on screen at a time no, there's a limit of 64 sprites in the SAT, but you could theoretically still display more than that. What you can't do is to show the contents of more than 8 sprites on any scanline (in a single frame)

maxxoccupancy Joined: 05 Mar 2022 Posts: 129 Location: Seabrook, New Hampshire	Posted: Wed Mar 09, 2022 1:59 am
	sverx wrote no, there's a limit of 64 sprites in the SAT, but you could theoretically still display more than that. What you can't do is to show the contents of more than 8 sprites on any scanline (in a single frame) I should've looked that one up. For my 3D graphics game, that means that a section of screen equivalent to1/4 the width by 1/3 the height is the maximum that can be covered with textures and animation sprites. To attempt that at 256x224, that would only be 28% of that height with less time between frames to update the VRAM--which is almost full anyway with everything I want to do. The point that I'm making is that 90% of the screen must be handled in background tiles, each line of which must be drawn from just 16 colors. My other post, "240 out of 343 colors" was meant to show how to break the color barrier and get 16-bit graphics out of the SMS. Using the rarely used 8x16 sprites, we can still display 64 sprites on screen, and the SMS is still limited to 1/4 of the width used for sprites before flickering occurs. However, instead of only being able to show sprites for 1/3 of the height (at 256x192), those sprites could now build a box that is 2/3 the height of the screen. There is also the consideration of Z80A CPU time, the main cause of slowdown and lower frame rates. A large area of the screen can be covered in sprite tiles more efficiently using 8x16 sprites. Finally, for color mixing of still photos/images, color sprites give you access to the full range of 343 colors, and any combination of 16 background colors can be mixed with any combination of 15 colors from the sprite swatch, thereby letting you display 240 out of those 343 colors at once. Since a game project that I'm working out requires tons of sprites to build textures for 3D graphics, and since most of the VFX considered at at least two sprites high, it makes sense for that one project to use 8x16 instead of 8x8.

Forums

View topic - proposed method for rotation of sprites on SMS