Sure, but did that "2D" orientation boil down to anything beyond accelerated blitting and perhaps a few geometry-rendering primitives? Part of the problem is also that there never was a standard feature set and API for 2D acceleration comparable to OpenGL or Vulkan. So support for it was highly hardware-dependent and liable to general bit rot.

Yes, there were other hardware acceleration tricks implemented. For example, hardware sprites allowed for bitmaps that were composed in real time for display rather than blitted to the framebuffer. This trick is still used for the mouse cursor. There was hardware scrolling which meant you could move the whole display and only render the edge that came into view. Both of these together is how platformer games were implemented on the SNES and similar hardware of that generation, and it’s why the gameplay was so smooth. The NES could either do hardware sprites or hardware scrolling, but not both IIRC, which is why the game world freezes when Link reaches the edge of the screen and the new screen comes into view in the original Zelda.

There were other hardware accelerations my memory is somewhat more vague on. I remember there were some color palate translation hardware, and hardware dithering.

There wasn’t any standard cross platform graphics api back then, but that’s more a statement about the era. Everyone wrote directly to the metal.

> For example, hardware sprites allowed for bitmaps that were composed in real time for display rather than blitted to the framebuffer.

You can do all these things with compositing, though. A "sprite" is just a very limited hardware surface where compositing happens at scanout, and some modern GPU's have those too.

VESA had one but it never took off.

https://web.archive.org/web/20081209121702/http://www.vesa.o...