Auditorium regression since #8743

[LunaMoo]

Black screen, runs at half fps(15/15) log get's spammed with:

E[DISP]: HLE\sceDisplay.cpp:804 80000107=sceDisplaySetFrameBuf(04000000, 512, 3, 0): must change latched framebuf first
E[DISP]: HLE\sceDisplay.cpp:804 80000107=sceDisplaySetFrameBuf(04088000, 512, 3, 0): must change latched framebuf first

Commenting out:

//return hleReportError(SCEDISPLAY, SCE_KERNEL_ERROR_INVALID_MODE, "must change latched framebuf first");

is enough to make graphics render properly again:

[hrydgard]

That check was added in #8743 . It must either be a little overzealous or missing some additional condition....

Eh doh, the pull request number was already in the title.

[LunaMoo]

One weird thing I noticed about this one ~ loading savestate from working in-game still keeps the log spammed with the error, but shows graphics fine.

While it's booting it shows a lot of unimplemented stuff none of it seems important for the game, but maybe not having it causes some timing issue that triggers the problem, the game might be just buggy by nature, could be a poor port as it's a multi platform game.

Edit: I followed my guess and found one big function which calls all those unimplemented syscalls and the problem starts when it passes through it during boot. Dumb workaround that worked for me was to skip it all which game normally would do if sceUmdActivate would return an error. Doing so not only boots into game with normal graphics, it also avoids the spammy error, so I guess it all is broken by those unimplemented syscalls;|.

Edit some time in the future:
I noticed that this game shows similar results when running on ps3, so maybe this is some weird anti-piracy measure?
I mean what's the reason for a PS Store only release to try to activate an UMD drive and then happens to work fine without a single thing missing(at least nothing I could tell) when sceUmdActivate returns an error?;] Suspicious. If it should return an error we could just do it for PBP files or another compat.ini I guess, so I'll just add new label here as I can't test it myself;c.
Would be cool to know what sceUmdActivate returns when there's no UMD(and game isn't an iso/cso backup as I guess those could be treated like umd?) or what happens on psp with some random UMD inserted while running this auditorium mini.

[unknownbrackets]

Without a UMD, at least with CFW to run psplink, here are some results:

[x] sceUmdActivate(1, disc0:): 00000000
[x] sceUmdActivate(1, disc0:) again: 00000000
[x] sceUmdActivate(-1, disc0:): 80010016
[x] sceUmdActivate(0, disc0:): 80010016
[x] sceUmdActivate(2, disc0:): 00000000
[x] sceUmdActivate(3, disc0:): 80010016
[x] sceUmdActivate(1, disc1:): 80010016
[x] sceUmdActivate(2, disc1:): 80010016
[x] sceUmdActivate(1, disc2:): 80010016

If it's calling it with standard parameters, it could be a different behavior with CFW...

-[Unknown]

[unknownbrackets]

Maybe just implementing sceMp4 would help (#1755.)

I assume the getframebuf changes have not helped here.

-[Unknown]

[LunaMoo]

Sorry forgot about this.
Yeah it still has same issue, althrough not sure, but something else possibly changed, I don't remember how it was 3 years ago, but it takes pretty long time to boot now and during that long time it prints in the debug log something like:

32:38:886 user_main    D[HLE]: jitcommon\jitblockcache.cpp:166 Adding proxy root 08896594 to block at 0887ba74
32:43:430 user_main    D[HLE]: jitcommon\jitblockcache.cpp:166 Adding proxy root 08880438 to block at 0887ba74
32:52:741 user_main    D[HLE]: jitcommon\jitblockcache.cpp:166 Adding proxy root 08863c84 to block at 0887ba74

Sometimes only or or two of those show up, maybe changes depending on me using unthrottle or not.

[unknownbrackets]

Hm, are you possibly using ir or a debug build? Or it's that slow even in release with jit?

IR tries to precompile for more smooth speed, but there might be some downsides to this. ProxyBlocks are used when multiple sections of RAM were involved in a jit block, so invalidating any section must invalidate that jit block.

-[Unknown]

[LunaMoo]

Release build with JIT. It takes around 18-20s to boot from pressing the game icon until it boots and first logo shows up, it's not that drastic, but compared to 1s boot in other games it kind of is.

Oh, it's caused by Simulate UMD delays, with Fast it instantly boots. Never thought that could slow boot by soo much considering it's still much faster than real PSP in other games.

[unknownbrackets]

Simulate UMD Delays is still very crude, which is why I keep saying I worry about proposals to make it on by default.

Simulate UMD Delays tries to simulate the seek delay of a UMD using some really awful basic heuristics. It definitely delays too much sometimes, and not enough other times. As long as two operations are close to each other on the disc, it's exactly the same as "Fast". It just adds a static penalty for operations on data that is far apart.

But distance in bytes on the ISO isn't really how the UMD drive works or what causes seek delays. It's a more complicated math formula. Add to that, the PSP-2000/3000 both have a UMD cache, which we'd probably ought to emulate even if we were correctly emulating UMD delays (since we default to PSP-2000 mode iirc. and some games detect that and do things that would be slow if it wasn't for the UMD cache that they trust is there.)

By the way, iirc from my tests - reads from the UMD cache are actually FASTER than "Fast".

But aside from all of that, this game is a mini. It wouldn't have ever had any UMD delays in the first place.

-[Unknown]