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 7 hours ago | parent | next [-]

>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 6 hours ago | parent [-]

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 5 hours ago \| parent [-]
		>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.

▲

matheusmoreira 4 hours ago | parent | prev | next [-]

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

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

▲

rtpg 3 hours ago | parent | prev [-]

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