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.

OffTopic > reason for wierd texture warp in Driv3r

#80635 - Ant6n - Mon Apr 24, 2006 7:17 am

did anybody ever figure out the reason for those weird texture warps in the second driver gba game?
It seems that they use affine texture mapping, but when an object is partially offscreen the effects become totally wierd - too wierd even for linear mapping. I'd post a pig but i dont have webspace right now...

Anton

#80641 - tepples - Mon Apr 24, 2006 12:39 pm

Sounds like bad clipping of texture coordinates.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#80663 - DekuTree64 - Mon Apr 24, 2006 4:54 pm

Yeah, I've seen that before too. I think it happens when a twisted quad is clipped.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#81534 - Ant6n - Sat Apr 29, 2006 8:31 pm

o, i think i figured it.
apparently driv3r renders polygons with multiple sides, not just triangles. but apparently it interpolates between two points of the edges that are the beginning and end of each scanline, and then interpolates between those points to get the scanline. That'd explain it.
The irony is that after 10 minutes playing the wierd textures arent the thing that makes you kind of dislike the game (i.e. you get used to it), but the fad story, which is badly told and real plump, the wierd handling (sliding at 5 mph?) and that all the time you bounce like a rubber ball of things that pop out of noewhere (i.e. cars)

#81566 - keldon - Sun Apr 30, 2006 2:29 am

If it was affine mapping then warping is inevitable. The method you described introduces serious accuracy problems when floating points are not used. I had a similar problem when I converted my floating point texture mapper to a fixed point texture mapper that interpolated with the textures delta and the point from one side.

The problem you get when using fixed point is that your delta is slightly innacurate, plus the u/v values your are interpolating with from the edge. Combined they can quite easily make your texture warp.

Why interpolate between two points on each line to calculate the texture's uv. The delta across any flat shape will be constant. Instead they would - if using this method - interpolate with an edge on one side, along with the shapes delta.

#81579 - Ant6n - Sun Apr 30, 2006 7:32 am

"The delta across any flat shape will be constant"

that is only true for triangles - because they have three points with three u,v coordinates, you can somehow stretch your texture across it... so i, too, would think that this would be the best approach with flat texturing.
but if you want to render an arbitrary convex polygon, i.e.
Code:

 e  ___ a
   /    |
  /     | b
d \    /
    \ / c

you would just walk along the left side and the right side of the polygon, then interpolate between to points (i.e. a and b, as well as e and d) and then interpolate between the edges for each scanline. I think they do it in this way because if you dont use triangles, you cant just use one wrapping...
mmmh... wierd, still, why not split it up in triangles and use constant delta values for each - maybe it produced wierder warps (like on the PS1)
btw, if your delta values are too inaccurate with fixpoint, then use different radix point. I.e., for coordinates use q16, but for du and dv use q24

#81583 - keldon - Sun Apr 30, 2006 10:10 am

Yes, I was thinking of implementing radix but just haven't got around to it.

If you are rendering a polygon such that it fits perfectly on the polygon then you should divide it into smaller triangles. If you interpolate between the edges in the way specified then you will get a screwed up texture - but I haven't seen this warping so I couldn't tell what exactly is wrong, I will have to try it out.

If you had a constant delta on your polygon - like how I said - the complete texture will not be drawn. I take it they are not drawing simple polygons, such that there exists no line in any direction such that no more than two edges of the polygon will touch - otherwise that method will fail.

#81602 - keldon - Sun Apr 30, 2006 3:10 pm

Just tried it out - for obvious reasons - and it just looks like affine texturing. Man that intro is long.

Looks like:
- affine texture mapping
- haven't seen any difficult polygons [only put it on for a few minutes]
- calculates uv using (a) delta + (b) uv value at beginning of a line. They have one of the same warping effects I get due to the innacuracy

Okay, i'll get into a car and look around the town, I'll stop being lazy. Looks like the same routine I have in my texture mapper. I'll post the code if you want, in fact>>>
My thread on it happening to me. It is an affine method, but the main problem is with the fixed point accuracy - you don't get that odd effect when it is floating point. Mine does not suffer to the full effect as driv3r, but one of its characteristics appear.

p.s. I must have been tired talking about the constant deltas across the entire shape.

#81627 - Ant6n - Sun Apr 30, 2006 6:27 pm

[Images not permitted - Click here to view it]
you see it doesnt use triangles, because otherwise there would be some artifact diagonally across. and then area in the middle, where its a rectangle, there is no obvious artifact - except that its just flat mappin.
the top and bottom, with the curves, implie that they interpolate across each scanline - otherwise they wouldnt get the curve

#81642 - keldon - Sun Apr 30, 2006 8:55 pm

Yes true. That horizontal line looked angled when I looked at it, so I thought it was divided [weirdly].

I guess the problem it gets is with the nearplane clipping giving the correct Z value at the bottom point of the texture, and the other warping is just due to it using the method you spoke of.