4x ICC modes - viewers

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Andrew Davie

Although it seems a while since the last update, a lot has been going on behind the scenes. I spent some amount of effort moving towards matrix math because "that's the right way to do 3D math". Well, that was a poor choice. Yes, it simplifies code - but adds horrendous overhead compared to fine-tuned by-hand coding. The reason is, many of the matrix operations consist of matrices with lots of zeroes - because such elements are unimportant. But to do a full matrix 4x4 multiply by 4x4 you end up doing a LOT of floating point calculations. At one point I believe I counted 192 floating point calculations per vertex. Yeah, of course I'm not super efficient in my code yet, but it was clear that the manual way I was doing it originally was going to be way faster.

So, I reverted.

There have been a lot of behind-the-scenes work done in world-view, object-view, screen-view translations rotations and projections done - not quite ready for the big time yet. I got it working in matrices but as I said - way too slow. I will get that sorted soon.

Other things I've fixed is making sure everyting works and auto-adjusts aspect ratios and various buffer sizes based on the iCC mode used (iCC = interleaved chronocolour). So now I basically need to set a flag to one of ICC0, ICC1, ICC2, ICC3 and it will display in the correct mode.

ICC0 = (original chronocolour) = 160 x 64
ICC1 = 160 x 192
ICC2 = 160 x 96
ICC3 = 160 x 64

There are four binaries attached - obviously named - running the ship viewer in the relevant mode.

Another thing I changed is the fine-tuning on the throttle for drawing. It may still black-screen crash on hardware - but as yet I've not seen any issues running on Gopher.  I pre-count the number of "draw operations", where that means either a pixel write or a "block" write (a block being a group of 8 pixels of the same colour). Essentially the current settings/throttle is to do up to 11000 of these operation per overblank period. the code is highly optimised. When there's not enough time (when things are close, for example) the frame rate may drop - although it's not really noticeable in these demos.

I have the colour "palette" cycling in these binaries - about every second or so.

As before, up/down = move closer/further.
button = switch to next spaceship



Andrew Davie

Update: I've seen a few overtimes; will reduce my tolerance. No need to report, TY.