[ALL] Zelda OoT/Majoras random freezing (+ potential pause menu fb corruption.)

[Dylan10126]

Platform - Windows 10
Version - 1.7.6
Rom - Zelda Ocarina of Time (all versions)
CPU - i5-4670k
GPU - GTX 980

Having an issue where the background of the pause menu will get all rainbow colored (see example below). The only solution I was able to find was the old PJ64 gameshark code which doesnt work.

That issue I can live with, however i'm mainly looking for information regarding random freezing I get where the rom will freeze, but the audio will still be playing, and the retroarch menu works fine. Save/load state brings me to a white screen with the same audio playing. These freezes can occur anytime between a few minutes of play, up to about an hour of play. The only lead I found to this issue was a year old post on the mupen64plus-libretro github saying that its related to Delay SI, which wasnt/isnt an option on the libretro cores.

[Dylan10126]

[m4xw]

So you decided to turn off framebuffer emulation and then ask why framebuffer emulation doesn't work?
IIRC there have been some freezes in OoT with high res textures if Color to RDRAM was off.
So enable FB Emu.

[Dylan10126]

I never disabled framebuffer emulation actually, its still set to true, but you would know that if you had asked instead of just assuming shit.

Color to RDRAM is set to Async, will change to Sync to see if that changes anything

[m4xw]

FBEmu is clearly off in that picture, also I know for a fact that this is functional (can also reproduce it by turning it off)

I played through OoT a couple of times myself with this core.
This only happens if FBEmu is off.
Do you use the bot ver, or compiled it yourself?

What is set for depth buffer?

[Dylan10126]

See screenshots attached for proof for framebuffer settings

bot version

