Throughout human history, people try to make the biggest, the fastest, and — sometimes — the smallest. [Hellmood] falls into the latter category and proves it with a 64 byte interactive 3D raycasting application for MSDOS.
Why MSDOS? We suppose why not? The .COM file format is lean, and you can take over everything without a lot of work. If the program were huge, it wouldn’t be very impressive. There are 64 shades of gray which is odd looking these days, however there are versions that use various color palettes and each one fits in 64 bytes or less. There’s even mouse control and you can see the results in the video below.
There were even some versions that didn’t do 3D and ray tracing that fit in 43 bytes, but that’s not as impressive visually. As you might expect, the code is written in assembly:
We looked at the code and recognized a BIOS call to set the video mode to 13 hex and some direct port output to the VGA video DAC at 0x3C9. We got lost after that, but it is certainly an economical program even if we can’t see how it is reading the mouse.
If you get the urge to do some MSDOS programming yourself, you can use gcc although you will almost surely get bigger executables. If you are just nostalgic for old games and software, you can run those in your browser.
51 thoughts on “Tiny Ray Tracer Fits In 64 Bytes”
Serpinki’s carpet right?
The inner walls have the AND texture, the front walls have a XOR texture, so yes, there’s kind of a hidden Sierpinski Carpet in the inner walls =)
Bet that would look great on an old high-curvature CRT. Actually, people who made graphics back in the day used a lot of the peculiarities and artifacts of CRTs to their advantage. Sprites in old games look magically more detailed and nicely shaded, then revert to flat garbage on a new display.
Indeed. You’d think our GPUs were up to CRT modeling.
Wonder what it would take to make this a real thing? Are pixel shaders still a thing?
MAME already has the ability to more or less accurately model a CRT. It has since 2011 when I added DX9 pixel-shader support, and again in 2015 when I did it in a more cross-platform way using the BGFX library as a backend.
It even supports an NTSC encoder/decoder pass, so as to give proper colors on systems like the Apple II when fed nothing but a monochrome image. I don’t know how to post images in Hackaday comments, but here’s a link: https://i.imgur.com/SLpnxBc.jpg
The link without the SSL for public enjoyment:
And for good measure, the BGFX backend even supports using different shaders in different viewports. So if you’re tired of having black pillarboxes surrounding the emulated 4:3 screen, you can do things like throw a blur+desaturate+zoom shader in there on the edges: https://i.imgur.com/o9YohXO.png
its interesting that the only people who say “they took advantage of it” don’t even have a quote from the THOUSANDS of people that worked in the industry of the time… they just assume people working on state of the art computer stations in rooms full of studio monitors is magically catering to YOUR specific crappy old Zenith
Many of the computer games back in the day were made by individual hackers or small groups, on their crappy old Zenith TVs, and then sold to the big publishing houses for some crappy royalty.
Game development was such hit & miss business that the publishers didn’t much bother employing the hackers directly on the off-chance that they’d come up with something clever; game development only became a big business after computer hardware started to become standardized enough that you could write game engines and skip re-inventing the wheel. That’s when they also dropped the clever hacks and pixel art.
… This is pure bullshit. There are interviews of old game programmers which gives examples of the development environment used which doesn’t generally involve studio monitors* with state of the art computer stations (whatever that would be). There are also graphics artists that have described how they took advantage of “flaws” and last it is obvious to anyone actually looking at the graphics. The graphics artists weren’t stupid.
(* which still give the same kind of distortions as other CRTs as otherwise they wouldn’t provide a true reference picture)
Exactly. A good friend of mine was one of the co-founders of a company that did SNES games back in the 90’s. He’s more than happy to tell stories about doing development on a commodity PC using the MS-DOS version of DeluxePaint, with the development kits hooked up to commodity composite-input monitors like various Commodore monitors.
Your just romanticising it. It’s a pretty ironic claim to make when it is so obvious just how much better graphics look on modern displays. If those artists you mention, but fail to name, really “took advantage” then they didn’t do a very good job. Meanwhile, there is only a single effect they could have made use of and it’s phosphor bloom. All they did was draw graphics which looked good to them and given the difference in effect of modern displays with low resolution graphics is squarer more clearly defined pixels I can’t see even if they’d drawn graphics on modern screens how it would have made any difference, after all, low resolution pixels on modern screen with small colour palettes are going to look big and square, no matter how you draw them. It’s a stupid argument. I play lots of retro games from the SNES, Commodore 64, arcades, Sinclair Spectrum and Amiga and I have never seen a single example of any game which by any objective standard looks better on a CRT. It’s just blurred. I can recreate blur on a flat panel with a filter if I really want to, but don’t.
Thanks Osgeld. I absolutely agree. People drawing graphics on CRTs only did what looked good to them. There is huge overstatement from analogue/CRT fans in “taking advantage of…”. I personally far prefer the alleged “garbage” modern flat panels produce. I prefer it so much I think the accusation is quite ironic because it’s so very obvious even old graphics from games written in the NTSC/PAL CRT era look far, far better on a modern flat panel where there definition is far more easily seen.
It’s basically subpixel rendering. Still possible, but the results will be different and nobody will see it because modern displays have incredibly tiny pixels.
More like an analog low-pass filter.
64 Shades Of Grey …. now THAT’S nerd sexy!!!!
There is also a 85 shades version in the archive on pouet, but it flickers too much so i went for “just” 64 shades ;)
Raycasting != raytracing.
Yeah, two totally different things.
(author here) Thanks for featuring this :) If you wanna know more about how to do something like this yourself, jump over to our wiki : http://www.sizecoding.org/wiki/Main_Page
Finally something to replace 3sc tube :)
“even if we can’t see how it is reading the mouse” – that’s because you likely looked at the wrong source. “intoanew 64b.asm” uses the timer (references 0x46c, which is the BIOS data area timer tick variable), “wolf64a inter dosbox ESC 64b.asm” uses int 33h, which is the interface to the mouse driver.
makes me believe that it uses only 16 shades of gray.
That’s right, the interactive version uses 16 predefined shades of the default VGA palette. Custom color generation would not have fit into 64 bytes with mouse interactivity.
That’s plenty! I used to play games on a laptop with just a few shades of gray. One game had color coded puzzles… Couldn’t get past it without some cheating!
Those were the times, when the games were exciting. Now they produce worn out inclusive PC trash – games made of recycled over and over shit. Eaten and excreted million times.
Sorry. This seems to be a case of clever bitmap shifting. Where is the the relation to raytracing?
It’s technically a raycaster. See svofskis explaination here. “Clever bitmap shifting” would need much than 64 bytes as far as i understand your idea.
The output to port 0x3C9 was to set the palette. Good times, good times….
I learned that trick in qbasic. out 0 to 3c8, and then output the colour triads to 3c9 to fill the pallet. RAINBOW!
I still have the code heh.
I learned it in QB as well :) Later i learned, that you can fire the values to 3c9 right away, which i did here. It might not work on 100% of all systems, but precious bytes were saved there :D Also, some version used the alternative way to set the colors … go check it out =)
Raytracing = global illumination model where value of a pixel is determined by shooting a ray from this pixel through the camera plane until it hits a light or until its input becomes negligible. It’s great for specular reflections and refractions.
Raycasting = shooting rays from pixels through the camera plane to find intersections with surfaces, the surfaces are often defined analytically (like in this demo) or as datasets (e.g. from a CT scan or Kinect point cloud). As a result you get a point on a surface. Using a normal at this point, the actual light value can then be calculated using raytracing or some simple illumination model.
Here’s Inigo Quilez’s fantastic site with tutorials, examples, explanations and everything: http://www.iquilezles.org/www/index.htm
Many people know him as iq, the author of elevated and other intros http://www.pouet.net/user.php?who=4063
Yeah, sure… RTX technology for DOS, yeah, really!
Amazing – but not one thing about this is a ‘Ray tracer’!!!
Indeed. I specifically called it “raycaster” everywhere. Maybe a real raytracer is also possible in 64 bytes, but i am not there yet ;)
I did a quick port to shadertoy (also sizecoding, but taking whooping 125 bytes there ^^) It’s maybe more readable than the ASM source and might give some insights about how this works. https://www.shadertoy.com/view/4tVBzD
Dunno if it would help any, or what for programming mag I read about, but in real mode,386 or higher, all the 32 bit registers are available..EAX, EBX,ECX,etc
just put the .386 directive at the top of your code
I rarely use 32bit registers at all, since every instruction on these requires an extra byte :| I remember one case where i explicitly needed a 32bit register, a 64 byte hires still fractal renderer : http://www.pouet.net/prod.php?which=64159
Great point, MSDOS was written for the 8 bit 8088, common misconception was the 8086 would run it twice as fast, no maybe 1.5x. Why? Word alignment, slowed it down.
386 has a 4 byte data bus, but the cpu still has to re-read data if its not aligned correctly.
hense .Align was created
MSDOS was QDOS which was written on and for a 8086 system.
This is dumb. Lots of processors could lose cycles if various data objects were not aligned to words or pages. The solution was easy: If it made any difference, the programmer would simply align the data to a word or page. Takes seconds. Regards, a professional programmer.
Good to see other people using DOS as well :) I am just finishing with my light control software written in QBasic, using LPT. So clean, entire machine for myself, nothing getting in the way.
If your machine has enough disk space, I highly recommend Visual Basic 1.0 for DOS , AFAIK , its available for free. It’s event driven, and I’ll post the Winders code to make it not take 100% cpu time
Very cool work. 64 bytes? How many instructions is it?
Wozniak did his 6502 floating point in 256 bytes and his basically bit-banged floppy head control, read/write/ encode/decode in a tiny space. In these days of Linux with 256GBytes on 4 cores in $10 credit card sized PCBs, it is great to see someone working on the small and fast.
Depending on the version (64 colors & softclipping, interactive) it’s 33 or 34 instructions. No floating point whatsoever ;)
Be fun if someone did this in EXAPUNKS.
Reminds me of that one time someone showed the better part of the first level of Descent 3D (including the recharge side-tunnel) into 2048 bytes as a fully animated demo, if I recall correctly. Tunnel and lava textures were generated on the fly not stored except for the recharge sparks – those were cheaper to store. Unfortunately, I can’t find the link…
Please find it :) As a reference, there is a famous 256 byte tunnel from 2001 from “baze” which still holds up nicely http://www.pouet.net/prod.php?which=3397 We have come far since, but back then this one was totally mindblowing
Turns out it’s the most-thumbs-up 4K DOS demo on pouet: http://www.pouet.net/prod.php?which=482
Besides the WebGL port i posted above, this raycaster can also be run “natively” (simulated in DosBox) in your browser : http://twt86.co/ (switch to wolf64.asm there) Beware, it’s nowhere near the speed of an original PC ^^
Please be kind and respectful to help make the comments section excellent. (Comment Policy)