Send a command to the visual display unit to turn off the flashing cursor.
> B=0: Initializes variable B to 0. This variable will be used for brightness calculations.
B is used to propagate quantization error from one pixel to the next - specifically, if we wanted one pixel to be orange, but the closest color we could use was red, then B contains "more yellow needed". In the next pixel, this will be added in to give this pixel more chance of being yellow.
> recursion
There is no recursion here. It's an infinite loop that exits when the raytraced ray fails to hit the floor or a sphere.
> The 4M and 4N are for scaling the coordinates to the screen resolution.
No - this is because early computers didn't have enough memory to store the whole screen image. Therefore there were 'device pixels' and 'logical pixels'. In this mode, each row of pixels is output 4 times into the screen, making each pixel into a group of 16 pixels (4x4).
Drawing commands in BBC basic are done in device pixels, but there is no point in figuring out a color for every device pixel if you can only store 1 in 16 of them..
Didn't check the inner loop since I didn't write that code - but I suspect it has similar accuracy issues.
That's not bad at all for ChatGPT. I guess it will be a long time before a computer can really accurately describe what a complicated uncommented algorithm is doing.
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.
Hah! The code doesn't work because chatGPT missed a very obscure trick...
At the start of the code is a comment "REM xxxxxx". It stripped this comment out thinking it was junk.
But actually, the code later uses the "PAGE" command to directly read RAM to get the contents of this comment, which it then uses as a lookup table for dithering.
Actually I did that (note that the REM is missing from my prompt.) It didn't look like a hack for embedding binary data for subsequent PEEK or CALL statements, which was common on the 8-bit Apple I grew up using, so I assumed it was just garbage and left it out.
When I fed it your updated version that didn't include the REM, farther down the page, it still didn't quite work. Although I can tell it's not too badly broken. There's some visual structure in the output, just not the expected image.
> VDU5: Sets the output to graphics.
Send a command to the visual display unit to turn off the flashing cursor.
> B=0: Initializes variable B to 0. This variable will be used for brightness calculations.
B is used to propagate quantization error from one pixel to the next - specifically, if we wanted one pixel to be orange, but the closest color we could use was red, then B contains "more yellow needed". In the next pixel, this will be added in to give this pixel more chance of being yellow.
> recursion
There is no recursion here. It's an infinite loop that exits when the raytraced ray fails to hit the floor or a sphere.
> The 4M and 4N are for scaling the coordinates to the screen resolution.
No - this is because early computers didn't have enough memory to store the whole screen image. Therefore there were 'device pixels' and 'logical pixels'. In this mode, each row of pixels is output 4 times into the screen, making each pixel into a group of 16 pixels (4x4).
Drawing commands in BBC basic are done in device pixels, but there is no point in figuring out a color for every device pixel if you can only store 1 in 16 of them..
Didn't check the inner loop since I didn't write that code - but I suspect it has similar accuracy issues.