it's super confusing that they have .x,.y .w as well as .p[0] to .p[3]
-
-
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ä -
The long-term plan is to more or less wrap the software rasterization within a compute shader, but proper support for that is going to require a massive upheaval of how the emulator draws things, as there's currently no support for the "core" to get HW buffers from the OS.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Thing is, the guy implementing this change is also responsible for the emulator's memory system, co-authoring the Mac machine drivers, and is working towards a cycle-interruptible 68000 core so that we can properly handle systems that use /DTACK.
1 vastaus 0 uudelleentwiittausta 1 tykkäys
Meanwhile, the reality is that the vast majority of these old arcade 3D games couldn't be mapped onto consumer GPUs that existed at the time of the driver being written, so software rasterization was the only option for an accurate presentation of the machine's output.
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.