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.
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.
May I suggest coding a quick (to code) slow (to run) and dirty 16 bit rotate in C to confirm?
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.
Can you split that model into two parts, which may fit the algorithm?
It would complicate rotation but worthy of consideration. I’ll add that to my thought pile too.
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.
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?
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.