Gliden64: Yakouchuu II - Satsujun Kouru: missing movies: HVQ movies unsupported (HLE)

[olivieryuyu]

Movies for this game uses HVQM technology (it is explained briefly in the lastest SDKs of the N64).

Only Pokemon Puzzle League and Yakouchuu II - Satsujun Kouru use this technology.

Pokemon Puzzle League uses the RSP version of the HVQM "microcode" where Yakouchuu II - Satsujun Kouru the CPU one.

Here what i can find with Nemu debugger for Pokemon Puzzle League

and for Yakouchuu II - Satsujun Kouru

As Yakouchuu II - Satsujun Kouru seesm so to the cpu version, normally the only thing would be to let the CPU to decode and transfer the graphics to the N64 memory and display them. However it doesn't work with detect CPU write option. It is even more obvious by the fact that running Glide64 on LLE emulation (it acts then as a dummy plugin) leads to displayed the movies!

[purplemarshmallow]

I get these results:
GLideN64 LLE: everything works fine, movies display correctly with detect CPU write option
GLideN64 HLE: fatal error if framebuffer emulation is enabled

[olivieryuyu]

indeed it works in LLE with CPU write option.

So it means that a command is used to allocate the framebuffer or something aroundish. It is not really a full microcode to be deciphered.

[AmbientMalice]

Just a thought - maybe this is related somehow to https://github.com/gonetz/GLideN64/issues/472

[purplemarshmallow]

I made a savestate in the middle of a movie and loaded it with GLideN64 HLE and I got to see something weird

[purplemarshmallow]

detect CPU write option does not work!
I saw the movies because I opened the config dialog. This switches the plugin into cpu rendering mode.
So there are two problems here:
-detect CPU write option does not work
-movies do not display in HLE (fatal error if framebuffer emulation is enabled)

[olivieryuyu]

the microcode allocates a buffer in the N64 memory and this is simply not handled i guess.

There is many information about this "microcode" in the latest N64 sdk.

[theboy181]

latest N64 sdk.?? when was the release date for the SDK?

[purplemarshmallow]

I think in 1999

[olivieryuyu]

SDK version 5.2 is dated September, 2000

[olivieryuyu]

I dumped the ucode: the version of Yakouchuu II - Satsujun Kouru uses a lot less code than Pokemon League. It is normal as the CPU is used to decode what was brought in memory.

If you uses the basic CFB plugin from Zilmar, you can see the movies of Yakouchuu II - Satsujun Kouru, with the wrong colors but you can.

Now potentially that fact can explain that in Pokemon League GlideN64 is able to display the movie as the RSP does all the decoding work and what there is in memory is the final result.

With Yakouchuu II - Satsujun Kouru, you need to wait that the CPU do the decoding and I guess GlideN64 does not catch this result or most likely interfer by its framebuffer emulation in this CPU decoding work, leading the graphic plugin to not work with framebuffer = CRASH.

It explains why using our good old Glide64 in LLE mode (as the CFB basic plugin), the movie is displayed and with the right colors! Because Glide64 does not interfere with the memory.

Reversing the ucode would not help because most of the decoding is not done by the RSP. What is needed is to intercept what was decoded by the CPU without pertubing the memory.

@gonetz

Does that makes sense?

PS: That does not explain however why it works in LLE? May be the ucode says where to read memory? If not, what is received as display list then?

[gonetz]

If image decoded by CPU, it can be output using only VI (video interface), no display list needed. Address and other parameters of image to output are in VI registers. I can't say more without digging the game, but I don't have time on it atm.

[theboy181]

@gonetz. Do you have a roadmap of your desired path for GLideN64? I would like to update the discord and share the direction.

[gonetz]

@theboy181 I don't have a roadmap due to heavy load in RL and thus lack of time for hobbies. There are global tasks, which I'd like to try to solve, like pixel coverage emulation, precise texture mapping and so on, but when I have one-two hours per week ...

[olivieryuyu]

I checked the ucode.

Significant amount of data are dealt by the RSP through quite a complex code and seems to be send back to some addresses in RDRAM.

I guess thoses addresses are a framebuffer where GlideN64 could read information.

This explains why CFB basic plugin can display the graphic as the data are most likely in basic output format.

This explains as well why GlideN64 crashes in HLE: ucode is not handled.

[StenApp]

http://jul.rustedlogic.net/thread.php?pid=432421#432421
https://github.com/PartyPlanner64/PartyPlanner64/wiki/HVQ-Image-Format

[olivieryuyu]

starting working on this one. Not very easy and fun to work with but it is the last HLE task!

[olivieryuyu]

need help please!

Can somene give me access to the menu where I can select movies? I mean a PJ64 savestate.

explanation here: https://tcrf.net/Yakouchuu_II:_Satsujin_Kouro

I did not succeed but someone will get it for sure

Thanks

[oddMLan]

@olivieryuyu Here you go
Yakouchuu II - Satsujin Kouro (J).pj.zip

Some cheats don't work with the recompiler. make sure to use interpreter & hold L while the game is booting.

[StenApp]

So this ucode is done, right?

[olivieryuyu]

decoded, not implemented yet

[olivieryuyu]

last microcode to be implemented. It could also be considered a pure RSP task as for Pokemon Snap.

[olivieryuyu]

https://github.com/mupen64plus/mupen64plus-core/issues/546

It should not be a grahics plugin task but a RSP task.

Decision is to not implement the ucode in GlideN64.

It is possible to play with this version of the CXD4 RSP plugin (win32 version of Mupenplus)

mupen64plus-rsp-cxd4 for HVQM & Yakouchuu II - Satsujun Kouru.zip

[olivieryuyu]

@gonetz

by closing this ticket, all microcode issues are nearly quenched!!!