Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BBC BASIC raytracer in 432 characters

mastodon.me.uk

Post reply on HN
Print view View original

81–90 of 96 posts

Re: BBC BASIC raytracer in 432 characters

#81

Post by aardvark179 »

anovikov wrote: post #49

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

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.

Re: BBC BASIC raytracer in 432 characters

#83

Post by mixedmath »

simonklitj wrote: post #68
mixedmath wrote: post #67

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?

Hmm, something like graphics.py maybe? https://mcsp.wartburg.edu/zelle/python/ppics2/code/graphics....

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.

Re: BBC BASIC raytracer in 432 characters

#84

Post by CamperBob2 »

logicallee wrote: post #69
londons_explore wrote: post #46

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... It would look even better with bidirectional error diffusion, but that requires reading back memory which I don't know how to do.

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

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-7682a8... I'd be inclined to suspect the lack of line numbers, as a first guess towards the problem.

Re: BBC BASIC raytracer in 432 characters

#85

Post by iainmerrick »

forinti wrote: post #66
iainmerrick wrote: post #39

Earlier quoted context omitted.

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!

Basic was actually a 16KB ROM. MOS occupied another 16KB ROM.

Dang, you're right, I was misremembering.

Re: BBC BASIC raytracer in 432 characters

#86

Post by wang_li »

flohofwoe wrote: post #30
kragen wrote: post #19

Earlier quoted context omitted.

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…

How do you speculate GOTO works if the tokenized program doesn’t have line numbers? Or if I write

     5 REM MY COOL PROGRAM
    10 PRINT “HELLO” 
    20 GOTO 10
Then later I write

    10 PRINT “DIE BART DIE”
How does it know to replace the right line?

Re: BBC BASIC raytracer in 432 characters

#87

Post by kragen »

wang_li wrote: post #86
flohofwoe wrote: post #30

Earlier quoted context omitted.

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…

How do you speculate GOTO works if the tokenized program doesn’t have line numbers? Or if I write 5 REM MY COOL PROGRAM 10 PRINT “HELLO” 20 GOTO 10 Then later I write 10 PRINT “DIE BART DIE” How does it know to replace the right line?

i don't think that flohofwoe was claiming the line numbers weren't stored, just that the textual representation with line numbers maybe isn't the correct measure

Re: BBC BASIC raytracer in 432 characters

#88

Post by flohofwoe »

wang_li wrote: post #86
flohofwoe wrote: post #30

Earlier quoted context omitted.

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…

How do you speculate GOTO works if the tokenized program doesn’t have line numbers? Or if I write 5 REM MY COOL PROGRAM 10 PRINT “HELLO” 20 GOTO 10 Then later I write 10 PRINT “DIE BART DIE” How does it know to replace the right line?

The line number is stored in the program, just not as text. It's preparsed into a (usually 16-bit) integer as part of the 'tokenization' of the input line buffer.

Re: BBC BASIC raytracer in 432 characters

#89

Post by rwmj »

userbinator wrote: post #64
kragen wrote: post #38

Earlier quoted context omitted.

last year i wrote a tetris in arm assembly 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 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×

The upper limit of instruction density on x86 is much higher than any RISC.

Particularly in the case of this x86 ray tracer, because the core of it is written using the stack-based x87 floating point instructions.

Re: BBC BASIC raytracer in 432 characters

#90

Post by londons_explore »

logicallee wrote: post #69
londons_explore wrote: post #46

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... It would look even better with bidirectional error diffusion, but that requires reading back memory which I don't know how to do.

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

50% right... 50% trash...

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

Post reply on HN