Tales of Eternia world map graphics

[unknownbrackets]

In the World Map, outside the very first town, it's very clear that the sky is drawn incorrectly. Pretty sure it's exactly as it appears, a depth testing issue.

It uses a >= test. Coord type is float, but it's throughmode, so I'm a bit confused about how it's handled. It might be -8192. Seems like depth write is disabled.

When drawing the foreground, it often uses u16 coords and obviously, not throughmode.

I'm not confident with my manual vertex decoding. Depth test is enabled and also >=. Depth write is not disabled, but I don't see any depth values showing up in the ge debugger.

It's hard to tell if softgpu has the same issue or not since most of the polygons are missing. But it may.

Anyway, the foreground writes happen with z values that are initially read from the vertex as e.g. -0.11 and ultimately transformed to values such as -3540. I'm not sure but that sounds less than entirely correct. The min/max z is 0x0064 - 0xc350.

I'm wondering if depth values are possibly always handled as u16s? Although, I don't know how that interacts with float coords in non-throughmode.

I actually suspect this is shared by other games. It's probably more of a problem here since through and non-through are mixed, although I don't really know.

-[Unknown]

[unknownbrackets]

I'm trying to test this, but I'm not sure I'm doing it right. Anyway, negative z values seem to be clamped to 0, at least in throughmode.

-[Unknown]

[hrydgard]

Yes, I believe depth values in through mode are always handled as unsigned - aren't we doing that already?

[unknownbrackets]

Right, not sure if it's clamped though. But anyway, I'm not sure how it interacts with non-throughmode being drawn.

Basically the game draws non-through mode graphics (all the 3d scenery and mountains and such), and then does the sky only in throughmode.

-[Unknown]

[hrydgard]

Well at the end of the day it's just pixels being rendered into the color and depth buffers. Through mode can really be seen as just a fixed transform matrix, plus some quirks (treat input Z as unsigned, as opposed to X and Y which are signed).

[unknownbrackets]

Sure. Let me put it another way.

Let's say in non-throughmode the game stores -3000. This turns into 0xF448 in the buffer (since it seems to be stored as a 16-bit number, let's just say anyway.) Everything is fine, and this compares < -2000 and > -4000.

Later, it switches to throughmode for the sky. It doesn't clear the depth buffer, so it still has 0xF448 in it. Now that value represents 62536 (throughmode is unsigned.) The game uses -4000 which is clamped to 0, and says "draw if >=".

I'm not 100% sure this is happening but it's what I think is happening after a bit more thought.

-[Unknown]

[hrydgard]

Hm, I don't think throughmode or not affects the interpretation of the bits in the depth buffer as far as the compare is concerned, and depth buffers are always unsigned.

Non-through mode sending -3000 as Z will probably not result in 0xF448 - or have you checked?

[unknownbrackets]

I can't get non-through mode to draw pixels, so no, I've not checked. I'm doing something wrong with the matrixes or the coordinates or the init or something.

We seem to treat it as signed in non-throughmode though, no?

https://gist.github.com/unknownbrackets/7530598

I removed where I was trying to set the matrices (I tried ortho and copying stuff from reflection.)

-[Unknown]

[unknownbrackets]

I got everything but float working. It's weird though. Makes me think my vertices are wrong, but, can't see what it is...

I'm using identity matrices (see above code), I'm not sure if that affects this. Pretty sure it does.

u8, non-through (seems to be treated as signed, but still weird):
0 <= z <= 127 -> 0x7fff - (z * 0x100)
128 <= z <= 255 -> 0xffff - ((z - 128) * 0x100)

u16, non-through (seems similar to u8 non-through):
0 <= z <= 0x7fff -> 0x7fff - z
0x8000 <= z <= 0xffff -> 0xffff - (z - 0x8000)

float, non-through:
dunno, can't get it to draw...

u8, though:
dunno, can't get it to draw...

u16, through:
0 <= z <= 0xffff -> z

float, through:
0.0 <= z <= 65535.0 -> z

Anyway, relevant to this, u16 is definitely treated differently in through and non-through mode, obviously they are transformed... Also, recent fixes seem to indicate softgpu does have this problem as well.

-[Unknown]

[unknownbrackets]

So anyway, -8192 is being translated to 0.875013f, or I guess basically 57343.976955f. It should only be drawn in the areas the mountains aren't, with a >= test, so supposedly the mountains are < 0.875013f.

Just to recap: the sky is drawn in throughmode as a float -8192.0f. We currently do the following to it:

(float)((u16)(s32)-8192.0f) * (1.0f / 65535.0f) -> ((u16)-8192) / 65535.0f -> 57344 / 65535.0f

The mountains, which it ought to be drawn underneath, are drawn with s16 positions in transform mode. Their raw values look like e.g. 0xf2ab, 0xf334 but these transform to values in the range of 1400 - 1670.

If I clamp the z to zero, rather than wrapping, it looks great... but I don't really think that's the correct thing here. Although no idea if minz/maxz/other settings affect that...

-[Unknown]

[unknownbrackets]

@hrydgard based on my tests, not sure if they're correct though, depth clamps in throughmode.

This is what I get for float positions in throughmode:
-1: DEPTH= 0000 0000 0000 0000
0: DEPTH= 0000 0000 0000 0000
1: DEPTH= 0001 0001 0001 0001
2: DEPTH= 0002 0002 0002 0002
65534: DEPTH= fffe fffe fffe fffe
65535: DEPTH= ffff ffff ffff ffff
65536: DEPTH= ffff ffff ffff ffff

However, there seems to be more to it than that since just doing that breaks other games (it makes Phantasy Star Portable show even less text.) I tried setting minz/maxz but they seemed to have no effect (in throughmode at least.) viewportz1/2 don't seem to do anything either...

Obviously, s16 wraps since it only has 16 bits.

Hmm... seems like Step_PosS16Through (and probably the jit versions) convert z to a signed float. With that fixed, other games do seem happy.

-[Unknown]

[hrydgard]

@unknownbrackets , alright I sent a pull request that changes PosS16Through to do Z unsigned.

Not sure at all what minz/maxz are supposed to be doing..

Viewport will not have any effect in Through mode, it's applied at the end of the regular transform pipeline which is completely bypassed in through mode.