24 ms·

BBC BASIC raytracer in 432 characters

194 points by neffo 3y ago

man4 3y ago
[dead]
LeoPanthera 3y ago
In 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.
- kragen 3y ago
  that's astounding; i would have guessed months or years
  - LeoPanthera 3y ago
    BBC BASIC is surprisingly efficient for an interpreted language. It kind of had to be, running on processors that slow.
    - KerrAvon 3y ago
      Some good discussion of that on The BBC BASIC wiki entry: https://en.wikipedia.org/wiki/BBC_BASIC https://en.wikipedia.org/wiki/BBC_BASIC (paragraph beginning "Due to a number of optimizations[…]".
      - crimbles 3y ago
        Also you could swap out hot spots with assembly trivially as it had an inline assembler. And you had indirect pointers in it!
        mavhc 3y ago
        The OP's code has REM based assembly it in to save space
        kragen 3y ago
        is that assembly or is that the dithering table
        alphabetter 3y ago
        Yes, the REM is the lookup table used in line 70. Because BBC Basic had a built-in assembler it was pretty uncommon for BBC programs to inline machine code as raw data (unlike some other computers from BITD).
        londons_explore 3y ago
        just a table of constants.
    - kragen 3y ago
      all the basics i used on processors that slow were surprisingly inefficient, even for an interpreted languages i thought they had to be, running on processors with that little memory. though later on i learned about forth, which is surprisingly efficient for an interpreted language a more likely explanation is that sophie wilson was just a better hacker than bill gates and paul allen
      - iainmerrick 3y ago
        Yeah, BBC BASIC is really good. Both the language design and the implementation. I loved it at the time, and the more I think back on it the more impressed I am. Like it had a very decent suite of floating-point routines, which if I remember right were very performant. In a 32KB ROM!
        forinti 3y ago
        Basic was actually a 16KB ROM. MOS occupied another 16KB ROM.
        iainmerrick 3y ago
        Dang, you're right, I was misremembering.
        crq-yml 3y ago
        Some of the improvement in BBC BASIC over Microsoft's BASIC is attributable to the larger ROM(the first Altair BASIC was just 4k), but it's also that the BBC Micro's 6502 and DRAM was clocked higher than contemporaries. It's just a faster, more refined 8-bit machine all around.
  - bunabhucan 3y ago
    I recreated a mandlebrot zoom I saw in a library book in bbc basic and the last image took two weeks. I had 8 of them saved on a floppy and that would slideshow them for a 2fps "movie"
    - kragen 3y ago
      that is fucking awesome, you are a legend
- PlunderBunny 3y ago
  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.
  - PlunderBunny 3y ago
    Update: Finished in only 2 hours 30 minutes.
    - deleted 3y ago
      [deleted]
    - tom_ 3y ago
      The Electron runs extra slowly in MODE 1 as the video system needs 100% of the RAM bandwidth to form the display. The CPU essentially ends up paused during the visible portion of each scan line, so the effective speed is probably more like 0.6 MHz.
- Sharlin 3y ago
  I wonder how much of that it spent just computing those square roots.
  - araes 3y ago
    Does anybody happen to know what SQR algorithm BBC Basic uses? http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin7.html#printhash http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin7.html#printha... does not seem to have the actual algorithm. Intel's optimization manual has suggestions for fast versions at 15.12.3 (recommended by @James https://stackoverflow.com/a/2637823/10981777 https://stackoverflow.com/a/2637823/10981777) Don't look especially long to implement for 22-bit approximation. https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-optimization-reference-manual.html https://software.intel.com/content/www/us/en/develop/downloa... Also, what's the SQRD? Not finding that referred to anywhere.
    - Sharlin 3y ago
      SQRD is just SQR D :)
      - araes 3y ago
        Thanks. So much more of that code makes sense now. IFD, SGNU, FORN, FORM. FORM especially. So many codes now have the word FORM as a special word. What a nightmare to read though if you don't know what it's supposed to be written like. Is it a: "FORM=" or a "FOR M=" ? Is it: "S GNU:G", "SG NU:G", "SGN U:G"? SQRD totally looks like some special kind of square root implementation.
        Sharlin 3y ago
        Yeah, early BASICs tended to let you skip the spaces, and in fact it sometimes did have a measurable effect on parsing/execution speed. And of course on file size too… Additionally, at least C64 Basic had two-character shorthands for all keywords.
kragen 3y ago
this says `goto 50` but there are no line numbers
- LeoPanthera 3y ago
  The robot automatically adds line numbers in increments of 10s.
- EspadaV9 3y ago
  If you go to the source link - https://bbcmic.ro/?t=9ctpk 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).
  - PlunderBunny 3y ago
    If you're playing with this on a BBC micro emulator, the best way to get this code into the emulator is to download the disk image from the above link. The actual basic program is named "PROGRAM" on the disc. List the code by typing LIST20, (the computer will lock up if you try to list line 10). If you just want to see the result, type MODE 1 and then press return, then type *LOAD SCREEN and press return again.
  - kragen 3y ago
    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
    - flohofwoe 3y ago
      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? :)
deleted 3y ago
[deleted]
ManuelKiessling 3y ago
Ok, 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”?
- sp332 3y ago
  W=1/SQR(U*U+V*V+1) This makes a sphere. It gets multiplied by two coordinates to make spheres at different places, U and V.
  - kragen 3y ago
    i think this is incorrect, i think that's computing the z component of the initial direction vector of the ray being traced if you change the initialization of i from sgn u to 1.2 * sgn u you will get an image with the spheres a little further apart
    - Sharlin 3y ago
      Yeah, that's something of a red herring. The actual ray-sphere intersection happens on line 50: // sphere_center = (E, F, Z) E = X - I F = Y - I // solving the ray-sphere quadratic eqn... P = U * E + V * F - W * Z // discriminant D = P * P - E * E - F * F - Z * Z + 1 // if solution (ie. intersection) exists IF D > 0 // intersect_point = ray_orig + T * ray_dir // this is the closer pt, -P + SQR D is the other T = -P - SQR D
      - kragen 3y ago
        yeah, that was what i guessed it was doing, but i couldn't remember or rederive the ray-sphere intersection formula to be sure
- Sharlin 3y ago
  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.
ChrisArchitect 3y ago
This one was from 2021. Do enjoy the insane things ppl managed to cram into tweets to the bbcmicrobot over the years. Anyone who's followed any part of the demoscene especially the classic smaller payload demos.. 4k etc.....this kinda thing is mindblowing and totally in the same spirit.
po 3y ago
Also, don't miss the gallery site! https://www.bbcmicrobot.com https://www.bbcmicrobot.com
- neffo 3y ago
  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. https://mastodon.me.uk/@bbcmicrobot/111760484438439751 https://mastodon.me.uk/@bbcmicrobot/111760484438439751
jug 3y ago
This effort is truly specular!
- jbverschoor 3y ago
  [flagged]
rwmj 3y ago
https://www.pouet.net/prod.php?which=78045 https://www.pouet.net/prod.php?which=78045 Incredible raytraced demo in 256 bytes.
- briansm 3y ago
  https://www.pouet.net/prod.php?which=53871 https://www.pouet.net/prod.php?which=53871 https://www.youtube.com/watch?v=36BPql6Nl_U https://www.youtube.com/watch?v=36BPql6Nl_U Incredible raytraced demo in 128 bytes. (An underwater journey through a Menger-sponge fractal)
- kragen 3y ago
  last year i wrote a tetris in arm assembly https://asciinema.org/a/622461 https://asciinema.org/a/622461 and was pleased to get it down below 1024 bytes then i looked and rrrola's 4is256 https://www.pouet.net/prod.php?which=29286 https://www.pouet.net/prod.php?which=29286 is a working tetris in under 256 bytes, and it's better than mine because it has colors and scoring. i could blame a little bit of inflation on arm being 32-bit rather than 16-bit, but not 4×
  - bbojan 3y ago
    You could try using Thumb instructions, they are 16 bit.
    - kragen 3y ago
      i was, but i wasn't talking about the size of the instruction word, but the size of the registers
  - userbinator 3y ago
    The upper limit of instruction density on x86 is much higher than any RISC.
    - kragen 3y ago
      that hasn't been my experience with instructions i've written myself, but then again, i'm not rrrola
