| ▲ | mrob 7 hours ago | |||||||
>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. | ||||||||
| ||||||||