Depth buffer is set to software (can see attached screenshot

[Dylan10126]

For what its worth, I cant reproduce this behavior via Parallel/angrylion, however that doesn't really mean much all things considered

[m4xw]

Try the GLideN64 branch, the mupen_next branch (the bot uses) is heavily outdated.
But it should work there too. Do you use up2date nvidia drivers?
Also just to make sure, you tried restarting the game?

[Dylan10126]

Was originally running the 9f92565 branch. Tried the 72cee5e (GlideN64) and on a whim, the 73ca3a8 (main) branch for no difference.

Updated to Nvidia driver version 430.39, no difference.

I noticed the issue occurs more frequently in more demanding places. Mostly areas with a lot of actors causes this behavior, otherwise it acts normally. Its not related to fps, as I always maintain a solid 60

[m4xw]

I will need a RA debug log.
Seems to be something with your setup.
Def. doesn't happen for me on a bunch of platforms.

[Dylan10126]

debug.txt

[m4xw]

Thats not a debug log.
You need to use ./configure --enable-debug

[Dylan10126]

Using that command flings me back to the help message, only letting me launch a verbose log or a messages log

[m4xw]

Just build RA using ./configure --enable-debug, then just do ./retroarch --verbose

[Dylan10126]

retroarch-log.txt

[m4xw]

That doesnt look too bad, can u try without texture enhancements?

[Dylan10126]

Disabled texture enhancements, no difference
Went to default 4:3 ratio, no difference

I'm still getting that texture state usage warning in the debug. Also it really didnt like it when I was running the debug in the cmd the first time around. Performance had a minor dip, but what was once an every couple of pauses issue was now constant

[m4xw]

Does it happen without high res textures too?
I can actually see the color buffer in the background, if i have to make a guess i'd say its driver related, doesn't happen for me on my GTX 1060 tho, GTX 780 or Switch.
I use a older driver tho..

[Dylan10126]

Yup. debug errors and all

I'm moving to a 2060 Ryzen build in a few days, so I can always revisit it. That being said I still cant trigger it in Parallel for the life of me. Been using the main room of the water temple as a test area for both libs.

What driver version are you running? I can try doing a rollback

[m4xw]

Well Parallel has a entirely different renderer.
It's completely sw rendered, so its not surprising.
I am on 417.22 (quite old)

[Dylan10126]

I just came from 399.xx before you made the suggestion to update

[m4xw]

Thats double weird

[m4xw]

I will investigate if i can repro.

[Dylan10126]

Not sure if it matters, but as for using save states with this issue, I have had mixed results. Utilizing a save/load state cycle with the framebuffer messed up, I have had situations where it would stay the same, or it would fix itself on the load and be normal, or id have it spit out this fun little image

[m4xw]

Check gl, its what I test.

[BParks21]

Never mind the fresh install defaults to gl so it was already tested

[BParks21]

I've reproduced it on my phone as well, but the result is slightly different. It results with an incorrect after image of Link and his surroundings. Like a previous position before the point i paused the screen.

[BParks21]

@m4xw Try starting a new game and pause the screen in Kakariko Village outside. I've noticed it doesn't happen everywhere. I can always trigger it there though.

[m4xw]

Give me a savestate where i just have to open the menu.

[BParks21]

@m4xw
Legend of Zelda, The - Ocarina of Time (USA) (Rev B).zip

[BParks21]

@m4xw So?

[BParks21]

So were you able to test the savestate?

[m4xw]

No, I got actual work to do.

[BParks21]

Ok sorry to bother you. Lmn when you do

[m4xw]

Will do.

[Dinksy0392]

Hello, for everyone that experiences crashing/or rainbow graphical glitches while pausing, i may have found a fix. Theres a subscreen delay fix code you enter in your "cheats" and enable it and boom. no more freezing, no more graphical glitches. i hope it helps someone like it did me

http://www.emutalk.net/threads/13878-Ocarina-of-Time-subscreen-delay-fix-codes-for-all-ROMs

[m4xw]

That cheat is already in place and automatically active with a known rom.

[m4xw]

Also you think about different kind of freezes here.

[BParks21]

Has anyone tested my savestate for the pause menu bug? I still get this bug even using the rom listed in the gamedb.

[BParks21]

@m4xw I really would have liked for you to have at least tested my savestate. I still have a pause menu with a white background but only in very specific places in the game. I've tested known roms from the database and i can produce it.

[m4xw]

@BParks21 I am currently on break and this is very low prio to me.

[BParks21]

@m4xw Okay funny the only version of Ocarina of Time that doesn't produce a white pause screen or a rainbow pause screen is Ocarina of Time Master Quest, the dump from the gamecube release. Every version I've tested from mupens data base and other rom data bases it occurs. In fact the pause screen transition is beautifully smooth in this version.

[m4xw]

@BParks21 Create a new Issue, this is getting nuts scrolling here.
Also please add details about your system & the sha256' of the rom's you used, impossible to look up in this thread.
We can continue the discussion there.

[BParks21]

@m4xw Sure np. What should i call it though? White/rainbow pause menu? I can't reproduce the rainbow pause menu anymore. It went rainbow in older releases. Now it just goes white sometimes.

[m4xw]

[Discussion] Zelda Pause-Menu Framebuffer Issues under certain conditions

[BParks21]

@m4xw Also when referring to the db I don't know how to find the crc of my file. I find the md5 fine but the 16 character crc format is what i can't figure out how to find. I convert the md5 with a little tool to crc-16 or crc-32 and i only get a 4 character result. I don't know a lot about this stuff, so yeah I'd appreciate some more info on how to properly check it. My md5 matches with the database i just can't figure out how to find my crc from my file.

[Pearate]

Hi I'm having some issue too.
Windows 10 RetroArch 1.8.5 (updated nightly) + mupen64 Plus-next 2.0.5
(RetroAchievements Hardcore Activated)
Tested 2 rom with the same results :
Legend of Zelda, The - Ocarina of Time (USA)
CRC32 Checksum: CD16C529
CRC32 Checksum: EC95702D
First I played OoT and I had no problem until the Forest Temple (maybe 10h of play)
Then I had a first random Freeze, followed by multiple random Freeze since.
To fix that, I changed some settings, so actually the Freeze don't appear anymore apparently.
But the new thing is that the game crash randomly.
So I read this topic and apparently I'm not the only one.

Have you find a clear solution yet ?
Thx

[flagrama]

@Pearate If you run into the OoT freeze again, could you input the Ocarina of Time Debug Input Sequence and share a screenshot of the first screen? I'm curious if it is the same issue the OoT randomizer randomly runs into. It apparently only happens on the dynamic_recompiler in m64p-nx.

I'm starting to think this is the same issue. I think I'm gonna have the person who has been testing the rando ROMs try to see if this happens only in 1.0 or 1.2 as well, then might make a proper issue for this freeze.

[flagrama]

@Pearate #180 is probably the issue you want to follow for your problem.

[Pearate]

Ok, if I have a new freeze I test the debug sequence, just to see.
For the moment, I changed to pure_interpreter, and I have no crash so far.
I keep you informed.
Thx

[peacepenguin]

#180 (comment)

I have same type of freezes and corruption in pause sometimes. BUT so far i can avoid them following the above advice about not ever running "fullspeed". I was sometimes pressing "space" to "fast forward" slow dialogue, i think "fast forward" = "full speed". Then sometime random after fast forwarding i would get the crash. Pause corruption seems like it wouldn't ever happen until i after i did a fast forward too. So pause corruption may be an indicator the freeze bug is "primed".

I avoid it now: do "in game" "save". close rom. run rom. load save from in game menu. Take new save state. Stop fast-forwarding. Now I haven't had a freeze, and no pause menu corruption even after hours of running.

BTW i use 100% default settings and stable release, except: aspect ratio: 16:9 adjusted

[BParks21]

I've also tested the latest version of GLideN64 in both mupen64 plus upstream and project64 dev builds and cannot reproduce this white pause screen with any of my roms.