SillyUsername 3y ago
Can anybody provide de-obfuscated/minified source so those of us who understand the principle (tracing rays of light around a scene) can understand the maths?
- kragen 3y ago
  here's my attempt 10 REMĀĘĆĞ$Č*Ēĉ!ăě-ĕ'ď rem dithering table in comment above consulted by GCOL line? rem raytracer from https://bbcmic.ro/?t=9ctpk by https://mastodon.me.uk/@coprolite9000 rem deobfuscated and possibly broken by kragen javier sitaker (untested) 20 MODE 1 VDU 5 30 FOR N = 8 TO 247 : rem loop over rows (n) and columns (m) of pixels FOR M = 0 TO 319 40 X = 0 : rem three-dimensional vector Y = -.1 Z = 3 U = (M - 159.5)/160 : rem xform screen coords to direction vector V = (N - 127.5)/160 W = 1/SQR(U*U + V*V + 1) : rem normalize direction vector U = U * W V = V * W I = SGN U : rem derive coordinate of sphere center (i, i, 1)? G = 1 50 E = X - I : rem beginning of do-while loop F = Y - I P = U*E + V*F - W*Z D = P*P - E*E - F*F - Z*Z + 1 IF D <= 0 then goto 60 T = -P - SQR D IF T <= 0 then goto 60 X = X + T*U Y = Y + T*V Z = Z - T*W E = X - I F = Y - I G = Z P = 2*(U*E + V*F - W*G) U = U - P*E V = V - P*F W = W + P*G I = -I : rem if we are reflecting then check other sphere now GOTO 50 : rem end of do-while loop, we have our escape from the scene geometry rem color according to y-component of direction vector to get sky gradient rem if instead y component is negative, make a checkerboard of pieces of sky 60 IF V < 0 then P = (Y + 2)/V : V = -V*((INT(X - U*P) + INT(Z - W*P) AND 1)/2 + .3) + .2 70 GCOL 0, 3 - (48*SQR V + ?(PAGE + 5 + M MOD 4 + N MOD 4*4)/3) DIV 16 80 PLOT 69, 4*M, 4*N NEXT, i'm interested to hear what i got wrong see also https://news.ycombinator.com/item?id=39026517 https://news.ycombinator.com/item?id=39026517 and https://news.ycombinator.com/item?id=39026495 https://news.ycombinator.com/item?id=39026495
