That looks somewhat close to how it is, it's just right now the Z divide on X/Y is being done before the inner equation, rather than after it. I've added some more debug logging, hopefully I can see what the actual verts look like before any transforms.
-
-
Vastauksena käyttäjille @TheMogMiner ja @Atrix256
it's super confusing that they have .x,.y .w as well as .p[0] to .p[3]
2 vastausta 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @leonard_ritter ja @Atrix256
I've been doing a pretty poor job of explaining the whole thing, but there is no .w, just .x and .y - any other interpolants (Z, W, anything else) get specified in a parameter array. https://github.com/mamedev/mame/blob/master/src/devices/video/poly.h … And, the driver itself: https://github.com/mamedev/mame/blob/master/src/mame/drivers/namcos23.cpp …pic.twitter.com/CVk2r0yHWJ
1 vastaus 0 uudelleentwiittausta 1 tykkäys -
Vastauksena käyttäjille @TheMogMiner ja @Atrix256
the mysterious 24 word packet that you originally posted, is that what these matrices look like typically or is it supposed to be weird for this game? what does it look like for a game that renders correctly?
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @leonard_ritter ja @Atrix256
Based on looking at the underlying game code, it appears to be a standard function that's used by each game to set up at least the projection matrix. Here's what it is in the scene I screenshotted: 1.0, 0.0, -0.414215, 0.0 0.0, 1.0, -0.310669, 0.0 0.0, 0.0, -1.0, 0.0
2 vastausta 0 uudelleentwiittausta 1 tykkäys -
The other (rightmost) half of the matrix is the same, except the -1.0 in the bottom row is 0.0, and the lower-right value is 772.531250
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Some of the verts being sent (yes, the hardware supports quads for some damn reason), note the "Pre-Clip Vertex" valuespic.twitter.com/1m8quuTR5U
1 vastaus 0 uudelleentwiittausta 1 tykkäys -
Vastauksena käyttäjille @TheMogMiner ja @Atrix256
this is being made even more confusing by the fact that you target MAME's render engine rather than GL or D3D
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @leonard_ritter ja @Atrix256
MAME doesn't *have* a render engine per se. It's all software rasterization. By the time geometry gets handed over to poly_manager, the verts must be in screen-space for the bitmap to which it will be drawn.
2 vastausta 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @TheMogMiner ja @Atrix256
my point stands
1 vastaus 0 uudelleentwiittausta 0 tykkäystä
Sure, but it ultimately boils down to the resulting X and Y members of vertex_t should theoretically be in the range of 0..639 and 0..479.
-
-
Vastauksena käyttäjille @TheMogMiner ja @Atrix256
from the matrix values you told me, my assumption is that the values would be in NDC coordinates, and the the 772* value in the last corner scales the vector's x/y components to pixel size. only a single one is required to do that.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @leonard_ritter ja @Atrix256
The baffling thing is that I'm not sure the meaning of the 772 value. I have, however, found a much better scene, as it has a single full-screen quad.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä - Näytä vastaukset
Uusi keskustelu -
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.