Tony Hawk's Underground 2 Remix - randomly crash ingame (previously also gfx issues)

[Superearth958]

It never worked well.

Intros stopped working since v0.8.1-997. Game randomy crashes ingame.

Graphic issue in menu :

And ingame :

I tested it again with v0.9.1-1073 it's still the same.

Log : http://pastebin.com/rqwabL2H

[dbz400]

Humm , just view on youtube for actual PSP rendering .

[dbz400]

Funny thing .If i save state , the background appear again ?

[unknownbrackets]

So that means that we have a framebuffer but a block transfer or memory write wrote to it, probably.

-[Unknown]

[dbz400]

Humm yes , it is block transfer

case GE_CMD_TRANSFERSTART:  // Orphis calls this TRXKICK
    {
        INFO_LOG(HLE,"Block Transfer");

43:27:309 idle0 I[HLE]: GLES\GLES_GPU.cpp:985 Block Transfer 43:27:343 idle0 I[HLE]: GLES\GLES_GPU.cpp:985 Block Transfer 43:27:376 idle0 I[HLE]: GLES\GLES_GPU.cpp:985 Block Transfer 43:27:409 idle0 I[HLE]: GLES\GLES_GPU.cpp:985 Block Transfer

[unknownbrackets]

So then this is probably similar to #3515, unless the block transfer is from outside a framebuffer but that's basically the same class of issue.

-[Unknown]

[dbz400]

I see. I did try to comment out the blocktransfer and savestate to see what happen , looks like the block transfer is used for the character only but not the background

[dbz400]

Just for record .The intro CG has been fixed .However in-game still bit mess up in graphics

[dbz400]

Just tried to savestate in latest build here , the background now cannot reproduce now .

[unknownbrackets]

How are the graphics now?

-[Unknown]

[dbz400]

Confirmed it is still same issue as previous.

[hrydgard]

Graphics fixed (well, still has polygon cracks which appear to be from a slight mismatch between s16 and float coordinates and some flickering textures which I think have a similar cause).

However, still pretty unstable.

[dbz400]

Thanks .It is pretty unstable indeed. It sometimes foce to close it.

[dbz400]

Flickering texture is caused by HW T&L

[hrydgard]

Yeah, I think there's a difference between how the PSP and OpenGL interprets s16 format coordinates. On software T&L we convert them to float ourselves, avoiding the problem. Should be reasonably simple to compensate for the difference.

[dbz400]

That's good .I think would also fix multiple similar issue observer in many other games that i observed with same behaviour

[hrydgard]

Seems stable with interpreter though.

[unknownbrackets]

You mean the vertex issue / hw transform is fine in the interpreter but not the jit? I have not tried that for FF3/4/etc.

Could just be rounding errors then...

-[Unknown]

[hrydgard]

No, the intermittent crashing (segfault). Sorry for being unclear, I was referring to the title of the issue. Crashing is the main issue remaining.

[unknownbrackets]

Maybe we are crashing when it modifies a jit emuhack to a valid address we have not written code to?

-[Unknown]

[hrydgard]

The only code modification it does is to rewrite a large chunk of vhdp.q instructions, that are not at the start of a block, with a set of slightly different vhdp instructions. I think it hardwires a culling function for the current camera position, which seems ridiculous but whatever.

[unknownbrackets]

Right, but if it's doing those modifications with bit-twiddling it could corrupt an emuhack. Though, it's probably not that.

Does it still crash sometimes with everything disabled?

-[Unknown]

[hrydgard]

Still crashes, but seems to take longer to repro, somehow. Don't have a consistent repro method.

[unknownbrackets]

You added some safeties recently, does this still crash? Maybe it gives interesting log messages now?

Does multithreaded impact whether it crashes?

-[Unknown]

[ppmeis]

Tested with latest build. Graphincs and in-game look good, but there are still random crashes while playing:

Debuglog (change .jpg to .7z)

[unknownbrackets]

It crashes even with fast mem off right? What does the stack trace look like?

It probably crashes in jit. When it does, you can try viewing the Disassembly (Debug -> Windows iirc in MSVC.) It might be interesting tos ee what jit code it's crashing at.

-[Unknown]

[hrydgard]

The game has broken audio for some reason, I have a feeling it might be related..

[ppmeis]

@hrydgard I think the same. During characters selection audio change every time I change my character.

@unknownbrackets I'm installing MSVC Express. I'm looking for a guide, do you know how to use it? Because I have strange error while compiling...

[unknownbrackets]

Can you copy/paste the error?

http://forums.ppsspp.org/showthread.php?tid=5231

The better version is actually now 2013 Community, but they're both fine.

-[Unknown]

[unknownbrackets]

Is the audio broken even in interp, by the way?

-[Unknown]

[ppmeis]

@unknownbrackets I have a few strange errors while compiling or building:

Error 2 error LNK1181: cannot open input file 'ÿþ/.obj' C:\programming\ppsspp\ext\zlib\LINK zlib

Warning 3 warning D4024: unrecognized source file type ' ■/', object file assumed C:\programming\ppsspp\native\CL native

[unknownbrackets]

I would try a brand new clone of ppsspp. It seems like something in the sln file got corrupted, maybe? Not really sure, never seen something like that...

-[Unknown]

[ppmeis]

@unknownbrackets I found the error, is because c1.dll and other dll on my SysWOW64 folder are very old. Now it works fine I'll try it now.

[ppmeis]

@unknownbrackets is this image usefull for you?

[Bigpet]

@ppmeis try to set it to "Debug" instead of "Release" (the combo box next to the green arrow) and also put the Disassembly in the view like suggested by unknown https://github.com/hrydgard/ppsspp/issues/3854#issuecomment-70701385

[ppmeis]

@Bigpet @unknownbrackets better now? :)

