3 ms·
I was pondering on that solution as well, not entirely sure how cache would behave but in 91 memory was relatively fast compared to CPU so lookup tables were us
by whizzter 6y ago
I was pondering on that solution as well, not entirely sure how cache would behave but in 91 memory was relatively fast compared to CPU so lookup tables were useful still (my thinking is that perspective could be calculated per row if rendering per row but if one would be using lookup tables for that division it wouldn't matter much by flipping to vertical), also if they were running modeX then doing vertical rendering would've been a benefit.
modeX memory layout has a write-enable bit for every 4th (or was it 8th?)column but the addresses was the same so you often would want to write every 4th pixel if doing something "exact" and then change the IO registers so it'd be every 4th again but offset by one, then repeating for offset 2 and 3 and then be done. Unless you were doing flat-shading where this write-enabling could be useful for writing 16 pixels in one 32bit word write with 4 writes enabled (this could also be useful for doing a half-resolution rendering by having 2 offsets enabled and then doing every other column).
(I really loved writing software-rendering code back in those days, glad to be getting much of that power back with shaders these days)
- s-macke 6y agoDon't forget, that you have to divide by the z-coordinate and this was also very expensive. With the height field you have to compute one time 1/z or perform a table lookup and then just multiply. You have to test and optimize both variants to be really sure.
- whizzter 6y agoFrankly back in those days even multiply was kinda expensive, i fully expect either of the methods directions to use a combined lookup table for both the perspective divide AND multiplication.