search

mupen64plus / mupen64plus-core

Core module of the Mupen64Plus project
1.29k stars 257 forks source link

Indiana Jones and the Infernal Machine recompiler freeze. #572

Open AmbientMalice opened 6 years ago

AmbientMalice commented 6 years ago

The game will freeze if you leave it idling in the main menu and let the demos play. The first demo will play fine, with the pyramids. But then the second demo, in China, will freeze just before the camera starts moving. Works okay with interpreter.

loganmc10 commented 6 years ago

When you say freeze what do you mean? Does the background music/sound continue playing? Does the whole application freeze, or just the game? Does anything show up in the logs?

AmbientMalice commented 6 years ago

Nothing in the logs. Music keeps playing for a few seconds, and then stops.

Jj0YzL5nvJ commented 6 years ago

I can reproduce this issue using 'mupen64plus-ui-console' on Xubuntu 16.04.4 LTS x64 and exist other reports over here, one of them is in Star Wars Episode I - Battle for Naboo.

For m64p:

A workaround is go to "Setting > Core and Plugin Settings > Core" and change 'R4300Emulator' from "2" to "1", "0" works too.

The problem occur with angrylion-plus too. @AmbientMalice, @billkings95, @GamingTVYT, can you all confirm that?

GamingTVYT commented 6 years ago

@Jj0YzL5nvJ Confirmed. In Star Wars BFN crash occurs (but only playing with the screen in Fullscreen mode of the emulator). Indiana Jones also has this screen locking problem. Yes it is occurring in the two Video Plugins.

StenApp commented 6 years ago

I can confirm that changing "R4300Emulator" to 1 creates a workaround.

It is not Recompiler related, it's a Interpreter problem too. Game loads demo and hangs, music plays, then stops and nothing happens anymore.

indydemo
loganmc10 commented 5 years ago

I can confirm that changing "R4300Emulator" to 1 creates a workaround. It is not Recompiler related, it's a Interpreter problem too

I'm trying to understand this, these statements seem to contradict each other. Does the problem happen when using the interpreter, or only when using the recompiler?

Can someone produce a save state that makes this problem easy to reproduce?

CallistoNTG commented 5 years ago

Can someone produce a save state that makes this problem easy to reproduce?

Just boot the game and leave it running in the main menu. It's the second demo cutscene, I believe.

StenApp commented 5 years ago

@Frank-74

Could you please provide a save game if its still logans wish?

https://github.com/gonetz/GLideN64/issues/1574#issuecomment-449567484

loganmc10 commented 5 years ago

Yes it would still be helpful

Jj0YzL5nvJ commented 5 years ago

Seriously? ...you need to do LITERALLY NOTHING to reproduce this issue. It's almost identical to #418

Frank-74 commented 5 years ago

@StenApp Hi, why ask me to provide a save state? I don't have mupen64plus installed.

I found settings that work for Project64 and Indy. No more lockups except for when loading trading post. Trading post only loads with Interpreter CPU. Demo's cycle around with no lockups.

I set Recompiler to Virtual Lookup Table, uncheck every option on recompiler except Register Caching and Cache. I set counter factor to 1 and VI Refresh to 1400. I've played through nearly to the end of the game with not a single lockup. When cutscene at end of level starts, I make a savestate so I can switch to Interpreter and let the trading post load. Once trading post is loaded I switch back to Recompiler.

With PJ64, protect memory enabled seems the cause for the lockups.

loganmc10 commented 5 years ago

I'm on holidays until Jan 2, if someone can provide a save state that makes this issue easy to reproduce I can spend some time to look into the cause of the issue

Jj0YzL5nvJ commented 5 years ago

Indiana Jones and the Infernal Machine Star Wars Episode I - Battle for Naboo

CallistoNTG commented 5 years ago

I'm on holidays until Jan 2, if someone can provide a save state that makes this issue easy to reproduce I can spend some time to look into the cause of the issue

You don't need a save state. In fact, using a save state makes the issue harder to debug/reproduce because if you use the recompiler-produced save state, for example, the game will freeze even if using the interpreter. As has been mentioned before, you boot the game, and simply wait. It will cycle through the demos, and freeze.

loganmc10 commented 5 years ago

If that is the case then it's unlikely this will get fixed. I know you all scoffed at the idea of needing a save state, but I need to be able to reproduce the issue in a few seconds so that I can try different things with the code. If I have to wait a few minutes every time I try something new I'd be at this for days, but I'll see what I can do with the save states that were provided

StenApp commented 5 years ago

but I need to be able to reproduce the issue in a few seconds so that I can try different things with the code.

That makes sense (now)!

@Frank-74 Sorry thought you could put a save game here

StenApp commented 5 years ago

@loganmc10 Any news about this?

loganmc10 commented 5 years ago

Recently the new dynarec was ported to x64, and I updated the m64p builds to use the new dynarec, so it's unlikely that this is still an issue, but I haven't had a chance to check.

Basically mupen64plus switched dynamic recompilers

StenApp commented 5 years ago

Can somebody please test if it is still an issue with the new dynarec

m4xw commented 5 years ago

@StenApp the issue appears fixed (using aarch64 dynarec), but stop_after_jal currently breaks the game if you shoot the gun, there is a workaround here https://github.com/mupen64plus/mupen64plus-core/issues/631#issuecomment-473479823 (or just setting stop_after_jal = 1 in new_dynarec_init will work too). It appears to need some additional instruction handling for predictive recompile.

JernejL commented 4 years ago

I would like to add a potentially useful info that this is potentially a GAME bug being triggered rather than a emulator issue - this area when entering shambala sanctuary will often also lock up in same manner on PC - it requires a few tries and some luck to get past on a modern pc - it's most likely a scripting bug triggered by some timing issue due to too fast hardware.

More info: http://www.the-spoiler.com/Sinjin/INDY/indylv4.htm

SPECIAL NOTE: There seems to be a popular "bug" with this level where after Indy enters the temple in the opening movie the camera pulls back to an aerial view of the building and you cannot see Indy. To fix this:

  1. Press the [Esc] key (in the game)
  2. Scroll to the options on the far right and move up to Display Options (the TV icon)
  3. Click the Advanced... button to access the advanced Display Options menu
  4. Click OK
  5. Click OK again on the main Display Options screen Following these steps should force the game to reset the video, and put the camera back inside the building with Indy. Now back to our game...

ALSO they supposedly fixed this, maybe you can look into how they fixed it:

https://steamcommunity.com/app/904540/discussions/0/3398435622550581452/

StenApp commented 4 years ago

Can somebody confirm that this is a game bug and/or an issue with the dynarec and/or the core? Is this still caused by missing additional instruction handling?

Jj0YzL5nvJ commented 3 years ago

This issue has already been solved with new dynarec but it still affects the original dynarec.

Other small issues to watch out for: https://github.com/mupen64plus/mupen64plus-core/pull/853#issuecomment-821321920 https://github.com/mupen64plus/mupen64plus-core/pull/871#pullrequestreview-688964637