Resident Evil: 2d incorrect, no movies, background missing, etc ...

[olivieryuyu]

nearly nothing works :(

[clobber]

RSP bug? You'll want to probably be using cxd4/fatcat's RSP for this game (https://github.com/cxd4/rsp) as it is known to fix this. Also find it odd you are testing this new GPU plugin on stone age N64 emulators when you should be using Mupen64Plus and a LLE RSP. cc: @gonetz

[gonetz]

Thanks for the hint about cxd4/fatcat's RSP. Regarding "stone age" emulators: LLE core and RSP are used since the stone age and for most games there is no difference which emulator to use.

[olivieryuyu]

Tests are usually done with cxd4/fatcat's RSP. It is not a RSP bug I think

[clobber]

LLE core and RSP are used since the stone age

LLE from that era would have been 15% complete, not enough to boot anything besides a demo.

for most games there is no difference which emulator to use

If this glitch happens with either RSP interpreter, it is possible the RSP is receiving corrupt information from the recompiler in 1964.

In which case testing with Mupen64Plus interpreter + mupen64plus-rsp-cxd4 (with DisplayListToGraphicsPlugin/CFG_HLE_GFX = 1 https://github.com/mupen64plus/mupen64plus-rsp-cxd4/blob/master/rsp.c#L55) would disprove this right away. Or, continue to play whack-a-mole with bugs and regressions and the N64 scene stays in its Win32 hellhole.

[olivieryuyu]

clobber, please this is a bug tracker, not a open discussion on the right approach on LLE RSP core and so on. If you want this kind of discussion, the inn on our forum is the right place. Thanks

[clobber]

Wat. I've given you helpful hints and possibilities as to why you see the glitch. If my information is invalid, prove me wrong.

[olivieryuyu]

we are testing with Hatcat RSP plugin under many emulators RE2, Mupenplus included. All of them leads for the time being to the same bugs. It is a gfx plugin issue for the time being. Thanks

[olivieryuyu]

even in LLE there is no gfx????

[AmbientMalice]

RE2 is a very interesting game that does a lot of interesting things, technologically. I do hope GLideN64 can fix it -- I imagine it would have knock-on benefits.

[AmbientMalice]

I notice that z64gl renders garbage\nothing with Resident Evil 2. So it's possible that GlideN64 inherited this bad behavior from z64gl.

[purplemarshmallow]

GLideN64 and z64gl don't have so much in common it's based on glN64. The only thing that is taken from z64gl as far as I know is the LLETriangle command. There's not much difference between HLE and LLE plugins so it wasn't necessary to copy a lot from z64gl. From the blog:

if you already have HLE plugin, you are one step from having LLE support as well. LLE plugin does emulation of RDP. HLE plugin does emulation of RDP plus high level emulation of RSP commands. That is, HLE plugin is LLE plugin + HLE RSP. Of course, practical implementation of LLE mode in HLE plugin has nuances, but in general the situation is like that.

Every hardware gfx plugin has problems with Resident Evil 2 except Glide64 and Glide64 uses many hacks for this game.

[AmbientMalice]

Every hardware gfx plugin has problems with Resident Evil 2 except Glide64 and Glide64 uses many hacks for this game.

Most can at least render the main menu. Jabo renders the menu well enough, for example. Stripping out RE2's hacks in Glide64, and the menu still works.

You're probably right, though. It's more likely GLideN64 has a combination of bugs that are unrelated to z64gl - it's just an interesting coincidence.

[purplemarshmallow]

movies work for me detect CPU writes option must be enabled

[AmbientMalice]

Maybe this issue should be renamed.

I notice that RE2 displays slightly more graphics with FB disabled. But the splash screens, spinning logo - nothing.

[oddMLan]

Current state.

LLE or HLE, no difference :(

FB emulation disabled, menu partially shows and intro cinematics (not fmv) show up, with FB enabled they're all black

FMVs work perfectly with FB emulation enabled.

Render FB to texture does not help. Copy depth to RDRAM doesn't help either. The game is FUBAR as of now.

[Gillou68310]

If anyone is interested I spend a few hours in order to port the ucode used for rendering backgrounds to HLE. It's not 100% accurate right now but at least it's a good start. https://github.com/Gillou68310/mupen64plus-rsp-hle/commit/0e4c2817291a48e7aab10d84bdbeee3b822665fb

[AmbientMalice]

If anyone is interested

I am very, very interested. RE2 N64 is a neat version of the game, and my personal favorite. But it runs terribly on Angrylion's, especially when viewing the map or using high resolution mode.

[weinerschnitzel]

Im very interested too. Thanks for porting it to mupen64plus-rsp-hle!

[Gillou68310]

RE2 N64 is a neat version of the game, and my personal favorite

Totally agree ;-) A lot of things are still broken with gliden64 so it still needs some work. Also porting the ucode used for rendering FMV videos won't be an easy task.

[angrylion7]

@AmbientMalice please leave a report at https://sourceforge.net/projects/angrylions-stuff/ if you think there is a bug other than frame rate issues.

[olivieryuyu]

The ucode for fmv was documented by the devs themself.

[Gillou68310]

Do you have a link?

[olivieryuyu]

meynink.zip

here the code for the fmv as per the devs

[Gillou68310]

Wow thanks! I didn't expect to have the source code. Why nobody ported this to hle yet? Anyway I will dump the ucode and compare with the source code you provided.

[olivieryuyu]

@Gillou68310: are you able to decipher gfx ucode by any chance?

[Gillou68310]

The re2 ucode I ported was my first experience, something specific you want me to look at?

[AmbientMalice]

@Gillou68310 I assume he's referring to the FMVs. I'm not sure how they're meant to be handled, though. More accurate FMV emulation might not make any difference if the end results still require a hack to render.

[olivieryuyu]

No i was speaking generally actually. FMV is not crucial, still nice to be support in mupen hle rsp. I would think for a start something very minor.

[AmbientMalice]

@olivieryuyu Ah, I get what you mean. You mean the various faulty HLE ucode implementations. Cough, Turok dynamic lighting, cough.

Wasn't there an HLE specular issue in F-Zero, too?

[olivieryuyu]

Yes indeed. For instance chopper attack texture issue #99

[Gillou68310]

FMVs work perfectly with FB emulation enabled. gliden64_resident_evil_ii_001 gliden64_resident_evil_ii_000

FMVs seems to work without a hack, backgrounds still need a hack though. The initial idea of porting the re2 ucode was to help finding why we need a hack in the first place ;-)

Do you guys have a dump of the ucodes you're talking about? Maybe I can take a look. But honestly if it's more than 500 instructions it's going to be difficult. Re2 ucode was around 400.

[olivieryuyu]

Nemu has a gfx ucode dump tool.

@gonetz: is it possible to guide a bit Gillou68310 on his request?

[gonetz]

I myself would like to know, how to dump and debug ucodes. There are plenty of things, which work incorrect in HLE. And RE2 is in the bottom of my list.

[Gillou68310]

At least I'll need a savestate for m64p where the issue happens (LLE != HLE)

And RE2 is in the bottom of my list.

I'm sad to hear that :-(

[olivieryuyu]

well for issue #99, just start the game, the issue is visible at 2nd screen, no need for a savestate.

For dumping ucode RSP, not sure if it was what is needed but here what exists in Nemu:

It can be found in plugin, dump memory. Not sure if it works fine. However Lemmy used certainly it for deciphering Starwars Rogue Squadron ucode, so i guess it works a bit :)

[LegendOfDragoon]

I like Nemu, but its compatibility isn't too great. You're better off using an open source emulator, so that you can modify the debugging code to suit your needs. I use PJ64 to dump microcode.

Anyway, here's my incomplete collection of dumps. https://www.dropbox.com/s/zt3u4l9ngpuvj4g/Microcodes.zip?dl=0 . Now that I think about it, I'm not sure if all of those OOT files in "Other" are jpeg. Some of the files may seem redundant, but are slightly different. For HLEing purposes you won't need to look at each file though. I may have to play more in some of these games, to see if there's unique code i missed. May also look into static analysis to make sure I have everything dumped.

If you want to do something easy, then HLEing World Driver Championship's RSP microcode would be a good candidate. There's apparently not much RSP code being used in that game.

Another easy task would be to HLE GB Tower in Pokemon Stadium 2. GB Tower doesn't even work in Pokemon Stadium 1 on any emulator I've tried.

From what I've seen, Last Legion's microcode kinda looks similar to GE's. Not sure why that game hasn't been HLEed yet.

here the code for the fmv as per the devs

How did you obtain that source code? Do you have any other sources for unique games?

[olivieryuyu]

RE2: Source were shared by the devs on gamasutra. I have no other source :(

World Driver Championship uses a modified version of the Zsort microcode (Mia Soccer 64). Confirmed by devs of the game in the past. I would be surprised that it would be easy to decipher it but I am not expert.

Last Legion's microcode uses 2 microcode: 1 is the normal F3DEX (for background etc) and the other one is called T3DUX (as you can see in a debugger memory). This latter is certainly an extented version of the turbo3d one. That one should be easier.

I just hope that there is someone around to explain how to dump and translate/debug ucodes. Or help out on finalizing the HLEzation of the gfx microcode. Seems not an easy task. I keep hoping though.

[LegendOfDragoon]

RE2: Source were shared by the devs on gamasutra. I have no other source :(

Oh ok. Well, I still appreciate that RE2 source code :smile: . RE2 seems like a very complex game. It has a lot of junk in IMEM, which makes it very difficult to analyze.

World Driver Championship uses a modified version of the Zsort microcode (Mia Soccer 64). Confirmed by devs of the game in the past. I would be surprised that it would be easy to decipher it but I am not expert.

That's odd because I really couldn't see a resemblance in the RSP code. Anyway, since there's not much RSP microcode in WDC, it would actually be relatively easy to do. The hardest part will probably be dealing with RSP Yielding (which is probably the reason Gauntlet HLE gfx isn't so great right now). If anyone is actually interested in HLEing WDC, I could help out. Otherwise, I may just HLE it myself some day.

Or help out on finalizing the HLEzation of the gfx microcode. Seems not an easy task. I keep hoping though.

I'd say it's more time consuming rather than difficult. I'd have done it already if it was at the top of my priority list. Right now, performance is my top priority. Can't even play SD Hiryuu well enough, when not using a software renderer.

I'd like to see Turok and Zelda MM's HLE lighting fixed and also be able to play Last Legion, Rogue Squadron, and a few other non-HLEed games. Problem is that there are bigger issues, like no emulator core properly handling Factor 5 games.

Last Legion's microcode uses 2 microcode: 1 is the normal F3DEX (for background etc) and the other one is called T3DUX (as you can see in a debugger memory). This latter is certainly an extented version of the turbo3d one. That one should be easier.

Man I love Last Legion. I may look into that game after WDC. Only reason I'd even do WDC first is because there's not much microcode lol. I wonder why some of the microcode looks similar to Goldeneye's. What microcode does Goldeneye use? I know it uses SW 2.0G, but does it also use other ones too? I also enjoy Toukon Road, the music is nice.

[Gillou68310]

@LegendOfDragoon thanks for sharing your dumps collection ;-) I'm personally using mupen64plus-rsp-z64 in order to dump ucodes. It doesn't have a buit-in tool to do it but I changed the debugging code a bit in order to suit my needs, like you said :-)

