neilobremski
Experienced Member
Since the first part I blogged a few weeks ago, I've written the method QTEX() [SUP][1][/SUP] which maps an 8x8x1 (monochrome) texture onto a quadrilateral (four vertices). This uses fixed point for all coordinates and deltas so there are rounding errors, especially in the inner loop when drawing a scan line because I use a single byte per U/V delta. In fact, here's an image which demonstrates the problem:
No matter how I adjust the U/V coordinates of each vertex, the last column of the enlarged heart is always a single pixel. It's not complicated to figure out why with a little math. The width of these is 33 pixels which means the distance used for calculating deltas is 32 or 0x20. Let's say U goes from 00 to FF, which is the bottom right heart in the image, with the top 3 bits used for the whole part of U (0-7). Now QTEX does a 16-bit divide per scanline to calculate the deltas but even still this is 0xFFFF / 0x20 = 0x07FF and it is truncated to just 0x07. Multiplying 0x07 by 20 we get 0xE0 for that last column which is U=7, but if you subtract 7 from that for the second to last scanline you get 0xD9 which is U=6. Boo!
Why doesn't the problem happen vertically? I step each edge with 16-bit word values which reduces the errors but does not completely eliminate them. Check out the left over pixel off the bottom right shore of the 'C' in this screenshot:
These are known issues and acceptable losses because this texture mapping is going to be used for cubes with numbered faces that don't get that large.
All in all I am happy with the results. At some point I'll get back to explaining how this all works and how it could be made more accurate but for now you'll just have to trust me and wait!
Footnotes:
[SUP][1][/SUP]. See the attached DEBUG script. View attachment 38263
No matter how I adjust the U/V coordinates of each vertex, the last column of the enlarged heart is always a single pixel. It's not complicated to figure out why with a little math. The width of these is 33 pixels which means the distance used for calculating deltas is 32 or 0x20. Let's say U goes from 00 to FF, which is the bottom right heart in the image, with the top 3 bits used for the whole part of U (0-7). Now QTEX does a 16-bit divide per scanline to calculate the deltas but even still this is 0xFFFF / 0x20 = 0x07FF and it is truncated to just 0x07. Multiplying 0x07 by 20 we get 0xE0 for that last column which is U=7, but if you subtract 7 from that for the second to last scanline you get 0xD9 which is U=6. Boo!
Why doesn't the problem happen vertically? I step each edge with 16-bit word values which reduces the errors but does not completely eliminate them. Check out the left over pixel off the bottom right shore of the 'C' in this screenshot:
These are known issues and acceptable losses because this texture mapping is going to be used for cubes with numbered faces that don't get that large.
All in all I am happy with the results. At some point I'll get back to explaining how this all works and how it could be made more accurate but for now you'll just have to trust me and wait!
Footnotes:
[SUP][1][/SUP]. See the attached DEBUG script. View attachment 38263