2026-09-14 01:01:03 <xentrac     > no worries; it's reasonable to ask them for advice about which one is better too, but I can't recommend it as highly
2026-09-14 13:39:54 <veltas      > Have been trying out writing performant line drawing in Z80 for ZX Spectrum
2026-09-14 13:40:03 <veltas      > Is kind of a fun problem for a number of reasons
2026-09-14 13:40:48 <veltas      > Firstly a pixel is really a bitmask plus address, because the display is a bitmap.  So there's 3 bytes to represent each pixel for instant access (or 2 bytes in coordinate form)
2026-09-14 13:41:33 <xentrac     > 3 bytes: 2 bytes of memory address and 1 byte of bitmask?
2026-09-14 13:41:38 <veltas      > Yep
2026-09-14 13:42:00 <xentrac     > but I suppose that if the line is mostly horizontal you can set several pixels at once
2026-09-14 13:42:13 <veltas      > That's right
2026-09-14 13:42:57 <veltas      > Currently I've been working on routines for moving to the next pixel mask/addr in each direction, because there are super quick and slower cases
2026-09-14 13:43:40 <veltas      > If I assume the pixels accessed are essentially random then the performance of handling the common cases where e.g. an 8x8 cell isn't crossed is better than e.g. a lookup table would be, i.e. quite fast
2026-09-14 13:44:29 <veltas      > What's also nice is that if these routines are used from bresenham's then if the line is mostly vertical or mostly horizontal then you are only calling one of these routines at a time
2026-09-14 13:44:59 <veltas      > But if they're mostly diagonal I think it gets a bit worse than a lookup table (albeit in less RAM)
2026-09-14 13:45:56 <veltas      > I say bresenham's because that can be tweaked simply to just call e.g. "next_pixel_right, next_pixel_up" etc as needed
2026-09-14 13:47:04 <veltas      > All this needs to double-return (or however deep it would need to be) and finish the line early if the edge of the screen is crossed, although it's not clear yet if it's easier to catch this from the high-level algorithm
2026-09-14 13:47:54 <veltas      > I'm sure there's (1) good code to do this already, and (2) an LLM could write this quickly and well; however this is just a fun exercise for me
2026-09-14 13:48:15 <veltas      > I'm enjoying the problem-solving part anyway
2026-09-14 13:48:54 <veltas      > The second difficulty is the horizontal rows of the ZX spectrum have an extremely strange layout, they're not in a linear order
2026-09-14 13:49:38 <veltas      > Good article on this here: http://www.breakintoprogram.co.uk/hardware/computers/zx-spectrum/screen-memory-layout
2026-09-14 13:51:11 <veltas      > Basically in the simple case, if I want to access the next or prev row's address I can get away with INC H or DEC H (where H is high byte for pixel address)... unless it carries into bit 3
2026-09-14 13:52:05 <veltas      > So I'm saving the initial value in A and xor'ing and checking bit 3 to see if it changed, RET Z
2026-09-14 13:53:18 <veltas      > Simpler is the column where I shift left or right, and then RET NC or INC/DEC the address's low byte
2026-09-14 13:54:05 <veltas      > I want to integrate this into Forth but the hot code will all be assembly, certainly line-drawing should be all be written in assembly.
2026-09-14 13:59:11 <veltas      > I'm not 100% sure what I'll do with it but I might do some 3D line-based graphics maybe
2026-09-14 13:59:40 <veltas      > The optimised line drawing can be added to zenv as an optional build extra
2026-09-14 14:02:49 <xentrac     > run-length-slice line drawing might be better suited to setting several pixels at once than Bresenham
2026-09-14 14:07:47 <veltas      > That's interesting will look into that
2026-09-14 14:08:08 <veltas      > Yeah that seems like it would be much faster for mostly-horizontal lines anyway
2026-09-14 14:20:22 <veltas      > If I'm doing 3D I should consider double buffering... as I could store in a simpler row order in the drawing buffer
2026-09-14 20:52:50 <veltas      > 
ACTION listening to https://www.youtube.com/watch?v=Isic2Z2e2xs

2026-09-14 21:58:10 <veltas      > Damn 49 minutes, way too short