[Bigpet]

@unknownbrackets Do I read this right and the enterCode pointer (which is 0xbb197778) is invalid? Or what is the this+271 referring to

[unknownbrackets]

Well, that's 0x271C. But, sorry, the code I want to see is inside the jit. I forgot that it automatically navigated to the top stack frame...

In the screenshot, you see the call stack with 04b6008f()? If you double click that, you should see the disassembly near where the jit actually is. It may not be exactly the same number when it crashes again, but that's fine.

I'm assuming that enterCode is fine.

-[Unknown]

[Bigpet]

Oh yeah I didn't see that it's not the top-most actual frame but the top-most frame with debug symbols

[Bigpet]

@unknownbrackets Hm, seems to crash on multiple different addresses, this is one of them

[unknownbrackets]

Hmm, what about with fastmem disabled? That just looks like an invalid address. Still a problem, but nearly impossible to debug from the jit disassembly.

If jit is somehow causing the invalid addresses, that's interesting. But keep in mind interpreter always has fast memory off.

-[Unknown]

[ppmeis]

@unknownbrackets as you want:

[unknownbrackets]

Hmm, that is also an invalid address (EAX is 0.) That also should not crash with fastmem off.

-[Unknown]

[Bigpet]

yeah, forgot to turn that off without I just get a game crash

also this:

@ppmeis also doesn't seem to happen for me If I start the game without dynarec and let the levels load without it and only enable it once actually in a level, that may just be a fluke though

[ppmeis]

Turning off fastmem, same as @Bigpet:

[Bigpet]

here's one of the game crashing logs in full https://gist.github.com/Bigpet/447d0b1f13f8ad1fb9f9

and here's the same actions with the interpreter working fine https://gist.github.com/Bigpet/945bd47d26f4e23a5c6b

[unknownbrackets]

Interesting that it breaks different ways. I think the most likely thing is that we're failing to invalidate some block that we should. What we can try is in Core/MIPS/MIPSInt.cpp, find:

        // Icache
        case 8:

Does it change anything if you add after that case 20:? I think that's not an icache func, though, just a thought.

If that doesn't help, you can try changing these lines, right below that:

            if (MIPSComp::jit) {
                MIPSComp::jit->InvalidateCacheAt(addr, 0x40);
            }

To:

            if (MIPSComp::jit) {
                MIPSComp::jit->InvalidateCache();
            }

This should make it a lot slower, but if we're incorrectly invalidating a subrange, this might catch it. If that fixes it, it could still be missing some other invalidation method, but at least it means it's jit cache related.

What if you change these lines (without any other changes from above):

//#define CONDITIONAL_DISABLE { Comp_Generic(op); return; }
#define CONDITIONAL_DISABLE ;

To:

#define CONDITIONAL_DISABLE { Comp_Generic(op); return; }
//#define CONDITIONAL_DISABLE ;

In Core/MIPS/x86/CompALU.cpp, CompFPU.cpp, CompLoadStore.cpp, and CompVFPU.cpp (they may not be exactly the same lines but you get the idea)? I think we're already assuming it's jit mechanics, I just want to rule it out for sure.

-[Unknown]

[Bigpet]

Not sure what you mean by case 20:

I tried

    // Icache
    case 8:
    case 20:

and that did not help.

But changing it to MIPSComp::jit->InvalidateCache(); did indeed seem to help

I should clarify that this did not help (in fact it reliably crashes on level change)

    // Icache
    case 8:
        if (MIPSComp::jit) {
            MIPSComp::jit->InvalidateCache();
        }

but this did help:

    // Icache
    case 8:
    case 20:
        if (MIPSComp::jit) {
            MIPSComp::jit->InvalidateCache();
        }

[Bigpet]

So, the most narrow change seems to be

            // Icache
    case 8:
        // Invalidate the instruction cache at this address
        if (MIPSComp::jit) {
            MIPSComp::jit->InvalidateCacheAt(addr, 0x40);
        }
        break;
    case 20:
        if (MIPSComp::jit) {
            MIPSComp::jit->InvalidateCache();
        }
        break;

Do you still need the CONDITIONAL_DISABLE changes tested?

[unknownbrackets]

Hmm. Hard to say. It may be just using func 20 a lot, so invalidating everything there fixes it. That's probably not a solution and may make things slow...

What if you change the 0x40 instead to 0x4000 or something?

Hmm, if that affects it, probably CONDITIONAL_DISABLE doesn't matter.

-[Unknown]

[Bigpet]

4000 is not enough or it may be before that area

edit: This MIPSComp::jit->InvalidateCacheAt(addr-0x2000, 0x4000); didn't help either, so it may not be in the vicinity

if I increase it to something absurd like MIPSComp::jit->InvalidateCacheAt(std::max(addr-0x10000000,0), 0x10000000); it works but I assume that's basically almost all code anyway (one zero less makes it crash already which is weird since that should cover around +-16meg area around the code)