Tiny Ray Tracer Fits In 64 Bytes

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

        1. 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

    1. 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

      1. 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.

      2. … 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)

        1. 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.

        2. 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.

      3. 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.

  1. “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.

    1. 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.

      1. 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 =)

  2. 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

  3. 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

      1. 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

        1. 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.

  4. 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.

    1. 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

  5. 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.

  6. 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…

Leave a Reply to The MogCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.