-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MotorStorm Arctic Edge USA - Abnormal Shadow #7552
Comments
The EU does not have the shadow glitch while the USA verson has that glitch. |
@daniel229 that sounds very strange :/ |
Does this still happen? Can you capture the drawing of the shadows in the GE debugger? -[Unknown] |
Can you try to pick out when it's highlighting the ground in red, right before it draws the shadow? https://github.com/hrydgard/ppsspp/wiki/How-to-find-a-graphic-issue-with-the-GE-debugger What I'm looking for is how it's drawing the shadow. I don't have the game so you are my window into this information. A screenshot just shows me that it's wrong but it could be doing so many different things. I guess it's most likely projecting. Maybe it's using stencil or something though... -[Unknown] |
If can't be fix than it is fine. :) |
Normally if you keep pressing step prim, it will eventually show the car. What you're seeing there is it initially clearing the screen. Here's how it works:
You just pressed step prim a couple times. You probably didn't even get 1% through the frame. There's a ton to draw. It redraws everything from scratch every single frame. That's how 3d games work. -[Unknown] |
That's exactly the right place, I just need the contents of the other tabs (you can use ctrl-a ctrl-c to copy as per that wiki page.) You can get there quicker by clicking "Step Frame" and then "Break on Texture..." and pasting 0x0907af00 into the box, then clicking "Resume". It will stop when it starts using that shadow texture again. So it's not projecting, it seems to be drawing it right where it wants. Actually, I wonder if this is bot blending right... I especially want to see the Flags, Lighting, Texture, and Settings tabs. -[Unknown] |
OK here it is. Flags: |
Lighting: |
Texture: |
Setting: |
Vertices: |
Matrics: |
List: |
Hope it help. :) |
Thanks. Those UVs definitely look questionable. If this is when the red is highlighted, it makes me think the vertices were written incorrectly somehow. The first one looks probably right, the rest look wrong. -[Unknown] |
Hm, if the vertices are written wrong, that would likely be a VFPU bug.. I thought we flushed most of those out by now though. Maybe some kind of int to shorter int conversion is not saturating properly, or similar.. |
Is the shadow issue fixable ? |
Hmm, I'm not sure now... the vertices can't be that wrong, because the preview is drawing them in the right place... right? Anyway, it's also possible this might be depth related. Does this behave the same in OpenGL and Direct3D in the latest git build? -[Unknown] |
Same issue for both OpenGL and Direct3D |
Notes for self: tex=0x0907af00, verts=0x08d8f520. Written by 0x089383D8 at 0x09FFABD0 -> copied from 0x09FF7BD0 -> copied from 0x09FFDBF0. That's written by 0x0893A358. Software renderer gets this wrong too. And lots of other things... It's the same across all backends and with jit enabled or disabled. UVs are definitely wrong, but haven't dug into why. 0x0893A16C vtfm2.p C300, E400, C010 -> This is always resulting in a 0 result pair, which gets multiplied by (0.5, 0.5) and then has (0.5, 0.5) added to it. Clearly this is not expected to result in zero - either the inputs are wrong, or the operation is wrong. The E400 matrix largely comes from 0x08AAA9C0 which seems to always be 0 and isn't written to. Seems to be in bss. Not seeing anything else relocate it... -[Unknown] |
Just to confirm this is somehow RAM or CPU related: a GE dump of the wrong shadows renders the shadows wrong on a real PSP too. It's possible there's something the dump isn't reproducing, but most likely it's CPU emulation or RAM transfer/cache/etc. related... -[Unknown] |
Doesn’t matter. |
Hmm, I'm pretty sure this bug still exists. -[Unknown] |
Same happens on latest version |
Still in 1.11.3 BTW. |
These versions are affected by shadow glitch: Europe Version (UCES01250) is the only version does not have Shadow Glitch. |
That's really interesting that it's game version dependent! We don't seem to have any compat.ini hacks that could be missing version IDs.... |
Any updates on this? |
Right, as I said, this isn't really renderer related. Something is funny with the drawing the game triggers. I guess it could even be a tricky VRAM mirror thing like Silent Hill. For reference, here's a frame dump (edited to remove the bloom, to be sure it isn't overwriting the PSP drawing) and what it looks like on a PSP: It's still unclear what's happening here but it seems to be related to something on the CPU, not actual rendering. A cheat to get rid of the shadow could write the following:
As a hack, which would at least make the shadows not show at all. Equivalently, you could force the values in memory it's reading (this will also just disable shadows, though):
I'd be curious to know if the Europe version has similar code, US looks like this originally:
The operation of this instruction is:
But E400 is all zeros. And as noted, that matrix is loaded from memory at 0x08AAA9C0 (this occurs at 0x0893A028), which starts its life as all zeros and doesn't change. So bit of a mystery what's supposed to fill it in. -[Unknown] |
On Latest ppsspp-v1.0.1-97-g3e1e8f1-windows-amd64. Buffering Mode On and all default settings.
The text was updated successfully, but these errors were encountered: