I've always wondered how it would've been like if there was a video game system that was about half-way between the 4th and 5th generation, that had the same graphical capabilities of the GBA, but at a 320x240p or similar resolution. How fast would the PPU VRAM bus have to be, in order to preform hardware rotation and scaling on individual sprites?

First of all, what 32-bit processor are you considering for this?

It sounds interesting. I think the trick is to keep the resolution low - maybe 256 pixels across, for easy addressing of the background. And lots of sprites.

With a 32-bit system you can pre-rotate bitmaps for sprites as you'll have plenty of RAM.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Define for us "4th or 5th generation" please.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The bandwidth depends on how many sprites you wish to have onscreen at once. If you're doing all the rendering inline with refreshing the display, that will be a pretty immediate constraint; if there are more elements than there are hardware paths for any particular scanline, then it will fail to render them.

If you're working like a modern 3d card and blitting all of your 2d assets to a framebuffer for display, then you will need enough bandwidth to cover all the overdraw you will be doing as well as output those pixels to the display. If you try to render too many, the framerate will drop but still show everything. I think many of the arcade hardware systems for those insane bullet hell shooters worked like this, instead of using hardware sprites for each individual element.

Some hybrid methods could have hardware parallax playfields overlaying each other, on some of which you blit a bunch of sprite instances. Then there's having the hardware breaking your bitmaps down into horizontal spans, doing occlusion tests on those spans, and then rendering the result during screen update (similar to s-buffering). I don't know if this has ever been used in commercial hardware, though.


ElEctric_EyE:
https://en.wikipedia.org/wiki/4th_generation_of_video_games
https://en.wikipedia.org/wiki/History_of_video_game_consoles_(fifth_generation)

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

That's interesting.
Sometimes technology advances too quickly and the concepts that got us there are lost or even not needed anymore, for a certain product.

The project I currently work on uses a concept similar to what is described in the wiki for video overlay. A 2D system (possibly 3D) with 5 pass-thru boards and 1 output board. It was meant to be an experiment in parallel computing using multiple cpu cores, but it is turning into more of a graphics accelerator controlled by 1 cpu.
So far 2 boards are working. The concept is solid.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Here are my thoughts of how the PPU would work.

The PPU will be clocked at 27 Mhz, and each scanline will be exactly 1716 cycles long. Each pixel is 4 cycles longs, with 320 active pixels across. VRAM will be accessed through an 8-bit bus, at 27 Mhz.

Cycles 0-1311 (328 pixels) will be spent fetching the bg layers, with either 4 bg layers, 2 rotate/scale layers, or 2 bg layers and 1 rotate/scale layer. Cycles 1312-1711 will be spent either fetching 800 pixels worth of sprites, or 400 pixels of rotate/scale sprites. Cycles 1712-1715 will be unused.

Why not faster, and make more layers/sprites ?

What about the Playstation or Sega Saturn ? Many games doesn't touch their 3D capabilities.

I'd have a hard time calling a PlayStation a 2D game system, but the Saturn, AIUI, was actually designed to be a 2D game system and the horribly anemic 3D capabilities were grafted on in a hurry once they got a look at their competition.

You could also make the case that the Genesis was a 32-bit game system, as the 68000 has 32-bit wide registers and so on, even if it only has a 24-bit address space and a 16-bit data bus. Or maybe the SegaCD, going by the logic that two 16-bit CPUs in parallel makes one 32-bit system, I seem to recall hearing some "logic" along those lines in terms of video game system marketing... Then again, if you're going in that direction, there's the "SuperGrafx" version of the TurboGrafx-16/PC-Engine. Doubled up on the video hardware to get extra playfields, but kept the same CPU, which then had trouble keeping up with the two video chips.

Anyway, plenty of directions to look in terms of existing hardware, the more interesting question is developing NEW hardware and software for a 2D game system.

Technically speaking, neither the Playstation nor Sega Saturn have true 3D rendering capabilities.

The Playstation 1 renders triangles, but these are 2D triangles - the vertices have no Z value.
The Sega Saturn VDP1 renders quads, but these are 2D as well - there is no Z value.



The Sega Saturn has no hardware ability to render proper 3D graphics, period.
All the 3D graphics were done using stretched 2D quads except for the VDP2 background effects.
I had both the VDP1 and VDP2 manual, so I'm familiar with how they work, although that was 15 years ago.

Toshi