Interactive Raycaster For the Commodore 64 Under 256 Bytes 143
New submitter Wisdom writes "1bir (1 Block Interactive Raycaster) is a simple ray casting engine implemented only in 254 bytes to run on a stock, unexpanded Commodore 64. The name comes from the fact that on a C64 floppy disk, 1 block is equivalent to 254 bytes stored on a disk sector. In 254 bytes, 1bir sets up the screen for drawing, creates sine and cosine tables for 256 brads based on a simple approximation, casts rays into a 2D map that lives inside the C64 KERNAL ROM, renders the screen in coordination with KERNAL, evaluates 8-way joystick input and detects collision against walls. The ray casting core employs a brute force algorithm to determine visible walls, while the mapping portion supports both open-ended (infinitely looped) and traditional, closed maps. The source code in 6502 assembly is available, with extensive comments. A YouTube video showcases 1bir in a detailed manner with both kind of maps and more information, while a Vimeo video presents a shorter demonstration."
Uses two undocumented / illegal instructions (Score:5, Interesting)
It's interesting to note that the code uses two "undocumented" 6510 instructions:
These instructions are undefined; they work by taking advantage of the internal CPU architecture to execute a hybrid of other legal opcodes. A lot of other older processors have such behavior, such as the Z80. Even the 8086 had a bit of this: "pop cs" and the second encoding of "sar" come to mind. (The 8086's "pop cs" was stolen by the 286 to mean an escape to a second opcode page.)
Re:Real-work problem? (Score:5, Interesting)
As a bioinformatician who's trying to give researchers better tools to identify disease, whose projects could also improve the lives of lots of folks: this is not that kind of programming. Demoscene programmers are generally hired by graphics companies and embedded systems development, where their formidable optimization abilities actually get put to use; those skills are not transferable to general high-performance computing. You'll have to keep hiring out of the general CS grad pool.
Re:(oblig) Better late than never (Score:5, Interesting)
Had the software been around when I used a C64 (when they were the state of the art) . .
What do you mean? C64 still is state of the art . . . for 1982.
On the other hand, a clever hack borders on being timeless - for example and inspiration if nothing else.
Certainly in a time of ever greater bloatware it can border on mind-blowing to consider what people used to do, and some still do, in handfuls or hundreds of bytes: The Puzzle [folklore.org]
Visual Transistor-level Simulation of the 6502 CPU [visual6502.org]
Re:Zip? (Score:5, Interesting)
The source code is zipped. For a 254 byte program. This just tickles me for some reason.
When you have a 300 baud modem on your C64 and Delphi Online charges by the minute, every last byte adds up!
The funny thing is, back then the handy thing about 300 baud was there was no need to pipe things to more -- you could just cat a file and read it as it downloaded ...
Stupid 1200 baud modems messed that all up ...
Optimization (Score:5, Interesting)
My 6502 is not completely lost.
Here is how to optimize the code a little bit:
Replace:
with:
This saves 2 bytes and a few cycles.
Re:Will this run . . . (Score:5, Interesting)
It is quite possible that it will run on VIC20, but it will probably need some modification to the actual render code (I do not have a VIC20, so I am not sure). Other than that, it should work, as RAM usage is minimal (just needs 320 bytes for sine/cosine tables, ZeroPage and the 1K video RAM).
Nevertheless, I will include it in the next release. Thanks for the idea.
Or, 2MHz 6809 with full 3d Game (Score:2, Interesting)
This was done a decade ago for the Color Computer (6809). A self-modifying 3d engine in ~256 bytes was turned into a full "doom" style 3d game.
http://members.optusnet.com.au/nickma/ProjectArchive/crasher.html
With video!
https://www.youtube.com/watch?v=jVFn_djQ6EY
Re:Optimization (Score:5, Interesting)
Well, it was not obvious.
I originally wanted to optimize the sign extend using some carry tricks, like asl/lda #0/sbc #0, but realized that it was unnecessary.
In fact, you can improve it even more, as follows:
Saving 6 bytes !
This trick is mentioned here:
http://forum.6502.org/viewtopic.php?p=5262 [6502.org]
BTW, your tsx/txs trick is really horrible, it forces the stack at the bottom of $100.