This effort is truly specular!
BBC BASIC raytracer in 432 characters
21–30 of 96 posts
Re: BBC BASIC raytracer in 432 characters
#22Earlier quoted context omitted.
Some good discussion of that on The BBC BASIC wiki entry: https://en.wikipedia.org/wiki/BBC_BASIC (paragraph beginning "Due to a number of optimizations[…]".
Also you could swap out hot spots with assembly trivially as it had an inline assembler. And you had indirect pointers in it!
The OP's code has REM based assembly it in to save space
Re: BBC BASIC raytracer in 432 characters
#23Re: BBC BASIC raytracer in 432 characters
#24Also, don't miss the gallery site! https://www.bbcmicrobot.com
the gallery site is amazing in and of itself. the gallery isn't PNGs or GIFs - it's generated in the browser from the emulator state. if you hover over an item it resumes the emulator.
Re: BBC BASIC raytracer in 432 characters
#25In the replies underneath, someone ran it on a real Acorn Electron computer (6502 at 1 MHz), where it completed in 8 hours and 40 minutes. Not too bad really.
I'm running this on a BBC micro emulator running at period-accurate speed, and it's taking just under a minute to draw one line. So I think it's going to finish in about 4 hours, which would make sense - approximately twice as fast as the Acorn Electron.
Update: Finished in only 2 hours 30 minutes.
Re: BBC BASIC raytracer in 432 characters
#26https://www.pouet.net/prod.php?which=78045
Incredible raytraced demo in 256 bytes.
Re: BBC BASIC raytracer in 432 characters
#27Ok, this is probably a dumb question: I get that the code traces the rays for this scene, obviously — but where is the scene, then? That is, where is the “data” (as opposed to the algorithm) that says “there’s a sphere at coordinates x,y,z with radius r, and here’s the other one, and here’s the checkerboard plane”?
It’s mostly implicit. See how the spheres are symmetric about the centerpoint? (Well, almost, the camera is at Y = -0.1.) The (X, Y) coordinates of their centers are simply (-1, -1) and (1, 1), given by the `I = SGN U` variable at the end of line 40. The Z is implicitly zero. Their radius is 1. The plane is basically defined by `P = Y - 2` at line 60.
…to elucidate a bit, when tracing the rays on the left side of the image, the sign of u is -1, so we're trying to intersect a sphere at (x-1, y-1, z), and on the right side similarly one at (x+1, y+1, z). This works because none of the left-side rays can even in theory hit the right-side sphere and vice versa. It's a very simple version of space partitioning optimization. And when tracing the reflected rays, we flip the sign of i, because there's no self-reflection – the left-hand sphere can only reflect the right-hand one and vice versa.
Re: BBC BASIC raytracer in 432 characters
#28This effort is truly specular!
[flagged]
Re: BBC BASIC raytracer in 432 characters
#29Ok, this is probably a dumb question: I get that the code traces the rays for this scene, obviously — but where is the scene, then? That is, where is the “data” (as opposed to the algorithm) that says “there’s a sphere at coordinates x,y,z with radius r, and here’s the other one, and here’s the checkerboard plane”?
The 3D scene is described by formulas instead of data. It's a bit similar to how SDF demos describe a 3D scene by combing shape formulas into a single formula for the whole scene (SDF = signed distance fields).
E.g. see:
Re: BBC BASIC raytracer in 432 characters
#30Earlier quoted context omitted.
If you go to the source link - https://bbcmic.ro/?t=9ctpk - then you can see the numbers with the lines. They increment in steps of 10 (which IIRC you could override manually with numbers in-between).
thanks! i didn't see that link. but i think the 432 bytes leaves the line numbers out, so it should actually be 448 bytes
I guess that's a philosophical question.
In most home computer BASIC interpreters, the source code (including line numbers) never exists as text in memory or on tape/disk, only as binary tokens. The only place where the original input text exists is a small line buffer which gets translated into binary token form when pressing Enter/Return.
The LIST command translates the token form back into human readable text.
And if you use 'AUTO' you also never type any line numbers... so are they actually part of the source code? Is there even 'source code' when the original source is never stored as text anywhere? Is the 'source code size' then the size of the original text data (that actually never exists a whole), or the size of binary token representation in memory and on tape/disk? :)