When I was working on Return to Dark Castle about 10 years ago, I did some tests with fast-ish Macs from that time. We were drawing the game in 16 bit color in

When I was working on Return to Dark Castle about 10 years ago, I did some tests with fast-ish Macs from that time. We were drawing the game in 16 bit color in RAM as layers of 32x32 pixel tiles and then uploading the resulting PixMap to the GPU as a texture (long story, that was due to starting work on the game in the 90s before OS X even came out). That ran several hundred fps even then. I did some other tests setting each pixel of a 640x480x32 bit buffer in RAM to a random color and then uploading that as a texture, and I believe I got over 1,000 fps on my mid 2011 2.3 GHz i5 Mac Mini with a 1333 MHz DDR3 bus. I feel like it uploaded at 2,000 or 4,000 fps if I didn't change any pixels in RAM, but am not positive. That's with an Intel Graphics 3000, not even a real video card. https://frankdenneman.nl/2015/02/19/memory-deep-dive-memory-subsystem-bandwidth/ https://frankdenneman.nl/2015/02/19/memory-deep-dive-memory-... Ok 1333 MHz DDR3 runs at 10,600 MB/s. A 640x480 32 bit color image takes up 640 * 480 * 4 = 1.17 MB. So the mini should get just over 9,000 fps with perfectly optimized code. I’m not sure if it’s possible to get there through OpenGL though, without direct access to the metal. We just don’t see this kind of speed today in practice because it's really easy to fall off the fast path with renderers like OpenGL and not realize it. So people get used to always thinking in terms of 60 or 120 or 240 fps and don't even realize that memory busses and video cards are orders of magnitude faster than that. Figure roughly a factor of 4 slower for hand-rolled blitter innermost loops, and we're probably looking at rendering Comanche at between 1,000 and 10,000 fps on a typical i7 computer today. All of this is why I was never really fond of the direction that 3D rendering went after video cards arrived around 1997. Shaders are cool and everything (even though they took 10 years to go mainstream), but it's a very specialized discipline and my brain is too old to keep up with it all now. I'd much rather have a multicore CPU with a wide bus (or better yet, multiple narrow busses) and no cache, where the GPU is ordinary RAM, and write blitters by hand. With 100,000 fps we could do some pretty wild stuff with voxels. I've completely given up on all that though, as the world went a different direction. It will keep doubling down on the branch it's on (SIMD with specialized and proprietary shaders running through Unity or Unreal) and completely ignore the rest of the tree of possibilities like ray tracing and ray casting. Which is fine. But this is probably why my heart fell out of game programming, to be completely honest. I did build a gaming PC with an NVIDIA GeForce RTX 2070 video card, but have yet to play around with the ray tracing stuff. In another universe, span buffering (s-buffering) would have been a fast way to render scenes as strips of scan lines. I'm having trouble finding the original article, but maybe these will help: https://www.gamedev.net/articles/programming/graphics/s-buffer-faq-r668/ https://www.gamedev.net/articles/programming/graphics/s-buff... http://www.hugi.scene.org/online/coding/hugi%2016%20-%20co3d13.htm http://www.hugi.scene.org/online/coding/hugi%2016%20-%20co3d... https://mikro.naprvyraz.sk/docs/Coding/2/SBUFF2.TXT https://mikro.naprvyraz.sk/docs/Coding/2/SBUFF2.TXT http://www.cs.uoi.gr/~fudos/sbuffer.pdf http://www.cs.uoi.gr/~fudos/sbuffer.pdf I’m sure there are even better techniques now, but I haven’t followed them.