Espozo wrote:
Isn't the way that the Sega CD does sprite scaling no different than the Super FX 2 with Yoshi's Island in that it still uses bandwidth to update vram? I mean like you couldn't necessarily do full screen background rotation at 60fps, right?
Yeah, and those ports of scaler games I mentioned run at 15FPS if I recall correctly, which is the framerate you'd get from trying to update like that... I wonder if the low framerate in those games is intentional. (it should still be able to blit more than the SuperFX since it's entirely done in hardware, however) The upside is that you can do
a lot more with it than with SNES' mode 7, which is not a minor thing either (see Battlecorps, Adventures of Batman & Robin, Soulstar...).
I have no idea if it'd have been like that originally, but given the kind of VRAM they used, it probably was like that and rendered to the 68000's RAM (if Sega had tried to implement the equivalent of mode 7 on the VDP itself, it'd have had a granurality of only 4 pixels per step... without sprites or anything else).
Espozo wrote:
Maybe I'm crazy, but didn't someone say that interlaced mode on the Genesis took a lot of room in the VDP?
Absolutely no idea, I don't think it was mentioned by Sega and we haven't decapped the VDP yet. It
does double the amount of memory each tile takes up in VRAM, but that's a different issue.
Espozo wrote:
I would have much rather substituted that for pretty much anything, especially a larger onscreen palette. More palette colors doesn't necessarily relate to a faster graphics processor, does it, unlike overdraw and the number of BGs?
Just memory. But yeah, they ran out of space in the die for that.
Also do note that they'd have probably wanted to go with a power of two. Maybe there was room for more than 64 colors, but not enough to reach 128 (SRAM can be quite big!), and they decided to reuse whatever space was left for something else.
Espozo wrote:
Heck, why not just make palette ram external to the chip like vram like the Neo Geo, which I'm pretty sure does?
The VDP
does have this capability (and allows you to show more colors in fact since you have layer information as well, up to 384 colors I think), the problem is that using external RAM would have increased the cost of the console. It
is used in arcades, though (Thunder Force AC uses it).
Espozo wrote:
Actually, now that I'm getting in to this, How does a picture from a 2D system actually get to the screen completed? Is there a frame buffer like 3D systems, where all the layers get drawn over each other, and that final image goes to the screen? Sorry if I sound stupid, just after learning about 3D graphics, it has gotten me curious.
It fetches the graphics data it wants from each of the layers (i.e. each tilemap layer and the sprite layer), then uses the priority information to determine which one to show, then takes the resulting pixel and passes it through the palette to get the final color to show.
As for sprites, older systems with a small limit (like the NES) just fetch them directly during hblank and combine them. Newer systems have a linebuffer (i.e. a framebuffer with just a row) where they render the sprites for the next line (the graphics for the sprites for the next line are fetched alongside the graphics for the tilemaps of the current line - this is why rendering has to start on line -1, not line 0).