5 ms·

Great article. I wonder at the speed of this on a modern machine vs an assembly version running in dos on a 1992 machine. A benchmark of interpreted code on

Great article. I wonder at the speed of this on a modern machine vs an assembly version running in dos on a 1992 machine. A benchmark of interpreted code on a modern OS + machine vs bare metal native code written in the 1992 style on an old machine would be interesting. I remember when Comanche came out... the 1990s were like the Heyday of flight sim games and Comanche was mind-blowing at the time as a teen. They were my favorite by far type of game. At some point it feels like they really died out. There were a lot of games that had a happy medium of fun vs realistic/complex back then. At some point the # of flight sim type games plummeted and the ones that stuck around bifurcated into hyper-realistic to the point they are a time suck (cause you could be using an actual real flight sim for real flight training) or they are hopelessly unrealistic and no fun compared to the old stuff. Not sure but I might disagree with the author about Comanche being 3 years ahead of it's time. It might have been closer to 5 years ahead of it's time. You didn't get stuff that really blew it away till hardware acceleration became prevalent, but by that time 3D FPS games were demolishing the flight sim market.

pjmlp 7y ago
I imagine it would be very sad, when you then realise how many wasted cycles our CPUs are doing versus those days.
- gibolt 7y ago
  Those cycles enable much higher level operations. Still tons of wasted effort, but hopefully development time for the same complexity is significantly reduced.
  - pjmlp 7y ago
    Yeah like Electron based apps, sigh.
    - soylentgraham 7y ago
      I think you just proved the point. If we didn't have this high level, easy-to-produce abstraction... you wouldn't have even heard of slack and electron. Yet it enabled people to create something a lot of people use :)
      - tambourine_man 7y ago
        There were many (and much better IMO) instant message multiplatform apps before Electron. The problem isn’t JavaScript, which these days is remarkably fast. It’s that every app loads almost an entire OS in order to run. Process isolation, layout engine, text rendering, 2D/3D graphics, audio…
      - pjmlp 7y ago
        There are plenty of Electron alternatives, without the bloat of carrying a browser around. Those people would also be enabled if they bothered to get out of the Web comfort zone and actually learn about them.
  - philipov 7y ago
    optimizing the high level operations would be a sweet application for machine learning, don't you think?
- Iv 7y ago
  GPU cycles are what is precious now. The idea that we basically run a whole program on each pixel, on 4K displays, at 60fps nowadays is just mindboggling.
  - pjmlp 7y ago
    While it is mindboggling, it is basically the PC catching up to ideas put in practice on the Amiga blitter, NeXTSTEP Renderman, PS3 Cell.
perl4ever 7y ago
The Comanche terrain as depicted (I never played the game) reminds me very much of VistaPro, which (as I look it up) came out in 1991. But that wasn't interactive...
- Iv 7y ago
  And took minutes to render one frame. It was triangle based though and more beautiful. I don't think they had a voxel engine built in.
  - HereBeBeasties 7y ago
    They didn't. It was light-path based, so similar to ray tracing. It'd also do trees, mist, etc. Check out https://m.youtube.com/watch?v=48KtJtDqkaM https://m.youtube.com/watch?v=48KtJtDqkaM for a 4K Vista Pro animation render!
facorreia 7y ago
In those days games came with hefty manuals. I particularly remember learning the rudiments of flying a helicopter from Gunship's manual. You can see for yourself on this PDF, starting on page 38: http://www.simwarrior.com/gunship/utilities/GSManUK.pdf http://www.simwarrior.com/gunship/utilities/GSManUK.pdf Edit: this is Comanche's manual: http://www.starehry.eu/download/simulation/docs/Comanche-Manual.pdf http://www.starehry.eu/download/simulation/docs/Comanche-Man...
- dundercoder 7y ago
  That gunship read was fascinating!
- HereBeBeasties 7y ago
  Didn't they just? Microprose and Digital Integration in particular were the masters back then for this stuff - I remember the Project Stealth Fighter (C64, ZX Spectrum in around 1987) and then the Tornado (PC) manuals with particular fondness, covering laser guided toss bombing and all sorts of stuff. I'm amazed to discover that Tornado has gone open source and is still being modded by people: http://www.moodurian.com/ http://www.moodurian.com/ https://archive.org/details/Project_Stealth_Fighter_1987_Microprose_Software/page/n5 https://archive.org/details/Project_Stealth_Fighter_1987_Mic... for another blast from the past.
Iv 7y ago
At that time I was in high school, trying to figure out with some friends how to render things in my Turbo Pascal program. At the time we did not have internet, so we were left to figure out how these techniques worked. We knew how to project things in 3D and rotation worked well, but rendering more than a few points would bring the CPU to a halt. At one point we read about texturing, but there again, how could the huge levels of Wolfenstein 3d be rendered on modest CPUs? Surely it was not drawing all the sorted triangles over each other each frame? There was not enough resources for that! Then one of us had internet access, printed two pages that explained raycasting. "Ohhhhh! That's how! rendering per column!" And yes, Comanche was very highly regarded by people interested in 3D rendering. It was said to be coded entirely in assembly (was it true?) which to me at the time felt really impressive.
rurounijones 7y ago
> At some point the # of flight sim type games plummeted and the ones that stuck around bifurcated into hyper-realistic to the point they are a time suck (cause you could be using an actual real flight sim for real flight training) or they are hopelessly unrealistic and no fun compared to the old stuff. The following info might be of interest: The company behind Digital Combat Simulator (DCS World), which is the hardest of hard core military flight Sims, recently announced Modern Air Combat (MAC) which I believe is aiming for the level of fun vs realism you mentioned. "Over the past year, a massive amount of work has gone into Modern Air Combat in order to make it a AAA title. During this period, we have also expanded the scope and features of the product substantially. This has led to us push back its release date to 2020. Modern Air Combat will not be a DCS World product, but rather a new series for us that focuses more on action, gameplay, and a shallowing learning curve." https://www.digitalcombatsimulator.com/en/newsletters/newsletter03012020-851b43a35367471cdaea724efa55d2a4.html https://www.digitalcombatsimulator.com/en/newsletters/newsle...
zackmorris 7y ago
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.