kragen 3y ago
a thing that puzzles me is how https://bbcmic.ro/?t=9ctpk https://bbcmic.ro/?t=9ctpk is only 4× faster in emulation (about 30 seconds per scan line and so on the order of 2 hours for the whole image) i'm running this on a ryzen 5 3500u at 2400 megahertz. the acorn electron which supposedly takes 8 hours and 40 minutes is a 1 megahertz 6502 when running from ram, roughly, 262144 instructions per second. at 2 ipc one core of the ryzen should be about 4800 mips. if the emulation slowdown is 10× (10 host instructions to emulate one guest instruction), which is typical for naïve interpretation, it should be about 1000× faster on this laptop as on the original hardware (possibly the basic is in rom and so it's closer to 524288 instructions per second) emulation through qemu-like dynamic code generation should cut the 10× slowdown to 3×, so it should be 3000× faster than the original hardware where did that factor of 1000 go? not the javascript engine, surely? incidentally there is a rocket-ship button underneath the output screen image labeled 'send to beebjit' which runs the program in about a second
- flohofwoe 3y ago
  If the emulator is entirely cycle correct for the entire system (including the video system, which is usually the most expensive to emulate, not the CPU), then the speedup on modern computers will be much less than just comparing the clock frequencies. Consider that each chip of a home computer system (CPU, 1..2 IO/timer chips, audio, video, ...) needs to do 'emulation work' for each 1 or 2 MHz clock cycle which can add up to quite a number of host computer instructions (dozens to hundreds). If each chip emulator just takes around 10..20 host system clock cycles to emulate one emulator clock cycle, then you are already looking at around 100 host system clock cycles per emulated clock cycle for the entire home computer (in reality it's probably worse). Such 'vertically sliced' emulation code is also full of conditional branches which put a heavy burden on the host CPU branch predictor. ...and that's how a theoretical 1000x speedup suddenly becomes a 10x speedup, it's not the CPU emulation (this is usually cheap) but the rest of the emulated system which can be expensive. Different emulators use all sorts of tricks and shortcuts, but usually with tradeoffs like less precise emulation, or less 'compartmentalized' code. PS: case in point this is just the top-level per-cycle function in my C64 emulator, which in turn calls per-cycle-functions in each of the chip emulators (which may each be just as much code): https://github.com/floooh/chips/blob/9a7f6d659b5d1bbf72bc8d060e5130b45e283480/systems/c64.h#L554-L745 https://github.com/floooh/chips/blob/9a7f6d659b5d1bbf72bc8d0... I'm trying to strike a balance between 'purity' (e.g. an entire emulated system can be 'plugged together' by wiring together chip emulators, just like one would build a real 8-bit computer on a breadboard), while still being fast enough to comfortably run in realtime even in browsers (https://floooh.github.io/tiny8bit/c64.html https://floooh.github.io/tiny8bit/c64.html). It's definitely possible to implement a faster cycle-correct C64 emulator with a less 'pure' architecture, but it's quite hard to do meaningful optimizations while keeping that same 'virtual breadboard' architecture. ...considering all the code that runs per cycle it's actually amazing how fast modern CPUs are :)
londons_explore 3y ago
In 398 characters, I can give it error diffusion dithering capabilities, which makes the code smaller and the output quality a bit better: https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE1%3AVDU5%3AB%3D0%5CnFORN%3D8TO247%3AFORM%3D0TO319%5CnX%3D0%3AY%3D-.1%3AZ%3D3%3AU%3D%28M-159.5%29%2F160%3AV%3D%28N-127.5%29%2F160%3AW%3D1%2FSQR%28U*U%2BV*V%2B1%29%3AU%3DU*W%3AV%3DV*W%3AI%3DSGNU%3AG%3D1%5CnE%3DX-I%3AF%3DY-I%3AP%3DU*E%2BV*F-W*Z%3AD%3DP*P-E*E-F*F-Z*Z%2B1%3AIFD%3E0T%3D-P-SQRD%3AIFT%3E0X%3DX%2BT*U%3AY%3DY%2BT*V%3AZ%3DZ-T*W%3AE%3DX-I%3AF%3DY-I%3AG%3DZ%3AP%3D2*%28U*E%2BV*F-W*G%29%3AU%3DU-P*E%3AV%3DV-P*F%3AW%3DW%2BP*G%3AI%3D-I%3AGOTO40%5CnIFV%3C0P%3D%28Y%2B2%29%2FV%3AV%3D-V*%28%28INT%28X-U*P%29%2BINT%28Z-W*P%29AND1%29%2F2%2B.3%29%2B.2%5CnB%3DB%2B3*SQRV%3AGCOL0%2C3-INTB%3AB%3DB-INTB%5CnPLOT69%2C4*M%2C4*N%3ANEXT%2C%22%7D https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE1... It would look even better with bidirectional error diffusion, but that requires reading back memory which I don't know how to do.
- logicallee 3y ago
  Thanks for sharing. I asked ChatGPT to analyze your code, while telling it what it does. How well do you think it did? Did it make any mistakes? https://chat.openai.com/share/6e754fa1-531d-432e-a767-8c81320dff5d https://chat.openai.com/share/6e754fa1-531d-432e-a767-8c8132...
  - bmsleight_ 3y ago
    Wow - I never thought of using ChatGPT for analysing code. It reads well - but does the author agree ?
  - CamperBob2 3y ago
    I just asked it to reformat the code for better readability, and it guessed it was a ray tracer. I for one welcome our new robot^H^H^H^H^Hparrot overlords. Also tried having it generate a JavaScript version, but the output doesn't look right: https://chat.openai.com/share/5d76e32b-81a1-4b4a-a808-7682a8cef6b3 https://chat.openai.com/share/5d76e32b-81a1-4b4a-a808-7682a8... I'd be inclined to suspect the lack of line numbers, as a first guess towards the problem.
anovikov 3y ago
Just curious how fast could the same thing be if someone who knows the hardware really well, wrote it in assembly.
- aardvark179 3y ago
  There’s a bunch of things you can do. Replacing all the square roots with a lookup table might be doable, and you could make the final drawing faster by not using the generic plot routines. You don’t have a lot of memory to play with though as you only have 32k to start with and the frame buffer will use 20k of that, so I’m not sure how good a look up table you could make for SQR.
Sharlin 3y ago
In a subthread, I got nerdsniped to figure out how this works, and for fun transcribed it ~faithfully to Rust – this one just outputs ASCII art instead of plotting pixels. You'll want to zoom out your browser as far as you can: https://www.rustexplorer.com/b#Zm4gbWFpbigpIHsKICAgIC8vIHJvdyBsb29wIOKAkyB1c2UgZmV3ZXIgcm93cyBkdWUgdG8gbm9uLXNxdWFyZSBhc3BlY3QgcmF0aW8KICAgIC8vIDMwIEZPUk49OFRPMjQ3CiAgICBmb3IgbiBpbiAoMC4uMTIwKS5yZXYoKSB7CiAgICAgICAgLy8gY29sdW1uIGxvb3AKICAgICAgICAvLyBGT1JNPTBUTzMxOQogICAgICAgIGZvciBtIGluIDAuLjMyMCB7CiAgICAgICAgICAgIC8vIGNhbWVyYSBjb29yZHMgPSByYXkgb3JpZ2luIHBvaW50CiAgICAgICAgICAgIC8vIDQwIFg9MDpZPS0uMTpaPTMKICAgICAgICAgICAgbGV0IG11dCB4ID0gMC4wOwogICAgICAgICAgICBsZXQgbXV0IHkgPSAtMC4xOwogICAgICAgICAgICBsZXQgbXV0IHogPSAzLjA7CgogICAgICAgICAgICAvLyByYXkgZGlyZWN0aW9uIHZlY3RvcgogICAgICAgICAgICAvLyBVPShNLTE1OS41KS8xNjA6Vj0oTi0xMjcuNSkvMTYwOlc9MS9TUVIoVSpVK1YqVisxKQogICAgICAgICAgICBsZXQgbXV0IHUgPSAobSBhcyBmMzIgLSAxNjAuMCkgLyAxNjAuMDsgLy8gcmF5IGRpciB4CiAgICAgICAgICAgIGxldCBtdXQgdiA9IChuIGFzIGYzMiAtIDYwLjApIC8gNjAuMDsgLy8gcmF5IGRpciB5CiAgICAgICAgICAgIGxldCBtdXQgdyA9IDEuMCAvICh1ICogdSArIHYgKiB2ICsgMS4wKS5zcXJ0KCk7CgogICAgICAgICAgICAvLyBub3JtYWxpemUgcmF5IGRpcgogICAgICAgICAgICAvLyBVPVUqVzpWPVYqVwogICAgICAgICAgICB1ICo9IHc7CiAgICAgICAgICAgIHYgKj0gdzsKCiAgICAgICAgICAgIC8vIHdoaWNoIHNwaGVyZSB3ZSB0cnkgdG8gaW50ZXJzZWN0IHNvbGVseSBkZXBlbmRzIG9uIHRoZSBzaWduIG9mIHUKICAgICAgICAgICAgLy8gST1TR05VOkc9MQogICAgICAgICAgICBsZXQgbXV0IGkgPSB1LnNpZ251bSgpOwogICAgICAgICAgICBsZXQgbXV0IGcgPSAxLjA7IC8vIHRoZSAxLjAgaXMgYWN0dWFsbHkgbmV2ZXIgdXNlZAoKICAgICAgICAgICAgLy8gc3BoZXJlIGludGVyc2VjdGlvbiBhbmQgcmVmbGVjdGlvbnMKICAgICAgICAgICAgLy8gbm8gcmVjdXJzaW9uIG5lZWRlZCBhcyB3ZSdyZSBub3Qgc3BsaXR0aW5nIHJheXMKICAgICAgICAgICAgLy8gdGhlIG9yaWdpbmFsIHNpbXBseSB1c2VzIGdvdG8gdG8ganVtcCBiYWNrIHNvIHRoaXMgbG9vcCBpcyBpbXBsaWNpdAogICAgICAgICAgICAncmVmbGVjdDogbG9vcCB7CiAgICAgICAgICAgICAgICAvLyBzcGhlcmUgY2VudGVyIGlzIGF0IChlLCBmLCB6KQogICAgICAgICAgICAgICAgLy8gNTAgRT1YLUk6Rj1ZLUkKICAgICAgICAgICAgICAgIGxldCBtdXQgZSA9IHggLSBpOwogICAgICAgICAgICAgICAgbGV0IG11dCBmID0geSAtIGk7CgogICAgICAgICAgICAgICAgLy8gc29sdmUgcmF5LXNwaGVyZSBxdWFkcmF0aWMgZXF1YXRpb24KICAgICAgICAgICAgICAgIC8vIFA9VSpFK1YqRi1XKloKICAgICAgICAgICAgICAgIGxldCBtdXQgcCA9IHUgKiBlICsgdiAqIGYgLSB3ICogejsKCiAgICAgICAgICAgICAgICAvLyBkaXNjcmltaW5hbnQKICAgICAgICAgICAgICAgIC8vIEQ9UCpQLUUqRS1GKkYtWipaKzE6SUZEPjAKICAgICAgICAgICAgICAgIGxldCBkID0gcCAqIHAgLSBlICogZSAtIGYgKiBmIC0geiAqIHogKyAxLjA7CiAgICAgICAgICAgICAgICBpZiBkID4gMC4wIHsgLy8gcmF5IGludGVyc2VjdHMgc3BoZXJlCiAgICAgICAgICAgICAgICAgICAgLy8gdHdvIHNvbHV0aW9ucywgY2hvb3NlIHRoZSBvbmUgY2xvc2VyIHRvIHRoZSBjYW1lcmEKICAgICAgICAgICAgICAgICAgICAvLyBpbnRlcnNlY3QgcG9pbnQgPSByYXlfb3JpZ2luICsgdCAqIHJheV9kaXIKICAgICAgICAgICAgICAgICAgICAvLyBUPS1QLVNRUkQKICAgICAgICAgICAgICAgICAgICBsZXQgdCA9IC1wIC0gZC5zcXJ0KCk7IAogICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgIGlmIHQgPiAwLjAgeyAvLyBpbnRlcnNlY3QgcG9pbnQgbm90IGJlaGluZCByYXkgc3RhcnQgcG9pbnQKICAgICAgICAgICAgICAgICAgICAgICAgLy8gWD1YK1QqVTpZPVkrVCpWOlo9Wi1UKlcKICAgICAgICAgICAgICAgICAgICAgICAgeCArPSB0ICogdTsgLy8KICAgICAgICAgICAgICAgICAgICAgICAgeSArPSB0ICogdjsgLy8gaW50ZXJzZWN0IHBvaW50IGNvb3JkcyA9IHJlZmxlY3RlZCByYXkgc3RhcnQKICAgICAgICAgICAgICAgICAgICAgICAgeiAtPSB0ICogdzsgLy8KCiAgICAgICAgICAgICAgICAgICAgICAgIC8vIHNwaGVyZV9ub3JtYWwgPSBpbnRlcnNlY3RfcHQgLSBjZW50ZXJfcHQKICAgICAgICAgICAgICAgICAgICAgICAgLy8gRT1YLUk6Rj1ZLUk6Rz1aCiAgICAgICAgICAgICAgICAgICAgICAgIGUgPSB4IC0gaTsKICAgICAgICAgICAgICAgICAgICAgICAgZiA9IHkgLSBpOwogICAgICAgICAgICAgICAgICAgICAgICBnID0gejsKCiAgICAgICAgICAgICAgICAgICAgICAgIC8vIHJlZmxlY3QgYWJvdXQgbm9ybWFsCiAgICAgICAgICAgICAgICAgICAgICAgIC8vIFA9MiooVSpFK1YqRi1XKkcpCiAgICAgICAgICAgICAgICAgICAgICAgIHAgPSAyLjAgKiAodSAqIGUgKyB2ICogZiAtIHcgKiBnKTsgCgogICAgICAgICAgICAgICAgICAgICAgICAvLyBuZXcgcmVmbGVjdGVkIHJheSBkaXIKICAgICAgICAgICAgICAgICAgICAgICAgLy8gVT1VLVAqRTpWPVYtUCpGOlc9VytQKkcKICAgICAgICAgICAgICAgICAgICAgICAgdSAtPSBwICogZTsKICAgICAgICAgICAgICAgICAgICAgICAgdiAtPSBwICogZjsgCiAgICAgICAgICAgICAgICAgICAgICAgIHcgKz0gcCAqIGc7CgogICAgICAgICAgICAgICAgICAgICAgICBpID0gLWk7IC8vIHRoZSBvbmx5IHNwaGVyZSB0byByZWZsZWN0IGlzIHRoZSBvdGhlciBvbmUKCiAgICAgICAgICAgICAgICAgICAgICAgIC8vIEdPVE81MAogICAgICAgICAgICAgICAgICAgICAgICBjb250aW51ZSAncmVmbGVjdDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAvLyBpbXBsaWNpdCBpbiB0aGUgb3JpZ2luYWwKICAgICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICB9CgogICAgICAgICAgICAvLyBwbGFuZSBpbnRlcnNlY3Rpb24KICAgICAgICAgICAgLy8gNjAgSUZWPDAKICAgICAgICAgICAgaWYgdiA8IDAuMCB7IC8vIGV2ZXJ5IGRvd253YXJkIHJheSBldmVudHVhbGx5IGhpdHMgdGhlIHBsYW5lCiAgICAgICAgICAgICAgICAvLyBQPShZKzIpL1YKICAgICAgICAgICAgICAgIGxldCBwID0gKHkgKyAyLjApIC8gdjsgLy8gcGxhbmUgaXMgYXQgeSA9IC0yCgogICAgICAgICAgICAgICAgLy8gd2hldGhlciBhIGxpZ2h0IG9yIGRhcmsgc3F1YXJlCiAgICAgICAgICAgICAgICAvLyAoSU5UKFgtVSpQKStJTlQoWi1XKlApQU5EMQogICAgICAgICAgICAgICAgbGV0IGNoZWNrZXIgPSAoKHggLSB1ICogcCkuZmxvb3IoKSArICgoeiAtIHcgKiBwKS5mbG9vcigpKSkgYXMgaTMyICYgMTsKICAgICAgICAgICAgICAgIC8vIGdyb3VuZCBmb2cgZWZmZWN0CiAgICAgICAgICAgICAgICAvLyBWPS1WKihjaGVja2VyLzIrLjMpKy4yCiAgICAgICAgICAgICAgICB2ID0gLXYgKiAoY2hlY2tlciBhcyBmMzIgLyAyLjAgKyAwLjMpICsgMC4yOwogICAgICAgICAgICB9CgogICAgICAgICAgICAvLyBhc2NpaSBhcnQgcGFsZXR0ZQogICAgICAgICAgICBsZXQgcGFsID0gYiIgLi06Kz0qY28jT0IlQFciOwogICAgICAgICAgICAvLyBuPTQgaW4gdGhlIG9yaWdpbmFsCiAgICAgICAgICAgIGxldCBuID0gcGFsLmxlbigpOwoKICAgICAgICAgICAgLy8gdmFsdWUgb2YgdiBpcyB1c2VkIGVpdGhlciBhcyBza3kgZ3JhZGllbnQgb3IgZ3JvdW5kIGNvbG9yCiAgICAgICAgICAgIC8vIEdDT0wwLDMtKDQ4KlNRUlYrPyhQQUdFKzUrTSBNT0Q0K04gTU9ENCo0KS8zKURJVjE2CiAgICAgICAgICAgIGxldCBpZHggPSBuIC0gMSAtIChuIGFzIGYzMiAqIHYuc3FydCgpIC8qICsgZGl0aGVyICovKSBhcyB1c2l6ZTsKCiAgICAgICAgICAgIC8vIHBsb3QgYSBzaW5nbGUgcG9pbnQKICAgICAgICAgICAgLy8gd2UnbGwganVzdCB3cml0ZSB0byBzdGRvdXQgc28gbm8gbmVlZCBmb3IgY29vcmRpbmF0ZQogICAgICAgICAgICAvLyBQTE9UNjksNCpNLDQqTgogICAgICAgICAgICBwcmludCEoInt9IiwgcGFsW2lkeF0gYXMgY2hhcik7CiAgICAgICAgfSAvLyBORVhUCiAgICAgICAgcHJpbnRsbiEoKTsgLy8gbmV3bGluZQogICAgfSAvLyBORVhUCn0KLyoKRk9STj04VE8yNDc6Rk9STT0wVE8zMTkKNDAgWD0wOlk9LS4xOlo9MzpVPShNLTE1OS41KS8xNjA6Vj0oTi0xMjcuNSkvMTYwOlc9MS9TUVIoVSpVK1YqVisxKTpVPVUqVzpWPVYqVzpJPVNHTlU6Rz0xCjUwIEU9WC1JOkY9WS1JOlA9VSpFK1YqRi1XKlo6RD1QKlAtRSpFLUYqRi1aKlorMUlGRD4wVD0tUC1TUVJEOklGVD4wWD1YK1QqVTpZPVkrVCpWOlo9Wi1UKlc6RT1YLUk6Rj1ZLUk6Rz1aOlA9MiooVSpFK1YqRi1XKkcpOlU9VS1QKkU6Vj1WLVAqRjpXPVcrUCpHOkk9LUk6R09UTzUwCjYwIElGVjwwUD0oWSsyKS9WOlY9LVYqKChJTlQoWC1VKlApK0lOVChaLVcqUClBTkQxKS8yKy4zKSsuMgo3MCBHQ09MMCwzLSg0OCpTUVJWKz8oUEFHRSs1K00gTU9ENCtOIE1PRDQqNCkvMylESVYxNgo4MCBQTE9UNjksNCpNLDQqTjpORVhULAoqLwo= https://www.rustexplorer.com/b#Zm4gbWFpbigpIHsKICAgIC8vIHJvd...
maxglute 3y ago
The dither effect looks really neat on ray trace, then I remembered thats just your average news paper photo. Still would be cool to see it in a game.
- mungoman2 3y ago
  Check out the game Return of the Obra Dinn for exactly this.
mixedmath 3y ago
This is interesting and serves as a potential "hook" for getting people interested in coding. I understand the BASIC appeal! In something like python, an analogous thing is turtle graphics. Is there something more similar (but still very basic) in python for something like this? A mini graphical language?
- simonklitj 3y ago
  Hmm, something like graphics.py maybe? https://mcsp.wartburg.edu/zelle/python/ppics2/code/graphics.py https://mcsp.wartburg.edu/zelle/python/ppics2/code/graphics....
  - mixedmath 3y ago
    Yeah, something like that. It's hard to be both expressive and useful. This is a small set of primitives around a tkinter canvas. I suppose one could expose a small set of primitives around a pygame too. I have to think hard about what exactly I would want.
miohtama 3y ago
Nice! Is there a commented source code?

194 points by neffo 3y ago

man4 3y ago

[dead]

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

kragen 3y ago
that's astounding; i would have guessed months or years
- LeoPanthera 3y ago
  BBC BASIC is surprisingly efficient for an interpreted language. It kind of had to be, running on processors that slow.
  - KerrAvon 3y ago
    Some good discussion of that on The BBC BASIC wiki entry: https://en.wikipedia.org/wiki/BBC_BASIC https://en.wikipedia.org/wiki/BBC_BASIC (paragraph beginning "Due to a number of optimizations[…]".
    - crimbles 3y ago
      Also you could swap out hot spots with assembly trivially as it had an inline assembler. And you had indirect pointers in it!
      - mavhc 3y ago
        The OP's code has REM based assembly it in to save space
        kragen 3y ago
        is that assembly or is that the dithering table
        alphabetter 3y ago
        Yes, the REM is the lookup table used in line 70. Because BBC Basic had a built-in assembler it was pretty uncommon for BBC programs to inline machine code as raw data (unlike some other computers from BITD).
        londons_explore 3y ago
        just a table of constants.
  - kragen 3y ago
    all the basics i used on processors that slow were surprisingly inefficient, even for an interpreted languages i thought they had to be, running on processors with that little memory. though later on i learned about forth, which is surprisingly efficient for an interpreted language a more likely explanation is that sophie wilson was just a better hacker than bill gates and paul allen
    - iainmerrick 3y ago
      Yeah, BBC BASIC is really good. Both the language design and the implementation. I loved it at the time, and the more I think back on it the more impressed I am. Like it had a very decent suite of floating-point routines, which if I remember right were very performant. In a 32KB ROM!
      - forinti 3y ago
        Basic was actually a 16KB ROM. MOS occupied another 16KB ROM.
        iainmerrick 3y ago
        Dang, you're right, I was misremembering.
      - crq-yml 3y ago
        Some of the improvement in BBC BASIC over Microsoft's BASIC is attributable to the larger ROM(the first Altair BASIC was just 4k), but it's also that the BBC Micro's 6502 and DRAM was clocked higher than contemporaries. It's just a faster, more refined 8-bit machine all around.
- bunabhucan 3y ago
  I recreated a mandlebrot zoom I saw in a library book in bbc basic and the last image took two weeks. I had 8 of them saved on a floppy and that would slideshow them for a 2fps "movie"
  - kragen 3y ago
    that is fucking awesome, you are a legend
PlunderBunny 3y ago
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.
- PlunderBunny 3y ago
  Update: Finished in only 2 hours 30 minutes.
  - deleted 3y ago
    [deleted]
  - tom_ 3y ago
    The Electron runs extra slowly in MODE 1 as the video system needs 100% of the RAM bandwidth to form the display. The CPU essentially ends up paused during the visible portion of each scan line, so the effective speed is probably more like 0.6 MHz.
Sharlin 3y ago
I wonder how much of that it spent just computing those square roots.
- araes 3y ago
  Does anybody happen to know what SQR algorithm BBC Basic uses? http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin7.html#printhash http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin7.html#printha... does not seem to have the actual algorithm. Intel's optimization manual has suggestions for fast versions at 15.12.3 (recommended by @James https://stackoverflow.com/a/2637823/10981777 https://stackoverflow.com/a/2637823/10981777) Don't look especially long to implement for 22-bit approximation. https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-optimization-reference-manual.html https://software.intel.com/content/www/us/en/develop/downloa... Also, what's the SQRD? Not finding that referred to anywhere.
  - Sharlin 3y ago
    SQRD is just SQR D :)
    - araes 3y ago
      Thanks. So much more of that code makes sense now. IFD, SGNU, FORN, FORM. FORM especially. So many codes now have the word FORM as a special word. What a nightmare to read though if you don't know what it's supposed to be written like. Is it a: "FORM=" or a "FOR M=" ? Is it: "S GNU:G", "SG NU:G", "SGN U:G"? SQRD totally looks like some special kind of square root implementation.
      - Sharlin 3y ago
        Yeah, early BASICs tended to let you skip the spaces, and in fact it sometimes did have a measurable effect on parsing/execution speed. And of course on file size too… Additionally, at least C64 Basic had two-character shorthands for all keywords.

kragen 3y ago

this says `goto 50` but there are no line numbers

LeoPanthera 3y ago
The robot automatically adds line numbers in increments of 10s.
EspadaV9 3y ago
If you go to the source link - https://bbcmic.ro/?t=9ctpk 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).
- PlunderBunny 3y ago
  If you're playing with this on a BBC micro emulator, the best way to get this code into the emulator is to download the disk image from the above link. The actual basic program is named "PROGRAM" on the disc. List the code by typing LIST20, (the computer will lock up if you try to list line 10). If you just want to see the result, type MODE 1 and then press return, then type *LOAD SCREEN and press return again.
- kragen 3y ago
  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
  - flohofwoe 3y ago
    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? :)

