at the very least i thought it should perform the same regardless of the size of the ram, turns out they very specifically made it with that 1MB cart in mind.
-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
Strictly from a technological perspective, could Street Fighter III have been ported to the Sega Saturn?
- Thread starter AragornsTaxPlan
- Start date
at the very least i thought it should perform the same regardless of the size of the ram, turns out they very specifically made it with that 1MB cart in mind.
The dreamcast has hardware vector quantization decompression in vram, as much as 1:16 ratio, you don't need bitdepth reduction to save vram.
There are a few palette related things that the Sega Saturn (and Sega Genesis) can do that the Dreamcast has a very hard time replicating. The entire reason the Dreamcast has a palette mode in the first place is that it's actually a neat trick you can do with the hardware vector quantization unit inside of the PVR2 core. Vector Quantization is a method of compression that can be applied to textures, it breaks textures up into 2x2 square patterns of pixels that are stored in a dictionary of 1024 slots. By doubling the width and height of a 2D image, you can make it so each dictionary pattern for the VQ unit becomes essentially a 2x2 pixel, which is referenced from textures via an index. A side effect of how the dreamcast's VQ works is that it expects pixels in memory to be near each other in what is called a morton pattern, a special type of octree that forms a Z-ordered curve. In colloquial terms, textures on the dreamcast are said to be "twizzled." Twizzling your textures has numerous benefits beyond being able to help with VQ, such as making 2x2 AA a free operation, for example. But the gist of it all is that, in order to use VQ, the pixels in your texture must be in a non-linear, unique order. Converting to this order on the fly is actually really hard for the Dreamcast CPU. In order to use VQ, you realistically need to build your textures before using them, it's not very easy to generate twizzled textures on the fly. That means, as a side effect, it's really hard to draw generate paletted images on the Dreamcast in real time. The Sega Saturn and Sega Genesis can do this with ease, it's the way their video hardware is built to work. But the dreamcast struggles.
The inability to generate paletted images on the fly was a major bottleneck for emulation development on the Dreamcast. When systems would need to change their tilesheets on the fly, it would grind the Dreamcast to a halt. That said, I know of a very recent way to achieve this on the Dreamcast, at the expense of using four times as much ram.
OP
OP
Just to clarify, when you say "paletted image", you're referring to a single frame of a sprite or any other 2D texture, correct?
Basically we're talking about, "Give me a relative X/Y coordinate, a value for red, green and blue, and I'll draw you a pixel" versus "Give me the memory address of the pre-loaded texture that you want me to display & tell me where"?
no, you're confused about the terminology. firstly, To clarify what I'm talking about, you need to know what sprites actually are, how they work, and why they exist. Let's start with basics -- in computer graphics, pixels (colored dots that make up an image) are stored in memory as numeric data. How this data is stored matters. For the most part, in modern graphics technologies, pixels are stored in groups in memory as you describe them - 3 values back to back to back that represents the percentage of red, green, and blue that makes up a single pixel. Storing numeric data in memory back to back to back like that is called a chunky pixel format, because the data is together as a single chunk.
Now, the range this numeric data can represent is determined by how many bits are reserved for each numeral. Bits are the basic unit of computing, they represent the smallest element of data, either a 1 or a 0. Alone, a bit is basically meaningless, but when you group bits together, they can represent numbers. Example - 1011 is a bit string that represents the number 13. More specifically, the string 1111 represents 15 and the string 0000 represents 0, and if you step through every single possible 4-bit string from 0000 to 1111 you will find that there are 16 unique combinations possible. The bitdepth, the number of bits in the string, determines the number of unique combinations you can have.
Representing color as you described earlier, with each pixel in memory being a triplet group of red, green, and blue values takes up a lot of memory. Traditionally today, we operate at 24-bit color where the bits representing each color percentage have a bitdepth of 8, meaning you have 256 values that red, green, and blue can each independently be at. That is the same as 3 bytes of data. If you wanted, for example, to store an entire 1920x1080 screen at 24-bit color, you can calculate it out and see a single screen would take 1920x1080 = 2073600 pixels @ 3 bytes each = 6220800 bytes = ~6.25 MB per screen. To draw an image to a screen, consoles use what is called a buffer to old all the pixels for the screen before sending it to the television. That means, if you wanted to send a single full screen 1920x1080 24-bit image to the screen, you'd need about 6.25 MB of video ram (VRAM) set aside to hold that image.
Old video game machines didn't have this kind of VRAM available. The Sega Genesis, for example, only had 64 KB of total VRAM. Yet it obviously displays full screen images when playing games. To accomplish this, it is necessary to have a method of representing graphics that drastically reduces memory needed to store a full screen image. Thus, old consoles use sprites and planes to draw graphics with, essentially a form of image compression.
Planes represent backgrounds in old video game machines. They are an arrangement of 8x8 tiles like a grid on the screen like this:
The way this works is that there is a small amount of VRAM set aside to hold pixels for tiles, 8x8 at a time. So say your background is made up of 10 unique tiles, that get repeated in a pattern. Instead of holding memory to store every pixel on the screen, you hold memory to store 10 8x8 tiles at 24-bit color (8x8 = 64 pixels x 10 tiles = 640 pixels @ 3 bytes each = 1920 bytes), then store the data which represents those tiles in the plane itself in what is called a planemap. A planemap is an area of memory they works like pixel data does, it's just a series of numeric units of data, but instead of each number representing a shade of red, green, or blue, each number instead represents which specific tile we want to draw at that spot. So, again, using our 1920x1080 example, 2073600 pixels is the same as 32400 8x8 tiles (32400 x (8x8) = 2073600). Since we only are using 10 tiles total, we don't actually need a huge bitdepth to represent a ton of unique combinations of 1's and 0's, so you could do something like using 4 bits per tile to represent our planemap, making an individual byte able to hold two tiles in memory, which means our new footprint to store an entire screens worth of graphicsis now 32400/2 = 16.2 KB for the plane map definition + 1.9 KB for the tile definitions themselves = ~18 KB for an entire screens worth of graphics. Planes and planemaps and tiles are meant to reduce the size of a resultant image.
The downside of using planes and planemaps is that everything has to fit into an 8x8 grid on the screen. Everything HAS to snap to that 8x8 grid, so you can't put pixels on the screen independently. For old systems like the MSX, the inability to easily control the pixel output lead to jerky scrolling, as the background has to move in 8x8 chunks:
Now, obviously aligning everything to an 8x8 grid presents a lot of motion problems in games, so to compromise, old consoles have a second type of graphics object called a sprite. Sprites work like how you describe them, with a sprite you can put individual pixels on the screen in any place. Sprites are small areas of memory set aside, separate from planes and planemaps, that are full resolution images. Say we want a 128x128 pixel sprite that can be drawn anywhere on the screen, not just in 8x8 chunks. We would set aside 128x128 = 16,384 pixels worth of data separate from the plane maps in VRAM to hold this image. The console itself has hardware that can put those pixels anywhere on screen. Thus sprites represent the moving, non-grid-based parts of old video game images that we see.
Now, just like how we split our plane up into tiles definitions to save space, so can you do the same thing with sprites. Instead of each pixel in a sprite storing an R, G, and B value in 3 bytes each, we could make it so each pixel in a sprite stores a numeric reference to a dictionary of color values. Let's say we set aside some memory to hold the definitions for 16 colors. That palette we defined would be 16 colors x 24 bits = 384 bits / 8 bits = 48 bytes to hold a single palette. Then, instead of storing pixels as 3 bytes each in our sprite, we could make the sprite a bunch of numeric references to that palette. As we only need to reference 16 unique colors, we could once again use 4 bits to represent each pixel in the sprite (this is called 4bpp coloring). That makes each byte of the sprite able to hold 2 pixels, were each pixel is actually a number that references which color in the palette that needs to be drawn on screen. Thus, our 128x128 sprite that, at 24 bit color was 49152 bytes big (128x128 @ 3 bytes), becomes 128x128 @ .5 bytes = 8,192 bytes big.
Being able to use palettes to represent sprites (and tiles, actually) like this has a bunch of side-effect benefits for graphics. For example, you can make backgrounds animate just by changing the order of the color inside the palette. If you change a color in the palette, all the sprites and tiles which have pixels that refer to that color in the palette also change. Old games would use this in stuff like Mario Bros or Sonic the Hedgehog to make item blocks glow or waterfalls look like they flow in each respective game.
What we have just described above, using planes and sprites and tiles, is what is colloquially known as "2D graphics hardware." When people talk about a certain machine being "built for 2D" or "having 2D hardware inside," they are referring to the above. The machine has an architecture set up to make sure you use tiles and sprites and planes to reduce memory. The purpose of "2D hardware" is to turn a little amount of RAM, into a very big amount of RAM.
Now, the dreamcast doesn't work like any of this. It doesn't have 2D hardware. It doesn't have sprites, or planes, or tiles, necessarily. The Dreamcast works like modern systems do (to a degree). Arrangements of pixels in VRAM on the dreamcast aren't called tiles or sprites, they are textures. A texture is just an area of VRAM that hold numeric data representing pixels on the screen. When you refer to a "pixel" on a texture, you call it a texel (texture pixel).
The way the dreamcast and modern "3D" hardware works is that there are no planes. Instead, you send numeric data to the graphics core of the machine which represents 3 to 4 points in space (depending on drawing mode). These points in space, when sent to the graphics core, are represented as corners of a shape. If you are drawing with 3 points, those points form together to make a triangle, if you are drawing with 4 points, those points form together to make a square (called a quad).
So, on the dreamcast, if you wanted to draw a background image, you don't need to define a planemap and tiles and send it that way. You instead store some pixel data in VRAM in a texture as Texels, then send some points in space that represents a square that fills the entire screen, then tell the graphics core to fill that square space with pixels that match the texels in your texture. You can always place graphics elements anywhere on the screen on the dreamcast, you are not limited to 8x8 grids. As such, there is no concept of tile, sprites, planes, etc on the dreamcast. This is because, in contrast to the Sega Genesis which had 64 KB of VRAM, the Dreamcast has 8 MB of VRAM, so it can store lots and lots of image data.
8 MB of VRAM is a lot compared to the genesis, but we use a lot more space to store texels on the dreamcast, so the dreamcast has a special piece of hardware inside the graphics core called a vector quantization unit. It is basically hardware compression. It works a lot like how we described palettes or tiles working above. To save the space a texture takes in vram, you can compress it using VQ. What this means is that the Dreamcast, separate from VRAM, has a special set of memory called a dictionary set aside to hold 2x2 pixel defintions. You can split a texture up into small 2x2 "tiles" which are stored in the VQ dictionary, and make each individual texture texel, instead of being a reference to pixel color, be a reference to each VQ dictionary entry. This reduces the size of textures in VRAM the exact same way we described above.
As I explained in an earlier post, the dreamcast can use this VQ hardware in a tricky way to simulate a color palette, like how works on a genesis or saturn. By making each texel in a texture essentially 2x2 pixels big (basically blowing it up), then each VQ dictionary entry becomes a 2x2 pixel solid color, and thus each texture texel references a solid block of color. Thus, you can turn a VQ compressed texture, in to functionally a paletted image. Changing one VQ dictionary entry, like from a 2x2 block of red pixels, to a 2x2 block of blue pixels, will make every texel in the texture that references that VQ dictionary entry, change from red to blue.
But unlike the Genesis or Saturn's tilemaps or planemap definitions, the way you store textures which have been VQ compressed on the dreamcast is strange. You store references to the VQ dictionary out of order in the texture, owing to the way the graphics core circuitry in the dreamcast works. On the genesis or saturn, if you wanted to change the 5th pixel from the top left of the sprite or tile, you would go into memory, count up to the 5th byte (or whatever) and change it there, it follows a logical, easy to follow pattern. The Dreamcast, when using VQ, requires textures to be twizzled. The 5th pixel on screen, might be the 65th pixel in memory, because of a weird ordering pattern twizzled textures must be. Computing the pattern, figuring out what pixels map to which memory locations, is slow for the Dreamcast CPU. Thus, on the Genesis and Saturn, you can actually control your memory directly, and put new pixels into tiles and sprites, to change the actual pixel make up of these paletted images, while on the dreamcast you cannot. The CPU is too slow to figure out which areas of memory to change, to change the pixel make up. You can change the palette easily, but you can't change the order of the texels in the texture.
Now, one huge caveat to all of the above -- the Dreamcast technically has something it refers to as sprites. It's a misnomer, however. The Dreamcast has a special drawing mode to reduce the amount of data it has to send to the graphics core. As mentioned above, you have to send 4 points in space to represent a square image. Those 4 points are 32-bit floating point numbers, meaning you are sending 128 bits of data from your CPU to the graphics core to draw one square image. Sending data from the CPU to the graphics core is slow on the dreamcast, so there is a special "sprite mode" to speed things up. Sprite mode isn't actually sprites, instead it's actually 16-bit floating point numbers. Instead of each point in space being represented by 32-bit numbers, you can enable "sprite mode" on the dreamcast to make each point be represented by 16-bit numbers. This means you can send 4 points in space in only 64-bits of data, which makes sending the data faster. But it has nothing to do with sprites as they are known in video game graphics terms. The downside to using 16-bit floating point numbers vs 32-bit floating point numbers is precision. Just as above, the less bits you have, the less unique numbers you can represent. Floating point numbers represent decimal and fractions of numbers, i.e. "1.5" instead of just "1" or "2." Thus, to hold all the representation of these decimal places, it needs a lot of unique combinations. Going from 32-bit to 16-bit effectively halves the number of unique combinations that number can represent, reducing the number of decimal places it can represent. When you deal with 3D math, you will wind up with a lot of small fractions that describe polygons landing in spots "between" whole numbers, if you can't represent those decimal places, then you get playstation 1 style warbling polygons. The reason this is called "sprite mode" is because, when dealing with 2D images, you don't land "between" whole numbers as much, making that problem not really a big deal.
tl;dr: saturn and genesis have actual 2D hardware, and thus enjoy the benefits that come from that. The Dreamcast does not, but can largely fake it, but due to the way it fakes it, there are benefits of 2D hardware that it cannot replicate.
no, they're not referring to anything, they're using "2D powerhouse" as a meaningless buzzword.
Today's direct color framebuffer "3D" hardware, can do "2D" better than any "2D hardware." Challenge them to describe any possible way their "2D hardware" is actual "2D hardware" or does "2D" any differently than any other modern graphics technology, and they go silent.
Was the Dreamcast version "Arcade Perfect*" back then? I guess if the DC was a 10/10 then a Sega Saturn could prolly do a 7.5/10 in terms of getting everything right.
*Remember when Arcade Perfect was then end all of benchmarks?
*Remember when Arcade Perfect was then end all of benchmarks?
Could you expound on that? I know you have all the details on the differences.
Functional is the right word. It's a technological marvel that it works as well as it does.
In terms of visuals it's close, but the actual game itself is all messed up. They changed frame data, timing, certain combos and setups no longer work.
Thanks. I played ALOT of 3rd Strike in the Arcades and even more on Dreamcast and I did not know this.
An N64 port of Street Fighter III sounds impossible. Are there any sprite based N64 games?
The N64 doesn't have sprites, for the reasons I explained above about the Dreamcast not having sprites. neither does the Playstation. So there is literally no "sprite based" games on any of those systems. They use flat, forward facing polygons and don't need to rely on nametables, planemaps, sprite objects, etc.
That said, there are a number of 2D games on the N64, most infamous being Yoshi's Story.
OP
OP
no, you're confused about the terminology. firstly, To clarify what I'm talking about, you need to know what sprites actually are, how they work, and why they exist. Let's start with basics -- in computer graphics, pixels (colored dots that make up an image) are stored in memory as numeric data. How this data is stored matters. For the most part, in modern graphics technologies, pixels are stored in groups in memory as you describe them - 3 values back to back to back that represents the percentage of red, green, and blue that makes up a single pixel. Storing numeric data in memory back to back to back like that is called a chunky pixel format, because the data is together as a single chunk.
Now, the range this numeric data can represent is determined by how many bits are reserved for each numeral. Bits are the basic unit of computing, they represent the smallest element of data, either a 1 or a 0. Alone, a bit is basically meaningless, but when you group bits together, they can represent numbers. Example - 1011 is a bit string that represents the number 13. More specifically, the string 1111 represents 15 and the string 0000 represents 0, and if you step through every single possible 4-bit string from 0000 to 1111 you will find that there are 16 unique combinations possible. The bitdepth, the number of bits in the string, determines the number of unique combinations you can have.
Representing color as you described earlier, with each pixel in memory being a triplet group of red, green, and blue values takes up a lot of memory. Traditionally today, we operate at 24-bit color where the bits representing each color percentage have a bitdepth of 8, meaning you have 256 values that red, green, and blue can each independently be at. That is the same as 3 bytes of data. If you wanted, for example, to store an entire 1920x1080 screen at 24-bit color, you can calculate it out and see a single screen would take 1920x1080 = 2073600 pixels @ 3 bytes each = 6220800 bytes = ~6.25 MB per screen. To draw an image to a screen, consoles use what is called a buffer to old all the pixels for the screen before sending it to the television. That means, if you wanted to send a single full screen 1920x1080 24-bit image to the screen, you'd need about 6.25 MB of video ram (VRAM) set aside to hold that image.
Old video game machines didn't have this kind of VRAM available. The Sega Genesis, for example, only had 64 KB of total VRAM. Yet it obviously displays full screen images when playing games. To accomplish this, it is necessary to have a method of representing graphics that drastically reduces memory needed to store a full screen image. Thus, old consoles use sprites and planes to draw graphics with, essentially a form of image compression.
Planes represent backgrounds in old video game machines. They are an arrangement of 8x8 tiles like a grid on the screen like this:
The way this works is that there is a small amount of VRAM set aside to hold pixels for tiles, 8x8 at a time. So say your background is made up of 10 unique tiles, that get repeated in a pattern. Instead of holding memory to store every pixel on the screen, you hold memory to store 10 8x8 tiles at 24-bit color (8x8 = 64 pixels x 10 tiles = 640 pixels @ 3 bytes each = 1920 bytes), then store the data which represents those tiles in the plane itself in what is called a planemap. A planemap is an area of memory they works like pixel data does, it's just a series of numeric units of data, but instead of each number representing a shade of red, green, or blue, each number instead represents which specific tile we want to draw at that spot. So, again, using our 1920x1080 example, 2073600 pixels is the same as 32400 8x8 tiles (32400 x (8x8) = 2073600). Since we only are using 10 tiles total, we don't actually need a huge bitdepth to represent a ton of unique combinations of 1's and 0's, so you could do something like using 4 bits per tile to represent our planemap, making an individual byte able to hold two tiles in memory, which means our new footprint to store an entire screens worth of graphicsis now 32400/2 = 16.2 KB for the plane map definition + 1.9 KB for the tile definitions themselves = ~18 KB for an entire screens worth of graphics. Planes and planemaps and tiles are meant to reduce the size of a resultant image.
The downside of using planes and planemaps is that everything has to fit into an 8x8 grid on the screen. Everything HAS to snap to that 8x8 grid, so you can't put pixels on the screen independently. For old systems like the MSX, the inability to easily control the pixel output lead to jerky scrolling, as the background has to move in 8x8 chunks:
Now, obviously aligning everything to an 8x8 grid presents a lot of motion problems in games, so to compromise, old consoles have a second type of graphics object called a sprite. Sprites work like how you describe them, with a sprite you can put individual pixels on the screen in any place. Sprites are small areas of memory set aside, separate from planes and planemaps, that are full resolution images. Say we want a 128x128 pixel sprite that can be drawn anywhere on the screen, not just in 8x8 chunks. We would set aside 128x128 = 16,384 pixels worth of data separate from the plane maps in VRAM to hold this image. The console itself has hardware that can put those pixels anywhere on screen. Thus sprites represent the moving, non-grid-based parts of old video game images that we see.
Now, just like how we split our plane up into tiles definitions to save space, so can you do the same thing with sprites. Instead of each pixel in a sprite storing an R, G, and B value in 3 bytes each, we could make it so each pixel in a sprite stores a numeric reference to a dictionary of color values. Let's say we set aside some memory to hold the definitions for 16 colors. That palette we defined would be 16 colors x 24 bits = 384 bits / 8 bits = 48 bytes to hold a single palette. Then, instead of storing pixels as 3 bytes each in our sprite, we could make the sprite a bunch of numeric references to that palette. As we only need to reference 16 unique colors, we could once again use 4 bits to represent each pixel in the sprite (this is called 4bpp coloring). That makes each byte of the sprite able to hold 2 pixels, were each pixel is actually a number that references which color in the palette that needs to be drawn on screen. Thus, our 128x128 sprite that, at 24 bit color was 49152 bytes big (128x128 @ 3 bytes), becomes 128x128 @ .5 bytes = 8,192 bytes big.
Being able to use palettes to represent sprites (and tiles, actually) like this has a bunch of side-effect benefits for graphics. For example, you can make backgrounds animate just by changing the order of the color inside the palette. If you change a color in the palette, all the sprites and tiles which have pixels that refer to that color in the palette also change. Old games would use this in stuff like Mario Bros or Sonic the Hedgehog to make item blocks glow or waterfalls look like they flow in each respective game.
What we have just described above, using planes and sprites and tiles, is what is colloquially known as "2D graphics hardware." When people talk about a certain machine being "built for 2D" or "having 2D hardware inside," they are referring to the above. The machine has an architecture set up to make sure you use tiles and sprites and planes to reduce memory. The purpose of "2D hardware" is to turn a little amount of RAM, into a very big amount of RAM.
Now, the dreamcast doesn't work like any of this. It doesn't have 2D hardware. It doesn't have sprites, or planes, or tiles, necessarily. The Dreamcast works like modern systems do (to a degree). Arrangements of pixels in VRAM on the dreamcast aren't called tiles or sprites, they are textures. A texture is just an area of VRAM that hold numeric data representing pixels on the screen. When you refer to a "pixel" on a texture, you call it a texel (texture pixel).
The way the dreamcast and modern "3D" hardware works is that there are no planes. Instead, you send numeric data to the graphics core of the machine which represents 3 to 4 points in space (depending on drawing mode). These points in space, when sent to the graphics core, are represented as corners of a shape. If you are drawing with 3 points, those points form together to make a triangle, if you are drawing with 4 points, those points form together to make a square (called a quad).
So, on the dreamcast, if you wanted to draw a background image, you don't need to define a planemap and tiles and send it that way. You instead store some pixel data in VRAM in a texture as Texels, then send some points in space that represents a square that fills the entire screen, then tell the graphics core to fill that square space with pixels that match the texels in your texture. You can always place graphics elements anywhere on the screen on the dreamcast, you are not limited to 8x8 grids. As such, there is no concept of tile, sprites, planes, etc on the dreamcast. This is because, in contrast to the Sega Genesis which had 64 KB of VRAM, the Dreamcast has 8 MB of VRAM, so it can store lots and lots of image data.
8 MB of VRAM is a lot compared to the genesis, but we use a lot more space to store texels on the dreamcast, so the dreamcast has a special piece of hardware inside the graphics core called a vector quantization unit. It is basically hardware compression. It works a lot like how we described palettes or tiles working above. To save the space a texture takes in vram, you can compress it using VQ. What this means is that the Dreamcast, separate from VRAM, has a special set of memory called a dictionary set aside to hold 2x2 pixel defintions. You can split a texture up into small 2x2 "tiles" which are stored in the VQ dictionary, and make each individual texture texel, instead of being a reference to pixel color, be a reference to each VQ dictionary entry. This reduces the size of textures in VRAM the exact same way we described above.
As I explained in an earlier post, the dreamcast can use this VQ hardware in a tricky way to simulate a color palette, like how works on a genesis or saturn. By making each texel in a texture essentially 2x2 pixels big (basically blowing it up), then each VQ dictionary entry becomes a 2x2 pixel solid color, and thus each texture texel references a solid block of color. Thus, you can turn a VQ compressed texture, in to functionally a paletted image. Changing one VQ dictionary entry, like from a 2x2 block of red pixels, to a 2x2 block of blue pixels, will make every texel in the texture that references that VQ dictionary entry, change from red to blue.
But unlike the Genesis or Saturn's tilemaps or planemap definitions, the way you store textures which have been VQ compressed on the dreamcast is strange. You store references to the VQ dictionary out of order in the texture, owing to the way the graphics core circuitry in the dreamcast works. On the genesis or saturn, if you wanted to change the 5th pixel from the top left of the sprite or tile, you would go into memory, count up to the 5th byte (or whatever) and change it there, it follows a logical, easy to follow pattern. The Dreamcast, when using VQ, requires textures to be twizzled. The 5th pixel on screen, might be the 65th pixel in memory, because of a weird ordering pattern twizzled textures must be. Computing the pattern, figuring out what pixels map to which memory locations, is slow for the Dreamcast CPU. Thus, on the Genesis and Saturn, you can actually control your memory directly, and put new pixels into tiles and sprites, to change the actual pixel make up of these paletted images, while on the dreamcast you cannot. The CPU is too slow to figure out which areas of memory to change, to change the pixel make up. You can change the palette easily, but you can't change the order of the texels in the texture.
Now, one huge caveat to all of the above -- the Dreamcast technically has something it refers to as sprites. It's a misnomer, however. The Dreamcast has a special drawing mode to reduce the amount of data it has to send to the graphics core. As mentioned above, you have to send 4 points in space to represent a square image. Those 4 points are 32-bit floating point numbers, meaning you are sending 128 bits of data from your CPU to the graphics core to draw one square image. Sending data from the CPU to the graphics core is slow on the dreamcast, so there is a special "sprite mode" to speed things up. Sprite mode isn't actually sprites, instead it's actually 16-bit floating point numbers. Instead of each point in space being represented by 32-bit numbers, you can enable "sprite mode" on the dreamcast to make each point be represented by 16-bit numbers. This means you can send 4 points in space in only 64-bits of data, which makes sending the data faster. But it has nothing to do with sprites as they are known in video game graphics terms. The downside to using 16-bit floating point numbers vs 32-bit floating point numbers is precision. Just as above, the less bits you have, the less unique numbers you can represent. Floating point numbers represent decimal and fractions of numbers, i.e. "1.5" instead of just "1" or "2." Thus, to hold all the representation of these decimal places, it needs a lot of unique combinations. Going from 32-bit to 16-bit effectively halves the number of unique combinations that number can represent, reducing the number of decimal places it can represent. When you deal with 3D math, you will wind up with a lot of small fractions that describe polygons landing in spots "between" whole numbers, if you can't represent those decimal places, then you get playstation 1 style warbling polygons. The reason this is called "sprite mode" is because, when dealing with 2D images, you don't land "between" whole numbers as much, making that problem not really a big deal.
tl;dr: saturn and genesis have actual 2D hardware, and thus enjoy the benefits that come from that. The Dreamcast does not, but can largely fake it, but due to the way it fakes it, there are benefits of 2D hardware that it cannot replicate.
Wow... Thank you so much. I want you to know that you didn't waste your time. I have a background in CS & actually do C# development for work. These concepts are definitely more advanced than I would typically deal with (managed code is where I like to live), but I was able to follow 95% of what you wrote. I certainly couldn't explain it to someone else this eloquently, but I really appreciate having a deeper understanding of both 2D and 3D graphics.
By the way, do you teach game design? If not, you should consider it!
You know, I would be interested to see if someone can get Third Strike working on the SEGA Saturn's hardware.
I have nothing real to contribute to this thread.
I'm sure a port of SFIII could have made it to the Saturn, but definitely not without compromises.
That said, Crawfish's SFA3 port to the GBA was fucking magic, and my go-to version of the game until it hit PSP.
I've written a book on all of the above.
One other thing to mention regarding the Dreamcast and palettes and VQ: there has very recently, like within the last couple of years, been figured out a way to let the Dreamcast create paletted textures in VRAM from scratch, like the genesis and saturn. I have documented how it works in my book, it's a super obscure way of abusing the Dreamcast's hardware. The only downside is it makes these new generated textures cost 4 times as much ram, effectively reducing your total VRAM to 25%.
That's something awesome for things like emulators which struggle to handle palettes of old consoles, which don't consume a ton of VRAM in the first place.
Last edited:
So what's your verdict? Could the Saturn have had Third Strike as an acceptable version?