I wrote a Raytracer for DOS, 16 VGA colors (2011) [video]
youtube.com
youtube.com
Reminds me of the time I was writing ESP/ESC software for car ECUs back in the days before Simulink models and automatic code generation where we had the vehicle dynamics books with all the physics of the car, and had to convert the math functions from continuous to discrete, then implement them in fixed point C, along with trigonometric functions (the CPU had no HW SIN/COS), optimized enough to run 100 times/second on a 16bit chip while keeping CPU load under 85%.
Test drivers were in awe and thought it's voodoo. No, it's just basic math implemented in C, similar to what Carmack was doing for the Doom/Quake 3D engines ;)
Because in the old days you had little memory to work with, 32kb for PROGRAM(Flash) and 2kb for DATA(RAM), so you'd store a few points in your table and use a linear interpolation function for the rest. Now, because silicon is cheap, even the chip controlling your headlights has 1MB of PROGRAM memory or more and could run DOOM but instead of fancy algos it's used to store all AutoSar libraries it needs for networking and certification.
I particularly love his older stuff, where the tech choices were just plain _weird_ because that's all he had lying around and needed to make stuff work.
For anyone curious how the mario animation is rendered in the editor: https://github.com/bisqwit/that_editor/blob/master/mario.cc
Not sure what it's doing there.
Seems that this Bisqwit also has a touch of the divine intellect. We must do a better job of protecting him!
http://1.bp.blogspot.com/_fmfAOCgGNJU/SQuCxkXJiRI/AAAAAAAAGE...
Do you remember what kind of speed ups that thing gave you? I wonder if you could play to backport some modern AI algorithms to it and run them at reasonable speeds -- however being a 286 I imagine it'd be quite a challenge.
[0] https://books.google.com/books?id=RD0EAAAAMBAJ&pg=PA89&lpg=P...
Realtime raytracing didn’t exist until recently but people have been dabbling with doing it at much slower speeds, and sequencing the resulting frames, for a long time.
[0]: http://www.realtimerendering.com/resources/RTNews/demos/over...
What I _don't_ like is his coding style. If he's writing C++, let him use modern C++...
* He should use C++ standard library header names, not C library headers.
* He should use std::array's rather than plain arrays.
* He asks whether there's a way to define arithmetic ops that's simpler/shorter than using macros - perhaps not, but using lambdas, `std::arrays`, and `<algorithm>` and `<numeric>`, you can get pretty close.
* Way way way too much magic numbers.
* Seems like a bunch of wheel-reinvention. Aren't there libraries for raw interaction with the hardware? e.g. EGA/VGA palettes?
etc.
Everything you take for granted today was bought and paid for with what people learned yesterday. You're judging technology that's likely close to 25 years old and the person using it by today's standards.
>I wrote the editor for 16-bit DOS because I thought there would be significant troubles trying to mix 16-bit interrupt callbacks with 32-bit protected-mode code. Also I don’t think I knew back then, that DJGPP has been as modernized as it indeed has. If it even was. So I used Borland C++ 3.1.
>This compiler by Borland was created before C++ was standardized, and it required me to make many sacrifices about style / sanity in the source code. For example, it did not support namespaces or templates. No STL! As such, the code is not representative of good programming practices for C++ programming, not by a long shot.
He's using his own editor:
In situations like this, I recommend acclimating yourself to the unusual style as a mental exercise. You will likely have to read a lot of quirky and/or legacy code in your career.