deleted 3y ago

[deleted]

ManuelKiessling 3y ago

Ok, 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”?

sp332 3y ago
W=1/SQR(U*U+V*V+1) This makes a sphere. It gets multiplied by two coordinates to make spheres at different places, U and V.
- kragen 3y ago
  i think this is incorrect, i think that's computing the z component of the initial direction vector of the ray being traced if you change the initialization of i from sgn u to 1.2 * sgn u you will get an image with the spheres a little further apart
  - Sharlin 3y ago
    Yeah, that's something of a red herring. The actual ray-sphere intersection happens on line 50: // sphere_center = (E, F, Z) E = X - I F = Y - I // solving the ray-sphere quadratic eqn... P = U * E + V * F - W * Z // discriminant D = P * P - E * E - F * F - Z * Z + 1 // if solution (ie. intersection) exists IF D > 0 // intersect_point = ray_orig + T * ray_dir // this is the closer pt, -P + SQR D is the other T = -P - SQR D
    - kragen 3y ago
      yeah, that was what i guessed it was doing, but i couldn't remember or rederive the ray-sphere intersection formula to be sure
Sharlin 3y ago
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.

ChrisArchitect 3y ago

This one was from 2021. Do enjoy the insane things ppl managed to cram into tweets to the bbcmicrobot over the years. Anyone who's followed any part of the demoscene especially the classic smaller payload demos.. 4k etc.....this kinda thing is mindblowing and totally in the same spirit.

