[drewying]

I agree with you in general, but I think it's worth pointing out that programming the NES's PPU is actually very similar to programming with a 2D graphics library today.

NES games never wrote their own scrolling logic, or there own graphics logic. They wrote tile values into a background table and then told the NES how much to scroll the playing field, and the NES rendered and scrolled everything automagically.

NES games never drew their own sprites. They just said "Hey NES, write the sprite at this x and y location" and the NES did it.

Audio worked the same way.

Honestly, coding for the NES would be similar to working with a simple 2D graphics library. So I don't know if it would be accurate to say "every line of code is yours" on the NES. It's more just that the "libraries" used were implemented in hardware instead of software.

[marshray]

> NES games never drew their own sprites. They just said "Hey NES, write the sprite at this x and y location"

Yeah, but the hardware is so limited with weird corner cases that writing a bitblt might be easier. For example, some games have to reconfigure their sprites at the beginning of every horizontal scan line to overcome the hardware limitation on simultaneously displayed sprites (8).

[klodolph]

Which games? To my knowledge this is at best exceptionally rare because there are only ~114 CPU cycles in a scan line. The reports I've heard are that if you do any OAM changes mid-frame, you get something like four lines of glitches. More common is to just do a full OAM DMA during vertical blank, at least from the ROMs I've seen.

[marshray]

I can't find the original link where I read about this, it may have been more theory than about specific games. These links seem to be relevant: http://wiki.nesdev.com/w/index.php/Sprite_overflow_games http://forums.nesdev.com/viewtopic.php?t=16299

[annywhey]

This is only sort of true in that while there are hardware supported things, the way in which you work with them is both more finicky than most APIs, and they get you relatively less close to a finished renderer.

For example, concepts like a scroll register don't typically appear in an abstracted API. They're a hardware detail that happens to assist in implementing a smooth scroll by reducing the necessary computation. But they aren't a "smooth scrolling API" because it works on the tilemap data only - you can also have sprites scroll. That necessitates a software implementation specifically for the task of sprite rendering. Witness the numerous NES games that either let sprites disappear when they hit negative X coordinates or put up a convenient black bar to hide it.