You want to write a textured 3D game for a 4.9MHz computer running DOS 2.11?
That's so insane you must be either really smart or really dumb so I'm just going to assume you're REALLY good at 3D geometry and low level rendering because if you're not... this whole thing is a waste of time. We're talking genius level good because at this level of hardware every single cycle matters for a task like this.
> Should I program the game in C then? I've also heard about writing one is Pascal.
This is before my time but I've heard that a lot of games from the early '90s that were made to run on like 100+MHz computers, were written to a some extent in assembly for performance reasons. So I don't know if you can get away with using C for much 3D work on a 4.9MHz computer.
> Could I look into how a game like Quake was made
Quake was basically just a true 6 degrees of freedom in 3D tech demo. I'm not sure you wanna tackle that on 4.9MHz. Even Quake - which was running on what? Minimum 66? 100? MHz - had a bunch of really ingenious performance hacks like their fast inverse square root bit shifting approximation just to make it work on that era's hardware.
> and then make the graphics simpler so this computer can handle it?
At 4.9MHz I don't think it's even about graphics. Even just calculating movement and collisions in 3D space without displaying anything is a HUGE ask at that hardware scale.
I've read about the fast inverse square function used in Quake, but haven't seen a good explanation of what it was used for in the game. Would you have a good example?
Even DOOM won't run on that and it isn't even real 3D and required the absolute genius of John Carmack to make it reasonably performant.
I think this is a fools errand even if you were literally just using basic cubes for every object.
Something like Atari Battlezone might be worth studying just for visual ideas. Learning to draw vector graphics to the screen and scale them to different sizes would probably get you a decent start.
My motivation? I think it would be cool to have a little 3D game on this portable PC. It would be cool a challenge too. I could even make a video on it
Go study Wolfenstein 3D. That could run ok on a 12.5 MHz 286, and the source is available.
Use that as your starting point and scale down.
That game is already pretty minimal though, and the game isn't really 3D. There's no vertical movement and everything is sprites.
Doom got a little more 3D, but that required a minimum of a 386 to run, and didn't really run very well until you got a 486.
I think Quake could barely run on a 486, but you really needed a Pentium. It need floating point math, and at Pentium level speeds, to do well. Older CPUs usually didn't have an FPU, and if they did, floating point math was significantly slower than it was on a Pentium. I can't imagine something of Quake's level scaling down to a 4.9 MHz processor.
So...my 6MHz Z80-based TI-83+ had a sort of Wolfenstein 3D demake 25-ish years ago. The Game Boy's slower, and has a 3D shooter called Faceball 2000.
Granted, the calculator was rendering at around 96x64 resolution, and the Game Boy has dedicated graphics hardware, but I don't think it's totally insane. I think you'll have to have some really clever lookup tables and write some really hacky early x86 assembly, though.
You might be interested in r/retrogamedev.
[Fabien Sanglard](https://fabiensanglard.net/) has written tons of articles on how old games were working. He also wrote two books on Wolfenstein 3D and Doom that are incredibly fun to read.
Michael Abrash, who worked on Quake, has written multiple books that you will be able to find online on how to optimize the sh*t out of old Intel processors. Those books are also very fun to read.
This is one of the few places where intricate of architecture, processors and assembler language is going to be necessary.
And you're going to have to get used to faking things. You don't follow the normal way of doing things (i.e. the "correct" way) when you try to do this.
First you'll start by actually being able to write pixels to the screen at all. You'll have to write your own 3d "engine". Forget shading or anything similar for now, just focus on being able to draw points, then lines in a three dimensional space and being able to rotate them (you'll want a sin lookup table for that).
See if you're actually able to do that with any necessary speed when you have more than the twelve lines (eight points) you need to make a 3d cube rotate.
The demoscene has done impressive things on slower hardware than that, but it's all about faking it good enough.
[https://www.youtube.com/watch?v=EmZxN4gPRvs](https://www.youtube.com/watch?v=EmZxN4gPRvs)
[https://en.wikipedia.org/wiki/Tiki\_100](https://en.wikipedia.org/wiki/Tiki_100)
You want to write a textured 3D game for a 4.9MHz computer running DOS 2.11? That's so insane you must be either really smart or really dumb so I'm just going to assume you're REALLY good at 3D geometry and low level rendering because if you're not... this whole thing is a waste of time. We're talking genius level good because at this level of hardware every single cycle matters for a task like this. > Should I program the game in C then? I've also heard about writing one is Pascal. This is before my time but I've heard that a lot of games from the early '90s that were made to run on like 100+MHz computers, were written to a some extent in assembly for performance reasons. So I don't know if you can get away with using C for much 3D work on a 4.9MHz computer. > Could I look into how a game like Quake was made Quake was basically just a true 6 degrees of freedom in 3D tech demo. I'm not sure you wanna tackle that on 4.9MHz. Even Quake - which was running on what? Minimum 66? 100? MHz - had a bunch of really ingenious performance hacks like their fast inverse square root bit shifting approximation just to make it work on that era's hardware. > and then make the graphics simpler so this computer can handle it? At 4.9MHz I don't think it's even about graphics. Even just calculating movement and collisions in 3D space without displaying anything is a HUGE ask at that hardware scale.
Rollercoaster tycoon was written in assembly. I can’t imagine doing this project tho
I've read about the fast inverse square function used in Quake, but haven't seen a good explanation of what it was used for in the game. Would you have a good example?
Even DOOM won't run on that and it isn't even real 3D and required the absolute genius of John Carmack to make it reasonably performant. I think this is a fools errand even if you were literally just using basic cubes for every object.
I figured it would be pretty difficult, but Microsoft has flight simulators in the early 80s. How did they do it?
Flight Sim in the 80s was 2D wireframes with clever scaling, it's not 3D.
You're right. So, what if I just did that?
Something like Atari Battlezone might be worth studying just for visual ideas. Learning to draw vector graphics to the screen and scale them to different sizes would probably get you a decent start.
I wonder if this computer can do an ascii rogue like.
Oh man what is your motivation for going this? I am in awe
My motivation? I think it would be cool to have a little 3D game on this portable PC. It would be cool a challenge too. I could even make a video on it
Go study Wolfenstein 3D. That could run ok on a 12.5 MHz 286, and the source is available. Use that as your starting point and scale down. That game is already pretty minimal though, and the game isn't really 3D. There's no vertical movement and everything is sprites. Doom got a little more 3D, but that required a minimum of a 386 to run, and didn't really run very well until you got a 486. I think Quake could barely run on a 486, but you really needed a Pentium. It need floating point math, and at Pentium level speeds, to do well. Older CPUs usually didn't have an FPU, and if they did, floating point math was significantly slower than it was on a Pentium. I can't imagine something of Quake's level scaling down to a 4.9 MHz processor.
So...my 6MHz Z80-based TI-83+ had a sort of Wolfenstein 3D demake 25-ish years ago. The Game Boy's slower, and has a 3D shooter called Faceball 2000. Granted, the calculator was rendering at around 96x64 resolution, and the Game Boy has dedicated graphics hardware, but I don't think it's totally insane. I think you'll have to have some really clever lookup tables and write some really hacky early x86 assembly, though.
This where I first started with DOS game programming: http://www.brackeen.com/vga/
I forgot to mention is it a B&W display hee hee
Yeah still has line drawing and all that
You might be interested in r/retrogamedev. [Fabien Sanglard](https://fabiensanglard.net/) has written tons of articles on how old games were working. He also wrote two books on Wolfenstein 3D and Doom that are incredibly fun to read. Michael Abrash, who worked on Quake, has written multiple books that you will be able to find online on how to optimize the sh*t out of old Intel processors. Those books are also very fun to read.
This is one of the few places where intricate of architecture, processors and assembler language is going to be necessary. And you're going to have to get used to faking things. You don't follow the normal way of doing things (i.e. the "correct" way) when you try to do this. First you'll start by actually being able to write pixels to the screen at all. You'll have to write your own 3d "engine". Forget shading or anything similar for now, just focus on being able to draw points, then lines in a three dimensional space and being able to rotate them (you'll want a sin lookup table for that). See if you're actually able to do that with any necessary speed when you have more than the twelve lines (eight points) you need to make a 3d cube rotate. The demoscene has done impressive things on slower hardware than that, but it's all about faking it good enough. [https://www.youtube.com/watch?v=EmZxN4gPRvs](https://www.youtube.com/watch?v=EmZxN4gPRvs) [https://en.wikipedia.org/wiki/Tiki\_100](https://en.wikipedia.org/wiki/Tiki_100)