- RETROARCH PPSSPP CANT SEE TEXT PORTABLE
- RETROARCH PPSSPP CANT SEE TEXT SERIES
- RETROARCH PPSSPP CANT SEE TEXT PSP
RETROARCH PPSSPP CANT SEE TEXT PSP
If you wish to put your PSP games on your internal Xbox SSD, you can follow the steps in this video to expand your dev mode storage and place the games properly into the internal drive. Refer back to this video for initial settings before diving into this video.
RETROARCH PPSSPP CANT SEE TEXT SERIES
This video is a continuation of my original Retroarch setup guide for Xbox Series X|S.
Even starting at 0.5 with a 1/4 slice (so ) doesn't work.Keep up to date with my current Xbox Retroarch guides here It also seems like the depth range is "quantized." Or at least, It works properly if I round minz/maxz to the nearest 16 (or less than that at different slice values.)Įven a slice of 2 - doesn't work. Keep the range at as before and keep hoping no one clears values other than 0. Clear other values to those values but hope they don't happen. Clear 0 to 0, and hope games never use an = test. In other words, glDepthRangef(0.5f, 1.0f) and glClearDepthf(0.5f), then drawing with a shader output of -1.0 would not match the 0.5 - the clear value would be slightly higher than the min depth value. From what I can see, any value passed to glClearDepthf() ends up being at a half pixel offset of the range, and then it just rounds differently than a draw with the range. This is probably fixable, and just slicing differently seems to have fixed it.īut, even trying different values, it doesn't seem like I can match clear and the min range. The actual range is 65535.996, which causes some inaccuracy. For example, I can get 0x007f8002 and 0x007f8001, and 0x007f7fff - but I can't get 0x007f8000 no matter what I try.Īlso, when doing the 1/256 slicing - because we're slicing to 1/256th and then dividing that by 65535, is actually off. I don't know if the way I'm reading the values is accurate, but there are some values that don't seem "addressable" using any float I've tried. Just to give context on some debugging I did on my phone, glClearDepthf() can clear individual depth values at a precision of 1 / (2^24-1). It's not enough to go back to the "old method of vertex rounding." We'd need to stop respecting minz/maxz, start skewing wide viewport depth ranges to again, go back to clipping clamped ranges, AND go back to the old method of vertex rounding.Īnd some or all (I'm not sure) of these problems also seem to affect other older GPUs, such as PowerVR and Mali. Right now it looks like we have to get rid of each of these things. That is, each of these in a vacuum from the others seems to have different problems on Adreno 3xx.
RETROARCH PPSSPP CANT SEE TEXT PORTABLE
We've stopped shrinking/skewing/clamping viewports that have depth go from 65535, which was previously partially working around clamping but caused glitches in Phantasy Star Portable 2.Does not work on Adreno 3xx at least, and I think from your testing yesterday, doesn't work on old Mali or old PowerVR either. We're mapping PSP z=0 to GL z=something other than 0.Let me summarize what we're doing now, which all seems not to work: The problem goes deeper, although our old method was working more often. it's not about vertex depth rounding, though. I think this means it's either using half floats of fixed 20 bit values for the depth range and clear, although the actual depth buffer has 24 bits of precision. and 0xff00 works just fine, which confirms this. If we assume that we lose 4 bits when specifying the range, 0xfef6 won't work right. Note that it normally sets this range to 0x2710 - 0xfef6. And the above doesn't help Phantasy Star Portable 1 - but forcing minz/maxz to 0/65535 does help it. This is all while using a 1/256th scale range. I can also add the same 1 / pow(2, 20) to the depth range, and this fixes it - again, no smaller values help. but maybe I could find the "right place" to align to 1 / pow(2, 20). And adding an offset to both (in case it's rounding bias) doesn't seem to help either. Any smaller value does not seem to have an impact. I've found that if I subtract 1 / pow(2, 20) from the clear's "0", it works. This really should be simple, and hard to mess up, imho.Īnyway, since it's not drawing, it's clear that the cleared depth of 0 is > the drawn depth of 0. Clipping is enabled, but it doesn't matter - and it's throughmode. In Ridge Racer, it first does a clear to 0, and then draws on top with 0. I'm suspecting that the precision of the depth range or clear registers is terrible, or something. This really seems like a precision issue.
0 kommentar(er)