po 3y ago

Also, don't miss the gallery site! https://www.bbcmicrobot.com https://www.bbcmicrobot.com

neffo 3y ago
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. https://mastodon.me.uk/@bbcmicrobot/111760484438439751 https://mastodon.me.uk/@bbcmicrobot/111760484438439751

jug 3y ago

This effort is truly specular!

jbverschoor 3y ago
[flagged]

rwmj 3y ago

https://www.pouet.net/prod.php?which=78045 https://www.pouet.net/prod.php?which=78045 Incredible raytraced demo in 256 bytes.

briansm 3y ago
https://www.pouet.net/prod.php?which=53871 https://www.pouet.net/prod.php?which=53871 https://www.youtube.com/watch?v=36BPql6Nl_U https://www.youtube.com/watch?v=36BPql6Nl_U Incredible raytraced demo in 128 bytes. (An underwater journey through a Menger-sponge fractal)
kragen 3y ago
last year i wrote a tetris in arm assembly https://asciinema.org/a/622461 https://asciinema.org/a/622461 and was pleased to get it down below 1024 bytes then i looked and rrrola's 4is256 https://www.pouet.net/prod.php?which=29286 https://www.pouet.net/prod.php?which=29286 is a working tetris in under 256 bytes, and it's better than mine because it has colors and scoring. i could blame a little bit of inflation on arm being 32-bit rather than 16-bit, but not 4×
- bbojan 3y ago
  You could try using Thumb instructions, they are 16 bit.
  - kragen 3y ago
    i was, but i wasn't talking about the size of the instruction word, but the size of the registers
- userbinator 3y ago
  The upper limit of instruction density on x86 is much higher than any RISC.
  - kragen 3y ago
    that hasn't been my experience with instructions i've written myself, but then again, i'm not rrrola

SillyUsername 3y ago

Can anybody provide de-obfuscated/minified source so those of us who understand the principle (tracing rays of light around a scene) can understand the maths?

kragen 3y ago
here's my attempt 10 REMĀĘĆĞ$Č*Ēĉ!ăě-ĕ'ď rem dithering table in comment above consulted by GCOL line? rem raytracer from https://bbcmic.ro/?t=9ctpk by https://mastodon.me.uk/@coprolite9000 rem deobfuscated and possibly broken by kragen javier sitaker (untested) 20 MODE 1 VDU 5 30 FOR N = 8 TO 247 : rem loop over rows (n) and columns (m) of pixels FOR M = 0 TO 319 40 X = 0 : rem three-dimensional vector Y = -.1 Z = 3 U = (M - 159.5)/160 : rem xform screen coords to direction vector V = (N - 127.5)/160 W = 1/SQR(U*U + V*V + 1) : rem normalize direction vector U = U * W V = V * W I = SGN U : rem derive coordinate of sphere center (i, i, 1)? G = 1 50 E = X - I : rem beginning of do-while loop F = Y - I P = U*E + V*F - W*Z D = P*P - E*E - F*F - Z*Z + 1 IF D <= 0 then goto 60 T = -P - SQR D IF T <= 0 then goto 60 X = X + T*U Y = Y + T*V Z = Z - T*W E = X - I F = Y - I G = Z P = 2*(U*E + V*F - W*G) U = U - P*E V = V - P*F W = W + P*G I = -I : rem if we are reflecting then check other sphere now GOTO 50 : rem end of do-while loop, we have our escape from the scene geometry rem color according to y-component of direction vector to get sky gradient rem if instead y component is negative, make a checkerboard of pieces of sky 60 IF V < 0 then P = (Y + 2)/V : V = -V*((INT(X - U*P) + INT(Z - W*P) AND 1)/2 + .3) + .2 70 GCOL 0, 3 - (48*SQR V + ?(PAGE + 5 + M MOD 4 + N MOD 4*4)/3) DIV 16 80 PLOT 69, 4*M, 4*N NEXT, i'm interested to hear what i got wrong see also https://news.ycombinator.com/item?id=39026517 https://news.ycombinator.com/item?id=39026517 and https://news.ycombinator.com/item?id=39026495 https://news.ycombinator.com/item?id=39026495

kragen 3y ago

a thing that puzzles me is how https://bbcmic.ro/?t=9ctpk https://bbcmic.ro/?t=9ctpk is only 4× faster in emulation (about 30 seconds per scan line and so on the order of 2 hours for the whole image) i'm running this on a ryzen 5 3500u at 2400 megahertz. the acorn electron which supposedly takes 8 hours and 40 minutes is a 1 megahertz 6502 when running from ram, roughly, 262144 instructions per second. at 2 ipc one core of the ryzen should be about 4800 mips. if the emulation slowdown is 10× (10 host instructions to emulate one guest instruction), which is typical for naïve interpretation, it should be about 1000× faster on this laptop as on the original hardware (possibly the basic is in rom and so it's closer to 524288 instructions per second) emulation through qemu-like dynamic code generation should cut the 10× slowdown to 3×, so it should be 3000× faster than the original hardware where did that factor of 1000 go? not the javascript engine, surely? incidentally there is a rocket-ship button underneath the output screen image labeled 'send to beebjit' which runs the program in about a second