I'd say it's more time consuming rather than difficult.

I agree with that, time is what you'll need the most when analysing disassembly. Also I need to familiarize myself with gfx ucodes. Starting with a small ucode is probably not a bad idea.

What is wrong with WDC?

[olivieryuyu]

WDC is an heavily customized ucode, without no doc available about it so Sergey does not know how it works and implement in HLE.

I am surprised it would be a simple gfx ucode. The gfx are amazing for this game so i would expect that it would be as complex as other gfx ucode. As well indeed it would need to ensure a proper RSP yielding. PJ 2.3 is the only emu managing this but it works only in LLE as in HLE the command is not implemented (expectation would be something similar (if not the same) as G_ZSENDSIGNAL & G_ZWAITSIGNAL in the Zsort microcode).

[AmbientMalice]

What is wrong with WDC?

Game's ucode is undocumented. Same ucode used in Stunt Racer 64, likel.y It also doesn't work on mupen64plus due to an RSP timing issue, which will present something of a problem, I imagine.

[Gillou68310]

Ok well, probably not the first gfx ucode to look at then.

[olivieryuyu]

Indeed. You could start with #268.

It uses F3DTEX/A. The game has some gfx bugs because this microcode is a slightly modified F3DEX microcode. So it nearly works but there is one ore two things not deciphered. The changes should concern only few commands. I guess that there would be no need to decipher all commands, only the ones which are not the same than the F3DEX.

