gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Graphics > Need Help With Fixed Point Affine Texture Mapping

#65493 - keldon - Tue Jan 03, 2006 5:48 pm

[Images not permitted - Click here to view it]
The image shows an issue I am getting with my fixed point texture mapping algo. It displays fine using floating points and all I have really done is replaced the floats with fixed point numbers.

The red line and the 3 coloured dots were added for reference points. The cyan dots represents the 2 3-point polygons used to render the square. The yellow dot is just a marker for where I am getting incorrect results.

The same horizontal delta is used across the each 3 point polygon. It appears that the fixed point delta in this case is a little lower than it should be due to precision.

I am currently using 16:16 fixed point for su deltas despite the fact that su is in the range of 0 to 1. Could the be the very reason? If so then should I use 1:31 fixed point for su deltas? And how would I go about multiplying 2 fixed point numbers with different points?

My fixed point conversion methods:
Code:
inline int ftoi ( float f ){
   return (int)((float)(1 << 16) * f);
}

inline int itoi ( int i ){
   return i << 16;
}

inline int fpmul ( int a, int b ){
   return (int)(((long long)a * (long long)b) >> 16);
}

inline int rdiv ( int b ) {
   return ((1 << 31) /b)<< 1;
}

inline int fpdiv ( int a, int b ) {
    return (int) (((long long)a << 16) / (long long)b);
}


inline float itof ( int i ) {
   return (float)i / (float)(1 <<16);
}

#65494 - keldon - Tue Jan 03, 2006 5:54 pm

I am thinking that maybe I could create a typedef type for 1:31 and 16:16 and overload those fixed point number methods to be able to have say:

inline int fpdiv ( fp31 a, fp16 b );

#65503 - kusma - Tue Jan 03, 2006 6:49 pm

it looks like you change dudx and dvdx (the horisontal u and v deltas) in the middle of your polygon. why? they stay stay constant for the entire polygon...

#65505 - keldon - Tue Jan 03, 2006 7:08 pm

integer polygon code

It does use a constant delta. But what I now think is happening is that I am starting off with different uv coordinates by the time I reach the left cyan dot in the polygon for the bottom.

The poly routine works by drawing the lines of the polygon whilst marking the su on the left side of the polygon at each line. What I think is happening here is that in the loop for ( int i = 0; i < npoints -1; i ++ ) { where I am setting the left uv of each line; I think I am completely losing accuracy.

Then in a second loop it takes the left su and applies the delta to it. I am positive it is just down to the accuracy lost after when drawing the lines.

Also to note, dx are actually 16:16 fixed point.