flohofwoe 3y ago
If the emulator is entirely cycle correct for the entire system (including the video system, which is usually the most expensive to emulate, not the CPU), then the speedup on modern computers will be much less than just comparing the clock frequencies. Consider that each chip of a home computer system (CPU, 1..2 IO/timer chips, audio, video, ...) needs to do 'emulation work' for each 1 or 2 MHz clock cycle which can add up to quite a number of host computer instructions (dozens to hundreds). If each chip emulator just takes around 10..20 host system clock cycles to emulate one emulator clock cycle, then you are already looking at around 100 host system clock cycles per emulated clock cycle for the entire home computer (in reality it's probably worse). Such 'vertically sliced' emulation code is also full of conditional branches which put a heavy burden on the host CPU branch predictor. ...and that's how a theoretical 1000x speedup suddenly becomes a 10x speedup, it's not the CPU emulation (this is usually cheap) but the rest of the emulated system which can be expensive. Different emulators use all sorts of tricks and shortcuts, but usually with tradeoffs like less precise emulation, or less 'compartmentalized' code. PS: case in point this is just the top-level per-cycle function in my C64 emulator, which in turn calls per-cycle-functions in each of the chip emulators (which may each be just as much code): https://github.com/floooh/chips/blob/9a7f6d659b5d1bbf72bc8d060e5130b45e283480/systems/c64.h#L554-L745 https://github.com/floooh/chips/blob/9a7f6d659b5d1bbf72bc8d0... I'm trying to strike a balance between 'purity' (e.g. an entire emulated system can be 'plugged together' by wiring together chip emulators, just like one would build a real 8-bit computer on a breadboard), while still being fast enough to comfortably run in realtime even in browsers (https://floooh.github.io/tiny8bit/c64.html https://floooh.github.io/tiny8bit/c64.html). It's definitely possible to implement a faster cycle-correct C64 emulator with a less 'pure' architecture, but it's quite hard to do meaningful optimizations while keeping that same 'virtual breadboard' architecture. ...considering all the code that runs per cycle it's actually amazing how fast modern CPUs are :)

londons_explore 3y ago

In 398 characters, I can give it error diffusion dithering capabilities, which makes the code smaller and the output quality a bit better: https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE1%3AVDU5%3AB%3D0%5CnFORN%3D8TO247%3AFORM%3D0TO319%5CnX%3D0%3AY%3D-.1%3AZ%3D3%3AU%3D%28M-159.5%29%2F160%3AV%3D%28N-127.5%29%2F160%3AW%3D1%2FSQR%28U*U%2BV*V%2B1%29%3AU%3DU*W%3AV%3DV*W%3AI%3DSGNU%3AG%3D1%5CnE%3DX-I%3AF%3DY-I%3AP%3DU*E%2BV*F-W*Z%3AD%3DP*P-E*E-F*F-Z*Z%2B1%3AIFD%3E0T%3D-P-SQRD%3AIFT%3E0X%3DX%2BT*U%3AY%3DY%2BT*V%3AZ%3DZ-T*W%3AE%3DX-I%3AF%3DY-I%3AG%3DZ%3AP%3D2*%28U*E%2BV*F-W*G%29%3AU%3DU-P*E%3AV%3DV-P*F%3AW%3DW%2BP*G%3AI%3D-I%3AGOTO40%5CnIFV%3C0P%3D%28Y%2B2%29%2FV%3AV%3D-V*%28%28INT%28X-U*P%29%2BINT%28Z-W*P%29AND1%29%2F2%2B.3%29%2B.2%5CnB%3DB%2B3*SQRV%3AGCOL0%2C3-INTB%3AB%3DB-INTB%5CnPLOT69%2C4*M%2C4*N%3ANEXT%2C%22%7D https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE1... It would look even better with bidirectional error diffusion, but that requires reading back memory which I don't know how to do.

logicallee 3y ago
Thanks for sharing. I asked ChatGPT to analyze your code, while telling it what it does. How well do you think it did? Did it make any mistakes? https://chat.openai.com/share/6e754fa1-531d-432e-a767-8c81320dff5d https://chat.openai.com/share/6e754fa1-531d-432e-a767-8c8132...
- bmsleight_ 3y ago
  Wow - I never thought of using ChatGPT for analysing code. It reads well - but does the author agree ?
- CamperBob2 3y ago
  I just asked it to reformat the code for better readability, and it guessed it was a ray tracer. I for one welcome our new robot^H^H^H^H^Hparrot overlords. Also tried having it generate a JavaScript version, but the output doesn't look right: https://chat.openai.com/share/5d76e32b-81a1-4b4a-a808-7682a8cef6b3 https://chat.openai.com/share/5d76e32b-81a1-4b4a-a808-7682a8... I'd be inclined to suspect the lack of line numbers, as a first guess towards the problem.

anovikov 3y ago

Just curious how fast could the same thing be if someone who knows the hardware really well, wrote it in assembly.

aardvark179 3y ago
There’s a bunch of things you can do. Replacing all the square roots with a lookup table might be doable, and you could make the final drawing faster by not using the generic plot routines. You don’t have a lot of memory to play with though as you only have 32k to start with and the frame buffer will use 20k of that, so I’m not sure how good a look up table you could make for SQR.

Sharlin 3y ago

In a subthread, I got nerdsniped to figure out how this works, and for fun transcribed it ~faithfully to Rust – this one just outputs ASCII art instead of plotting pixels. You'll want to zoom out your browser as far as you can: https://www.rustexplorer.com/b#Zm4gbWFpbigpIHsKICAgIC8vIHJvdyBsb29wIOKAkyB1c2UgZmV3ZXIgcm93cyBkdWUgdG8gbm9uLXNxdWFyZSBhc3BlY3QgcmF0aW8KICAgIC8vIDMwIEZPUk49OFRPMjQ3CiAgICBmb3IgbiBpbiAoMC4uMTIwKS5yZXYoKSB7CiAgICAgICAgLy8gY29sdW1uIGxvb3AKICAgICAgICAvLyBGT1JNPTBUTzMxOQogICAgICAgIGZvciBtIGluIDAuLjMyMCB7CiAgICAgICAgICAgIC8vIGNhbWVyYSBjb29yZHMgPSByYXkgb3JpZ2luIHBvaW50CiAgICAgICAgICAgIC8vIDQwIFg9MDpZPS0uMTpaPTMKICAgICAgICAgICAgbGV0IG11dCB4ID0gMC4wOwogICAgICAgICAgICBsZXQgbXV0IHkgPSAtMC4xOwogICAgICAgICAgICBsZXQgbXV0IHogPSAzLjA7CgogICAgICAgICAgICAvLyByYXkgZGlyZWN0aW9uIHZlY3RvcgogICAgICAgICAgICAvLyBVPShNLTE1OS41KS8xNjA6Vj0oTi0xMjcuNSkvMTYwOlc9MS9TUVIoVSpVK1YqVisxKQogICAgICAgICAgICBsZXQgbXV0IHUgPSAobSBhcyBmMzIgLSAxNjAuMCkgLyAxNjAuMDsgLy8gcmF5IGRpciB4CiAgICAgICAgICAgIGxldCBtdXQgdiA9IChuIGFzIGYzMiAtIDYwLjApIC8gNjAuMDsgLy8gcmF5IGRpciB5CiAgICAgICAgICAgIGxldCBtdXQgdyA9IDEuMCAvICh1ICogdSArIHYgKiB2ICsgMS4wKS5zcXJ0KCk7CgogICAgICAgICAgICAvLyBub3JtYWxpemUgcmF5IGRpcgogICAgICAgICAgICAvLyBVPVUqVzpWPVYqVwogICAgICAgICAgICB1ICo9IHc7CiAgICAgICAgICAgIHYgKj0gdzsKCiAgICAgICAgICAgIC8vIHdoaWNoIHNwaGVyZSB3ZSB0cnkgdG8gaW50ZXJzZWN0IHNvbGVseSBkZXBlbmRzIG9uIHRoZSBzaWduIG9mIHUKICAgICAgICAgICAgLy8gST1TR05VOkc9MQogICAgICAgICAgICBsZXQgbXV0IGkgPSB1LnNpZ251bSgpOwogICAgICAgICAgICBsZXQgbXV0IGcgPSAxLjA7IC8vIHRoZSAxLjAgaXMgYWN0dWFsbHkgbmV2ZXIgdXNlZAoKICAgICAgICAgICAgLy8gc3BoZXJlIGludGVyc2VjdGlvbiBhbmQgcmVmbGVjdGlvbnMKICAgICAgICAgICAgLy8gbm8gcmVjdXJzaW9uIG5lZWRlZCBhcyB3ZSdyZSBub3Qgc3BsaXR0aW5nIHJheXMKICAgICAgICAgICAgLy8gdGhlIG9yaWdpbmFsIHNpbXBseSB1c2VzIGdvdG8gdG8ganVtcCBiYWNrIHNvIHRoaXMgbG9vcCBpcyBpbXBsaWNpdAogICAgICAgICAgICAncmVmbGVjdDogbG9vcCB7CiAgICAgICAgICAgICAgICAvLyBzcGhlcmUgY2VudGVyIGlzIGF0IChlLCBmLCB6KQogICAgICAgICAgICAgICAgLy8gNTAgRT1YLUk6Rj1ZLUkKICAgICAgICAgICAgICAgIGxldCBtdXQgZSA9IHggLSBpOwogICAgICAgICAgICAgICAgbGV0IG11dCBmID0geSAtIGk7CgogICAgICAgICAgICAgICAgLy8gc29sdmUgcmF5LXNwaGVyZSBxdWFkcmF0aWMgZXF1YXRpb24KICAgICAgICAgICAgICAgIC8vIFA9VSpFK1YqRi1XKloKICAgICAgICAgICAgICAgIGxldCBtdXQgcCA9IHUgKiBlICsgdiAqIGYgLSB3ICogejsKCiAgICAgICAgICAgICAgICAvLyBkaXNjcmltaW5hbnQKICAgICAgICAgICAgICAgIC8vIEQ9UCpQLUUqRS1GKkYtWipaKzE6SUZEPjAKICAgICAgICAgICAgICAgIGxldCBkID0gcCAqIHAgLSBlICogZSAtIGYgKiBmIC0geiAqIHogKyAxLjA7CiAgICAgICAgICAgICAgICBpZiBkID4gMC4wIHsgLy8gcmF5IGludGVyc2VjdHMgc3BoZXJlCiAgICAgICAgICAgICAgICAgICAgLy8gdHdvIHNvbHV0aW9ucywgY2hvb3NlIHRoZSBvbmUgY2xvc2VyIHRvIHRoZSBjYW1lcmEKICAgICAgICAgICAgICAgICAgICAvLyBpbnRlcnNlY3QgcG9pbnQgPSByYXlfb3JpZ2luICsgdCAqIHJheV9kaXIKICAgICAgICAgICAgICAgICAgICAvLyBUPS1QLVNRUkQKICAgICAgICAgICAgICAgICAgICBsZXQgdCA9IC1wIC0gZC5zcXJ0KCk7IAogICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgIGlmIHQgPiAwLjAgeyAvLyBpbnRlcnNlY3QgcG9pbnQgbm90IGJlaGluZCByYXkgc3RhcnQgcG9pbnQKICAgICAgICAgICAgICAgICAgICAgICAgLy8gWD1YK1QqVTpZPVkrVCpWOlo9Wi1UKlcKICAgICAgICAgICAgICAgICAgICAgICAgeCArPSB0ICogdTsgLy8KICAgICAgICAgICAgICAgICAgICAgICAgeSArPSB0ICogdjsgLy8gaW50ZXJzZWN0IHBvaW50IGNvb3JkcyA9IHJlZmxlY3RlZCByYXkgc3RhcnQKICAgICAgICAgICAgICAgICAgICAgICAgeiAtPSB0ICogdzsgLy8KCiAgICAgICAgICAgICAgICAgICAgICAgIC8vIHNwaGVyZV9ub3JtYWwgPSBpbnRlcnNlY3RfcHQgLSBjZW50ZXJfcHQKICAgICAgICAgICAgICAgICAgICAgICAgLy8gRT1YLUk6Rj1ZLUk6Rz1aCiAgICAgICAgICAgICAgICAgICAgICAgIGUgPSB4IC0gaTsKICAgICAgICAgICAgICAgICAgICAgICAgZiA9IHkgLSBpOwogICAgICAgICAgICAgICAgICAgICAgICBnID0gejsKCiAgICAgICAgICAgICAgICAgICAgICAgIC8vIHJlZmxlY3QgYWJvdXQgbm9ybWFsCiAgICAgICAgICAgICAgICAgICAgICAgIC8vIFA9MiooVSpFK1YqRi1XKkcpCiAgICAgICAgICAgICAgICAgICAgICAgIHAgPSAyLjAgKiAodSAqIGUgKyB2ICogZiAtIHcgKiBnKTsgCgogICAgICAgICAgICAgICAgICAgICAgICAvLyBuZXcgcmVmbGVjdGVkIHJheSBkaXIKICAgICAgICAgICAgICAgICAgICAgICAgLy8gVT1VLVAqRTpWPVYtUCpGOlc9VytQKkcKICAgICAgICAgICAgICAgICAgICAgICAgdSAtPSBwICogZTsKICAgICAgICAgICAgICAgICAgICAgICAgdiAtPSBwICogZjsgCiAgICAgICAgICAgICAgICAgICAgICAgIHcgKz0gcCAqIGc7CgogICAgICAgICAgICAgICAgICAgICAgICBpID0gLWk7IC8vIHRoZSBvbmx5IHNwaGVyZSB0byByZWZsZWN0IGlzIHRoZSBvdGhlciBvbmUKCiAgICAgICAgICAgICAgICAgICAgICAgIC8vIEdPVE81MAogICAgICAgICAgICAgICAgICAgICAgICBjb250aW51ZSAncmVmbGVjdDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAvLyBpbXBsaWNpdCBpbiB0aGUgb3JpZ2luYWwKICAgICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICB9CgogICAgICAgICAgICAvLyBwbGFuZSBpbnRlcnNlY3Rpb24KICAgICAgICAgICAgLy8gNjAgSUZWPDAKICAgICAgICAgICAgaWYgdiA8IDAuMCB7IC8vIGV2ZXJ5IGRvd253YXJkIHJheSBldmVudHVhbGx5IGhpdHMgdGhlIHBsYW5lCiAgICAgICAgICAgICAgICAvLyBQPShZKzIpL1YKICAgICAgICAgICAgICAgIGxldCBwID0gKHkgKyAyLjApIC8gdjsgLy8gcGxhbmUgaXMgYXQgeSA9IC0yCgogICAgICAgICAgICAgICAgLy8gd2hldGhlciBhIGxpZ2h0IG9yIGRhcmsgc3F1YXJlCiAgICAgICAgICAgICAgICAvLyAoSU5UKFgtVSpQKStJTlQoWi1XKlApQU5EMQogICAgICAgICAgICAgICAgbGV0IGNoZWNrZXIgPSAoKHggLSB1ICogcCkuZmxvb3IoKSArICgoeiAtIHcgKiBwKS5mbG9vcigpKSkgYXMgaTMyICYgMTsKICAgICAgICAgICAgICAgIC8vIGdyb3VuZCBmb2cgZWZmZWN0CiAgICAgICAgICAgICAgICAvLyBWPS1WKihjaGVja2VyLzIrLjMpKy4yCiAgICAgICAgICAgICAgICB2ID0gLXYgKiAoY2hlY2tlciBhcyBmMzIgLyAyLjAgKyAwLjMpICsgMC4yOwogICAgICAgICAgICB9CgogICAgICAgICAgICAvLyBhc2NpaSBhcnQgcGFsZXR0ZQogICAgICAgICAgICBsZXQgcGFsID0gYiIgLi06Kz0qY28jT0IlQFciOwogICAgICAgICAgICAvLyBuPTQgaW4gdGhlIG9yaWdpbmFsCiAgICAgICAgICAgIGxldCBuID0gcGFsLmxlbigpOwoKICAgICAgICAgICAgLy8gdmFsdWUgb2YgdiBpcyB1c2VkIGVpdGhlciBhcyBza3kgZ3JhZGllbnQgb3IgZ3JvdW5kIGNvbG9yCiAgICAgICAgICAgIC8vIEdDT0wwLDMtKDQ4KlNRUlYrPyhQQUdFKzUrTSBNT0Q0K04gTU9ENCo0KS8zKURJVjE2CiAgICAgICAgICAgIGxldCBpZHggPSBuIC0gMSAtIChuIGFzIGYzMiAqIHYuc3FydCgpIC8qICsgZGl0aGVyICovKSBhcyB1c2l6ZTsKCiAgICAgICAgICAgIC8vIHBsb3QgYSBzaW5nbGUgcG9pbnQKICAgICAgICAgICAgLy8gd2UnbGwganVzdCB3cml0ZSB0byBzdGRvdXQgc28gbm8gbmVlZCBmb3IgY29vcmRpbmF0ZQogICAgICAgICAgICAvLyBQTE9UNjksNCpNLDQqTgogICAgICAgICAgICBwcmludCEoInt9IiwgcGFsW2lkeF0gYXMgY2hhcik7CiAgICAgICAgfSAvLyBORVhUCiAgICAgICAgcHJpbnRsbiEoKTsgLy8gbmV3bGluZQogICAgfSAvLyBORVhUCn0KLyoKRk9STj04VE8yNDc6Rk9STT0wVE8zMTkKNDAgWD0wOlk9LS4xOlo9MzpVPShNLTE1OS41KS8xNjA6Vj0oTi0xMjcuNSkvMTYwOlc9MS9TUVIoVSpVK1YqVisxKTpVPVUqVzpWPVYqVzpJPVNHTlU6Rz0xCjUwIEU9WC1JOkY9WS1JOlA9VSpFK1YqRi1XKlo6RD1QKlAtRSpFLUYqRi1aKlorMUlGRD4wVD0tUC1TUVJEOklGVD4wWD1YK1QqVTpZPVkrVCpWOlo9Wi1UKlc6RT1YLUk6Rj1ZLUk6Rz1aOlA9MiooVSpFK1YqRi1XKkcpOlU9VS1QKkU6Vj1WLVAqRjpXPVcrUCpHOkk9LUk6R09UTzUwCjYwIElGVjwwUD0oWSsyKS9WOlY9LVYqKChJTlQoWC1VKlApK0lOVChaLVcqUClBTkQxKS8yKy4zKSsuMgo3MCBHQ09MMCwzLSg0OCpTUVJWKz8oUEFHRSs1K00gTU9ENCtOIE1PRDQqNCkvMylESVYxNgo4MCBQTE9UNjksNCpNLDQqTjpORVhULAoqLwo= https://www.rustexplorer.com/b#Zm4gbWFpbigpIHsKICAgIC8vIHJvd...

maxglute 3y ago

The dither effect looks really neat on ray trace, then I remembered thats just your average news paper photo. Still would be cool to see it in a game.

mungoman2 3y ago
Check out the game Return of the Obra Dinn for exactly this.

mixedmath 3y ago

This is interesting and serves as a potential "hook" for getting people interested in coding. I understand the BASIC appeal! In something like python, an analogous thing is turtle graphics. Is there something more similar (but still very basic) in python for something like this? A mini graphical language?

simonklitj 3y ago
Hmm, something like graphics.py maybe? https://mcsp.wartburg.edu/zelle/python/ppics2/code/graphics.py https://mcsp.wartburg.edu/zelle/python/ppics2/code/graphics....
- mixedmath 3y ago
  Yeah, something like that. It's hard to be both expressive and useful. This is a small set of primitives around a tkinter canvas. I suppose one could expose a small set of primitives around a pygame too. I have to think hard about what exactly I would want.

miohtama 3y ago

Nice! Is there a commented source code?