Misshitsu no Sacrifice and Macross series needs mipmap interpolation for smooth animation.

[RadarNyan]

DEMO: NPJH90092 PRODUCT: ULJS00251
(This game required 6.10 PSP update)

No vocal
All vocals are silent in game as reported in #2436 but BGM now works fine.

In debug log:

01:24:128 BGM thread   E[ME]: HLE\sceAtrac.cpp:939 sceAtracGetSecondBufferInfo(0, 0bfafa54, 0bfafa58)
01:24:128 BGM thread   D[ME]: HLE\sceAtrac.cpp:1353 sceAtracSetLoopNum(0, -1)
01:24:128 BGM thread   D[ME]: HLE\sceAtrac.cpp:919 sceAtracGetRemainFrame(0, 0bfafa50)
01:24:128 BGM thread   D[IO]: HLE\sceUmd.cpp:316 0x32=sceUmdGetDriveStat()
01:24:129 BGM thread   E[ME]: HLE\sceAtrac.cpp:632 WARNING: Remaining data in packet - we currently only decode one frame/packet
01:24:129 BGM thread   D[ME]: HLE\sceAtrac.cpp:702 00000000=sceAtracDecodeData(0, 08986a00, 0bfafa24[00000800], 0bfafaf8[00000000], 0bfafa1c[232])

Intro background video lagging

(Check next comment for animation)

Nothing wrong in log console, OP movie plays pretty fine and smooth though.

Edit:
Just a list of titles that are affected by this with gameID's in case it'll ever need a hack:

• Misshitsu no Sacrifice(ULJS-00251, NPJH-50224),
• Misshitsu no Sacrifice Jitka: Aru Heisa Shisetsu kara no Dasshutsu (NPJH-00065),
• Misshitsu no Sacrifice: Miki High Tension Night (NPJH-00077),
• Macross Ace Frontier (ULJS-00158, ULJS-19029),
• Macross Ultimate Frontier (ULJS-00231, ULJS-00223),
• Macross Triangle Frontier (ULJS-00321, ULJS-00369, ULJS-19072).

Macross series uses it for(AFAIK) water animation only, Misshitsu series uses it for pretty much all animations, including animated UI.

Also to note since things are easily forgotten, mipmap interpolation is already supported in software renderer.

[RadarNyan]

Intro background video lagging

side by side gif animation showing this bug in action (up: real PSP, down: PPSSPP)
as you can see PPSSPP is also running in full speed (check the arrow, it animates fine)
GE debugger shows these textures have two levels, L1 is different from L0 but the same (in shape) as the next changed textures L0 but lighter (in brightness).

JPCSP also has this problem.

[unknownbrackets]

Has this improved or changed at all? If not, a log might help - wondering if it uses sceMpeg or scePsmf.

-[Unknown]

[RadarNyan]

Tried latest git build (v0.9.9.1-1582-g08eaa6e) nothing changed.
Which log level & log channels should I choose for the log?

Here's the official download link of trial version (NPJH90092) if you want to debug yourself:
http://www.d3p.co.jp/sacrifice/ms_trial.zip
This scene is at the very beginning of the game (right after you start the game from title screen)

[LunaMoo]

The problem might be completely unrelated, but the animation of what should it look like vs how it looks reminds me of water in macross games, so just for reference to check another if one of those get's fixed - #5559

[unknownbrackets]

Interestingly, it draws this using bezier patches. I'm not sure, at first I thought it was using bezier to "tween" between keyframes, but afaict it uses the same control points for every single frame.

The bezier patch is a single patch and, afaict, it's always the same. We generate pretty basic UVs for it, in a 0, 0.25, 0.5, 0.75, 1.0 pattern. I'm guessing that part is all correct. It uses UV scaling to just draw the right portion of the texture.

Importantly: it uses 2 texture levels. The two levels appear to be slightly different frames. level/bias is set to 0x050001 and slope is 0. While displaying a single frame, this bias (the 5) goes from 0x0 - 0xf, so this is probably what drives the tweening affect?

