I wrote a Raytracer for DOS, 16 VGA colors (2011) [video](youtube.com)
youtube.com
I wrote a Raytracer for DOS, 16 VGA colors (2011) [video]
https://www.youtube.com/watch?v=N8elxpSu9pw&lc=Ugw9uYtPMZ7t1-qfLr54AaABAg
45 comments
I have always been curious how some of these ECUs worked behind the scenes. I know many times when they were reverse engineered by tuners the major tables such as ignition advance, fueling, mass air flow, etc. would be identified and that would be enough to allow some tuning of the car. But there were always many tables with a mysterious purpose, such as tau adjustments, which were never fully understood. I also wondered how values were interpolated by the ECU considering most things are table based. The tables might have 500 rpm, 1000rpm, etc cells with timing values, but when you log the ECU you do not see big jumps in timing at those cutoff points.
> The tables might have 500 rpm, 1000rpm, etc cells with timing values, but when you log the ECU you do not see big jumps in timing at those cutoff points.
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.
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’m planning to build a transmission control module for my car. Can I please reach out with a couple of questions?
Bizqwit has done some phenomenal work. I loved his videos on how DOOM style 3D engines work where he goes through raycasting and BSP trees. He also has videos around how passwords work in old 8-bit console games. His article about dithering I read a while back was also super interesting and I can see that he used that in this raytracer. Highly recommended.
His "doom-style engine" video is closer to BUILD than DOOM - it recursively chases through convex sectors rather than using a BSP tree.
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.
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.
His channel is jaw-dropping.
My favorite thing about bisqwit is that he drives a charter bus for work, despite being an amazing coder. This is his hobby.
He used to! Now he is working as a developer again [1].
[1] https://bisqwit.iki.fi/cv.html
[1] https://bisqwit.iki.fi/cv.html
And also as a part-time dance instructor (maybe Israeli folk dance?). What an interesting dude.
Love bisqwit's videos.
For anyone curious how the mario animation is rendered in the editor: https://github.com/bisqwit/that_editor/blob/master/mario.cc
For anyone curious how the mario animation is rendered in the editor: https://github.com/bisqwit/that_editor/blob/master/mario.cc
This is art, and I mean that in the most literal way possible.
Bisqwit's channel is full of awesome stuff like this. Well worth a look at his other videos too.
I enjoy biscuit videos, but I think the code is very hard to follow. I've been a follower for over 3 years now. Exceptional programmer
DJGPP.
My DOS boxes in the 80's and 90's certainly never looked like that. Quite impressive, although I bet he has a bit more hardware than I did...
BTW: The Hebrew on the test pattern that appears in the start of the video is Isaiah 12:3 "ושאבתם מים בששון ממעייני הישועה"
Not sure what it's doing there.
Not sure what it's doing there.
He writes about religious stuff on his website. See "Writings" section.
https://bisqwit.iki.fi/jutut/#h5
https://bisqwit.iki.fi/jutut/#h5
Seeing his page loudly claiming that Islam is literally Satanic, in parallel with the coding style, gave me Terry A. Davis flashbacks.
One of the other videos on his channel is literally “256 colors is enough for anyone”, which is one of the commandments of TempleOS, so your flashbacks are well-informed ;-)
My memory may not be what it was, but I believe King Terry dictated 16 colors for the temple. 256 is 4-bits too many! You could do quality porn w/ 256, and that would be ungodly!
Seems that this Bisqwit also has a touch of the divine intellect. We must do a better job of protecting him!
Seems that this Bisqwit also has a touch of the divine intellect. We must do a better job of protecting him!
It's a christian thing - the highlighted letters are jesus' name, and there's a cross right in the middle.
I wrote one in Pascal about 1994. It was slow, but it worked.
[deleted]
It's kind of interesting, it's supposedly about raytracer, but raytracers even existed back then. I think the code that was presenting him "typing" the raytracer code and then presenting it was really the harder part to do.
IIRC we've had raytracers since the 60's since they're basically trigonometry and vector math, but due to limited memory computers at the time had it was never really used.
I used to use an open source ray tracer called POV-Ray in the early nineties and it was pretty impressive. Here’s an example of an early scene you could render with it: https://amp.reddit.com/r/vintagecgi/comments/eswamt/chesspov...
I remember using povray too. Officially it required a 386 pc but it could be recompiled for 286, which is what I did. My PC had a IIT 2c87 coprocessor that had special 4x4 matrix multiply instructions, so of course I modified povray to take advantage of that.
That matmul instruction seemed oddly specific, so I had to google that, and lo and behold, indeed there was such a thing! [0]
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...
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...
I no longer remember the numbers but the speed ups were measurable. That FPU had 24 FP registers (as compared to 8 in a regular 287). The best case would be to load a matrix to the registers and then have a bunch of vectors to multiply the stored matrix with. Then this thing could fly. Loading the matrix to the registers was slow though because 287 coprocessors used DMA to communicate with memory.
I did a few similar scenes using a software renderer I wrote - not a ray tracer, though - for a Computer Graphics class in the early 2000s. Except I used a painting by Jim Todd as background, named "What Price Victory":
http://1.bp.blogspot.com/_fmfAOCgGNJU/SQuCxkXJiRI/AAAAAAAAGE...
http://1.bp.blogspot.com/_fmfAOCgGNJU/SQuCxkXJiRI/AAAAAAAAGE...
Less active the last several years, but it's still around:
http://www.povray.org/
https://github.com/POV-Ray/povray
http://www.povray.org/
https://github.com/POV-Ray/povray
Well, the algorithm was developed in the 1600's, but I remember Turner Whitted's 1979 SIGGRAPH paper blowing me away. I mean, sure, they were slow, but before REYES, they were about the only solution to GlobIlum. (Forward from the lights and backwards from the camera - you could even do specular lighting!)
Reyes isn't a global illumination algorithm, in fact it doesn't prescribe any kind of illumination at all. Global illumination was first described by Cindy Goral, Ken Torrance and Donald Greenberg in the constrained setting of diffuse reflectance in polygonal scenes; the first general GI algorithm, path tracing, was introduced in 1986 by James Kajiya.
https://en.wikipedia.org/wiki/Radiosity_(computer_graphics)
https://en.wikipedia.org/wiki/Radiosity_(computer_graphics)
The way I implement REYES, it does. But no doubt- Kajiya was the man.
I'm curious how you would solve the GI problem with Reyes; note that doing something like like photon mapping or radiosity isn't Reyes itself.
Photon mapping. I've never gotten radiosity debugged properly. I tend to like Reyes as something that works for NURB tersellation for me than the triangle interpolation thing. It could be that I'm a lazy programmer that has trouble with textures using classic z-buff techniques.
http://www.etwright.org/cghist/juggler.html - similar work from 1987 on an Amiga
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.
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.
This webpage[0] claims that realtime raytracing has existed since 1995, demo can run on PC/MS-DOS
[0]: http://www.realtimerendering.com/resources/RTNews/demos/over...
[0]: http://www.realtimerendering.com/resources/RTNews/demos/over...
I actually like the video of the author writing in the source better than the ray-tracing. What kind of editors is he using, anyway?
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.
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.
He's writing this in Borland C++. If my memory serves me correctly, there wasn't even a widely available STL implementation for this compiler, let alone standard header names, standard containers, lambdas, <algorithm>, <numeric>, hardware abstraction libraries, etc. etc. etc. The title is verbatim "I wrote a Raytracer for DOS, 16 VGA colors."
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.
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.
Yes. And in his editor README he explains why he has to use Borland C++
>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.
https://github.com/bisqwit/that_editor
>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.
https://github.com/bisqwit/that_editor
> What I _don't_ like is his coding style. If he's writing C++, let him use modern C++.
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.
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.
> What kind of editors is he using, anyway?
He's using his own editor:
https://github.com/bisqwit/that_editor
He's using his own editor:
https://github.com/bisqwit/that_editor
First learn what it was to program for MS-DOS, then comment, without bashing.
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 ;)