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.

48 thoughts on “Tiny Ray Tracer Fits In 64 Bytes

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

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

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

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

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

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

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

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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