You could check as well #99, #624, #663, #665

[LegendOfDragoon]

Sorry I kinda forgot that WDC and GB Tower don't work in mupen. Nevermind about doing those first then. I guess implementing HQVM might be a good start for HLE. Otherwise, I'd try doing T3DUX.

@LegendOfDragoon thanks for sharing your dumps collection ;-)

You're welcome :smile: .

PJ 2.3 is the only emu managing this but it works only in LLE as in HLE the command is not implemented (expectation would be something similar (if not the same) as G_ZSENDSIGNAL & G_ZWAITSIGNAL in the Zsort microcode).

I got those games working in 1964, but couldn't get it working in m64p-libretro. Is there any documentation on G_ZSENDSIGNAL & G_ZWAITSIGNAL?

[olivieryuyu]

https://n64squid.com/Nintendo%20Ultra64%20Programming%20Manual+Addendums.pdf

the Zsort is explained in the addendums.

[olivieryuyu]

@Gillou68310: short question about your work in RE2 : what does your implementation? you called it resize_bilinear.

Do you mean that it resize the background texture and apply a bilinear filter?

:)

[Gillou68310]

It loads the raw image data in rgb888 format from rdram (src_addr + offset) and resize it using bilinear interpolation, storing resized image back to rdram (dst_addr) in rgba1555 format. The background image is not processed in one piece but split in multiple parts that's why we have to deal with an offset.

[Gillou68310]

I started working on https://github.com/gonetz/GLideN64/issues/99, I'm already able to isolate specific GBI commands from disassembly but now I'm wondering on which command I need to focus on. Since @gonetz's hack in glide64 is located in the F3D_Vtx command I guess that's where I need to start looking. @gonetz could you confirm?

[gonetz]

Yes, it is load vertex, generation of texture coordinates in G_TEXTURE_GEN mode. gSPProcessVertex in my code. It is not the only problem with that game. The logo not only has wrong tex coords, it is also too bright. I compared color calculated with gSPLightVertex_default() and color calculated by RSP in LLE mode. To get correct color, intensity in gSPLightVertex_default should be 10 times less than it actually is.

[Gillou68310]

Ok thanks for the infos ;-)