pjmlp 7y ago

I imagine it would be very sad, when you then realise how many wasted cycles our CPUs are doing versus those days.

gibolt 7y ago
Those cycles enable much higher level operations. Still tons of wasted effort, but hopefully development time for the same complexity is significantly reduced.
- pjmlp 7y ago
  Yeah like Electron based apps, sigh.
  - soylentgraham 7y ago
    I think you just proved the point. If we didn't have this high level, easy-to-produce abstraction... you wouldn't have even heard of slack and electron. Yet it enabled people to create something a lot of people use :)
    - tambourine_man 7y ago
      There were many (and much better IMO) instant message multiplatform apps before Electron. The problem isn’t JavaScript, which these days is remarkably fast. It’s that every app loads almost an entire OS in order to run. Process isolation, layout engine, text rendering, 2D/3D graphics, audio…
    - pjmlp 7y ago
      There are plenty of Electron alternatives, without the bloat of carrying a browser around. Those people would also be enabled if they bothered to get out of the Web comfort zone and actually learn about them.
- philipov 7y ago
  optimizing the high level operations would be a sweet application for machine learning, don't you think?
Iv 7y ago
GPU cycles are what is precious now. The idea that we basically run a whole program on each pixel, on 4K displays, at 60fps nowadays is just mindboggling.
- pjmlp 7y ago
  While it is mindboggling, it is basically the PC catching up to ideas put in practice on the Amiga blitter, NeXTSTEP Renderman, PS3 Cell.

perl4ever 7y ago

The Comanche terrain as depicted (I never played the game) reminds me very much of VistaPro, which (as I look it up) came out in 1991. But that wasn't interactive...

Iv 7y ago
And took minutes to render one frame. It was triangle based though and more beautiful. I don't think they had a voxel engine built in.
- HereBeBeasties 7y ago
  They didn't. It was light-path based, so similar to ray tracing. It'd also do trees, mist, etc. Check out https://m.youtube.com/watch?v=48KtJtDqkaM https://m.youtube.com/watch?v=48KtJtDqkaM for a 4K Vista Pro animation render!

facorreia 7y ago

In those days games came with hefty manuals. I particularly remember learning the rudiments of flying a helicopter from Gunship's manual. You can see for yourself on this PDF, starting on page 38: http://www.simwarrior.com/gunship/utilities/GSManUK.pdf http://www.simwarrior.com/gunship/utilities/GSManUK.pdf Edit: this is Comanche's manual: http://www.starehry.eu/download/simulation/docs/Comanche-Manual.pdf http://www.starehry.eu/download/simulation/docs/Comanche-Man...

dundercoder 7y ago
That gunship read was fascinating!
HereBeBeasties 7y ago
Didn't they just? Microprose and Digital Integration in particular were the masters back then for this stuff - I remember the Project Stealth Fighter (C64, ZX Spectrum in around 1987) and then the Tornado (PC) manuals with particular fondness, covering laser guided toss bombing and all sorts of stuff. I'm amazed to discover that Tornado has gone open source and is still being modded by people: http://www.moodurian.com/ http://www.moodurian.com/ https://archive.org/details/Project_Stealth_Fighter_1987_Microprose_Software/page/n5 https://archive.org/details/Project_Stealth_Fighter_1987_Mic... for another blast from the past.

Iv 7y ago

At that time I was in high school, trying to figure out with some friends how to render things in my Turbo Pascal program. At the time we did not have internet, so we were left to figure out how these techniques worked. We knew how to project things in 3D and rotation worked well, but rendering more than a few points would bring the CPU to a halt. At one point we read about texturing, but there again, how could the huge levels of Wolfenstein 3d be rendered on modest CPUs? Surely it was not drawing all the sorted triangles over each other each frame? There was not enough resources for that! Then one of us had internet access, printed two pages that explained raycasting. "Ohhhhh! That's how! rendering per column!" And yes, Comanche was very highly regarded by people interested in 3D rendering. It was said to be coded entirely in assembly (was it true?) which to me at the time felt really impressive.

rurounijones 7y ago

> At some point the # of flight sim type games plummeted and the ones that stuck around bifurcated into hyper-realistic to the point they are a time suck (cause you could be using an actual real flight sim for real flight training) or they are hopelessly unrealistic and no fun compared to the old stuff. The following info might be of interest: The company behind Digital Combat Simulator (DCS World), which is the hardest of hard core military flight Sims, recently announced Modern Air Combat (MAC) which I believe is aiming for the level of fun vs realism you mentioned. "Over the past year, a massive amount of work has gone into Modern Air Combat in order to make it a AAA title. During this period, we have also expanded the scope and features of the product substantially. This has led to us push back its release date to 2020. Modern Air Combat will not be a DCS World product, but rather a new series for us that focuses more on action, gameplay, and a shallowing learning curve." https://www.digitalcombatsimulator.com/en/newsletters/newsletter03012020-851b43a35367471cdaea724efa55d2a4.html https://www.digitalcombatsimulator.com/en/newsletters/newsle...

zackmorris 7y ago

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.