Closed meepingsnesroms closed 1 year ago
Might be a bad bug but at the same time, the NEON renderer is a very, very good renderer and makes things much faster.
Just removing it altogether would be foolhardy.
What about disabling it until it can be fixed?
What on earth are you talking about?
Without the NEON renderer, PCSX ReARMed is worthless.
Let me make it clear once more - disabling or even outright removing the NEON renderer is completely out of the question. Spend your energy instead trying to fix the bug instead.
I have no knowledge in this area so I can't fix it, I will just use a custom build with it disabled instead.
This happened even with my custom build, but not with dynarec turned off so it is not the neon gpus fault but dynarec inaccuracy.
This may have to do with signed,unsigned casting since only far polygons are affected.
OK, try to see if you can get to the bottom of the issue. It's slightly messy code though and it's known that the ARM codepath is more complete than the C version, which has slightly broken graphics.
What is wrong with the C graphics pipeline?(aside for lack of resolution multiplier)
Broken graphics here and there, and several times slower than the ARM codepath.
I dont think I can fix it. But if it helps others it is somewhere in the dynarec and happens on armv6 and armv7.
Pcsx-reloaded with x86 dynarec does not have this problem. Most likely in the geometry transformation engine part. This is with the official bios. Disabling the dynarec fixes it but is too slow. Only affects far polygons, and even then only some of those. Moving your view point(car) to the left or right makes them appear even if you don't get closer, but they disappear again when centered. You can see them the best in the airship stage or by the spaceship in the overworld. They seem to only glitch if the tip of the triangle is pointed away from you.
I get this also with rpi3 (Cortex-A53) and CTR. it's quite subtle but i can see the triangle break-up on certain background objects.
if it's only certain arm processors, i wonder if more conservative compile options could resolve it?
i want to verify it happens in standalone - https://github.com/notaz/pcsx_rearmed - but having trouble getting it to recognise BIOS file and/or controller. it just locks up for me on rpi3. is there another game that shows it well?
I don't know of any other games that do it, it may be a speedhack the game implements if it thinks it is running too slow that could be fixed with timing adjustment like the other 2 hacks.(since only far polygons are affected it could just be lowering the render distance)
I can try to mess with the timing.
Still cant find whats wrong.
This doesn't occur on other games that use far distance polygons (like Spyro the Dragon.) I'll go around and try all the games I know of that have them but so far CTR was the only one I had issues with.
Well CTR is poorly coded so it is probably the games fault for using inconsistent timing.
If you google the "CTR language selector bug" you'll know what I mean.
The ps2 ps1 mode has different timing, does this happen on a real ps2?
I don't have my ps2 setup right now to test it but from this video it would appear not https://m.youtube.com/watch?v=aNYYMG4Oxds
The issue also doesn't appear in the official ps1 emulator on the ps3, however CTR does have issues on the psp/Vita official emulator if I remember correctly, but not sure if it's the same rendering issue.
I'm not seeing this, probably some dynarec bug fixed long ago.
The polygon culling on the arm dynarec completely destroys long distance objects, I tested with pcsx-rearmed android, pcsx-rearmed mac and openemu mednafen. Only pcsx-rearmed android was effected. Here is an archive of all test screenshots plus 2 broken ones for easy viewing. neonremove.zip
I originally thought it was the fault of the neon gpu plugin but after using unai gpu on android and testing it it still happened so all thats left is the dynarec.