Thanks to @markmoxon.bsky.social I * think * I understand why my backface culling routine is not quite working. I'd oversimplified my routine due to misunderstanding how the face normals worked. Shouldn't take long to fix. Job for tomorrow.
Replies
Ooookay, my understanding was correct, and my code was using the normals correctly. However, the Cobra model data is slightly too big for my 8-bit rotate code, thus causing the odd glitch with hidden faces being calculated incorrectly sometimes. Another overflow type bug. Should fix that really.
sep 2, 2025, 2:36 pm • 13 0 • view
And it appears that this is not a new bug I've introduced. It is a limitation in the rotation algorithms of the pure assembler spinning cube demos I've done in the past. I'm going to park that up and accept the limitation. May add a slower 16 bit rotate if required.
sep 2, 2025, 4:19 pm • 9 0 • view
May I suggest coding a quick (to code) slow (to run) and dirty 16 bit rotate in C to confirm?
sep 2, 2025, 4:32 pm • 1 0 • view
I already did that - the original using float worked. And if I use 16-bit maths for the rotate, rather than 8, that works. 8-bit rotate is convenient and very fast as it uses the Z80N MUL instruction in the trig.
sep 2, 2025, 4:36 pm • 0 0 • view
Can you split that model into two parts, which may fit the algorithm?
sep 2, 2025, 9:06 pm • 1 0 • view
It would complicate rotation but worthy of consideration. I’ll add that to my thought pile too.
sep 2, 2025, 9:13 pm • 1 0 • view
Proved this - I can rotate two of the axis and everything is fine. As soon as I rotate all three (as per my demo), an overflow occurs and the now embiggened cube (160 rather than 80 units along each side) glitches.
sep 2, 2025, 2:39 pm • 4 0 • view
Hear me out on this one weird idea... instead of going 16 bits to handle 3 axes, rotate two axes per frame only (say, xy), accumulating the third axis for the next frame, then rotate two again (say, yz) on the next frame and so on?
sep 2, 2025, 5:21 pm • 1 0 • view
My gut feeling is that it won't work, as the effects are accumulative, but I'll add it to my thought pile on that.
sep 2, 2025, 5:25 pm • 2 0 • view
In my implementation I think I just used the winding method - no normals calculated. From memory it was quite efficient as you have to visit the points anyway...
sep 1, 2025, 10:15 pm • 3 0 • view
Yeah, I normally use the winding method. The Elite data is stored differently with face normals. It's more an exercise in bloody mindedness at the moment. And recalling all the relevant vector maths from years ago like dot products.
sep 1, 2025, 10:18 pm • 3 0 • view
It's all very well being a computer whiz - but for 3D graphics, avoiding maths isn't really an option...
sep 2, 2025, 7:57 am • 3 0 • view
Hahaha! Indeed.
sep 2, 2025, 7:59 am • 0 0 • view