[LarsDu88]

Lovely book. Skimming through it. One thing that might help contextualize it is a brief discussion of the how contemporary hardware like the SNES rendered sprites so efficiently compared to the PC hardware at the time. It's not obvious to modern readers why a PC with significantly more powerful compute capabilities would struggle to keep up with significantly slower Nintendo hardware at the time for sprite rendering.

[mrob]

>It's not obvious to modern readers why a PC with significantly more powerful compute capabilities would struggle to keep up with significantly slower Nintendo hardware at the time for sprite rendering.

To put it briefly, 4th generation and earlier games consoles saved on expensive RAM by not having frame buffers [0]. The CPU wrote a description of how to construct the scene using tiles and sprites to a smaller video ram, then dedicated video hardware converted this to the video signal one line at a time. The whole frame gets rendered from scratch every video refresh, so there's no need for tricks like Commander Keen's adaptive tile refresh. Scrolling at 60 fps (or 50 fps for PAL hardware) is as cheap as changing a single value in video memory. It's like the famous "racing the beam" of the Atari 2600, except less flexible and done by dedicated hardware so you don't tie up the CPU.

On the PC, the CPU writes the actual graphics to a frame buffer, then the graphics card outputs the contents of the frame buffer as the video signal. The naive approach to scrolling requires rewriting the entire frame buffer, so tricks to avoid redundant writes are highly beneficial.

[0] Except for the Atari Lynx, which was a portable system with a screen resolution of only 160×102. I can't think of any other exceptions, but maybe there are more.

[wk_end]

I get what you're saying, but the comparison to "racing the beam" is maybe a little misleading, because the point is that you aren't "racing" the beam. Rather, the system is operating in perfect lockstep with the beam. From the software perspective, you set the scene up and then sit back while it draws. And then in the abstract and from the hardware's perspective it's not even one line at a time, it's one dot at a time.

[mrob]

>Rather, the system is operating in perfect lockstep with the beam.

That's the same as the Atari 2600. It just occurred to me that the name "racing the beam" is misleading because you can't be too fast either. "Matching the beam" would be a better name. My point is the graphics hardware in both the 2600 and in tile+sprite consoles assembles the graphics just before it's sent to the video output without buffering the whole frame. The main difference is the 2600 graphics hardware is typically reconfigured every line while the later consoles' graphics hardware is typically reconfigured every frame (although re-configuring between lines is usually also possible, and some games left it unchanged on some screen refreshes to save CPU time at the expense of lowering frame rate).

>from the hardware's perspective it's not even one line at a time, it's one dot at a time.

Mostly true, but I tried to make the description generic to as many systems as possible, so "line" is IMO more broadly accurate because a line is composed of dots. The Neo Geo is a tile + sprite system too, and it renders to line buffers.

[fredoralive]

It's basically a case of hardware acceleration. Most games consoles and fancier micros have some of dedicated graphics chip that handles the heavy lifting of generating graphics. So for basic game graphics the CPU largely acts as a manager adjusting things like tilemaps and their viewport offsets, and sprite locations (possibly updating things several times mid frame, for fancier effects). The exact setup differs between systems, tilemaps and spites like the SNES is common, though you also have setups with some sort of framebuffer and a Blitter to speed up drawing to it instead.

A traditional IBM PC has a "dumb" framebuffer, where everything is done by the PC. Simply scrolling the background by 1 pixel basically means redrawing a lot of the screen, and you have to keep track of what graphics behind sprite would need to be redrawn after they move etc. As a bonus, on early consumer level 386 and 486 machines you have a mighty processor, but the graphics card is often still on a 16 bit 8MHz(ish) ISA bus. The PC does have an advantage that it's more flexible, so stuff like 3D was easier to do than on a tile-and-sprite setup (especially once we had stuff like VESA and PCI).

[matheusmoreira]

These videos do an excellent job at explaining how the SNES works:

https://www.youtube.com/playlist?list=PLHQ0utQyFw5KCcj1ljIhE...

[rtpg]

the Gameboy, not the SNES, but this talk is very very good at going in detail about a bunch of internals. The graphics stuff is 29 minutes in but I love the whole video. Very much a high level guide to building a "retro-y" fantasy console for people into that stuff

https://youtu.be/HyzD8pNlpwI?t=1759