But, it only ever has 2 texture levels. Our current code seems to think that texlevel >> 16 should peg a specific mip level?

-[Unknown]

[hrydgard]

Are the two levels set to different sizes or the same size? Really interesting use of the mipmapping hardware and mipmap bias if the latter, and one that we simply can't replicate using OpenGL, without writing some rather specialized shader code for this case...

[unknownbrackets]

Same size, sorry should've mentioned that.

I mean, I guess we could fetch from both levels and interpolate ourselves if we did it in the shader. Seems messy... probably better to bind as separate textures?

I looked at the code again, we divide by 16. So basically, it goes from 0.0 to 0.9375 of the next keyframe using mipmapping. I still wonder if this is what that water does as well in the Macross game.

-[Unknown]

[hrydgard]

So - if the first two mip levels are the same size, we create them as separate textures (or as a WxHx2 3D texture where available, that is, OpenGL 3 and ES 3+) and either blend in the shader or sample the 3D texture with a Z coordinate equal to the mip bias. Yet more shader flags and combinations, sigh...

[hrydgard]

Actually I think this is rare enough that we can just ignore it for OpenGL ES 2.0 and go ahead and only do the 3D texture solution. Doesn't seem worth the trouble to go all out with workarounds when this will be comparatively easy to do...

[unknownbrackets]

For voices (probably ought to be a separate bug though), it seems like an timing problem related to IO. It calls sceIoClose on a file, then starts a thread and that thread tries to access the file. It's possible we're doing async wrong and that can somehow work...

-[Unknown]

[unknownbrackets]

So, what's happening here with the voices is that even after closing a file, you're supposed to be able to read a stale result from the file - it seems. Basically the game does this:

thread1:
sceIoOpen
sceIoReadAsync
sceIoClose
create thread2

thread2:
sceIoWaitAsync

It seems like sceIoClose is meant to wait for the pending operation to complete, and then close it. The result would then be available for thread2, and the memory would've been written.

-[Unknown]

[daniel229]

JPCSP fixed the voices in jpcsp/jpcsp@61ecddc

[hrydgard]

Just for the record, I believe #8868 should have fixed the voices here. Mipmapping ("video lag") issue is, as mentioned, the same as #5350 .

[RadarNyan]

Yes, I can confirm that voices playback is working.
Can't test the code in for mipmapping though as I'm currently not cappable to make a custom build.

[LunaMoo]

Just to note this fake mipmap problem isn't limited to the talking goo animation shown above, possibly all animations in this game use it, from the start of the demo I noticed it on ui elements(althrough not as bad with those just cuts fps by half) and all animated water(looks pretty much as choppy as in Macross series).

[hrydgard]

Both problems seem to be fixed since a long time, closing.

[LunaMoo]

Those problems were fixed, but for now only in softGPU.

[LunaMoo]

Would implementing this still be that bothersome in for example Vulkan backend? It's nowadays decently supported even on mobiles.

[hrydgard]

Not difficult, just a little architecturally awkward, and since it doesn't affect playability it's kinda fallen down the list of priorities. It will get implemented though (for VK/D3D11, possibly also GL 3+)

[LunaMoo]

I'd say it does affect playability of at least Misshitsu series since all animations in the game use it and currently run like they're on heavy frameskipping^_^;, then again there were always people willing to play in single digit fps if the alternative would be not playing at all.

[hrydgard]

I hacked up something Vulkan-only that needs testing. Some GE dumps would be great, preferably in the middle between two animation frames. Both for Misshitu and Macross water, ideally.

[unknownbrackets]

There's actually a free demo up above. It does it pretty early on.

-[Unknown]

[hrydgard]

Oh right, I think I have that sitting around somewhere - unfortunately, the link 404s.

[Panderner]

Misshitsu no Sacrifice's intro background video runs smoothly on latest build.

[hrydgard]

Closing, finally :) That was not easy, heh.