Gliden64: 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 ;-)

[olivieryuyu]

"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"

It looks like the SPBgRectCopy or gSPBgRect1Cyc in SDEX microcode. Can be wrong though.

[Gillou68310]

Well data memory organization is not following the uObjScaleBg struct, so devs probably wrote a custom ucode like the fmv ucode. It's just a guess of course ;-)

[AmbientMalice]

Some testing will be needed of course, but in the meantime...

[olivieryuyu]

small question: does the issues fixed by the hack is due to ucode issues?

[gonetz]

No, had no particular issues with ucode. I described problems with this game and my solutions in my blog:
http://gliden64.blogspot.ru/2017/04/resident-evil-2.html?m=1

[gonetz]

Btw, @purplemarshmallow gave me an idea how to deal with background load without the hack. Special code need to be written anyway, but it can be reused for other games.

[AmbientMalice]

@gonetz Will this new method take long to implement? Also, will this general purpose method help resolve the various games that have overlapping buffers? Because if so, that's awesome.

[gonetz]

Yes, buffer copy has sense to implement as part of general strategy for overlapping buffers support. Overlapping buffers can not be supported without serious changes in current frame buffer emulation code. Thus, it will take long.

[purplemarshmallow]

I tried to implement it in GLideN64 some time ago. But I made no progress and gave up

[AmbientMalice]

It would be a good feature down the track, but in the meantime, the current implementation is an amazing demonstration of the benefits of GLideN64's new VI code. The emulation seems flawless. Glide64 was a hot mess with this game.

[AmbientMalice]

I notice that during certain camera angle changes, there's a flash of garbage onscreen. I assume this is a limitation of the hack?

[gonetz]

Yes. If VI_WIDTH register has incorrect value at time of background load, the load will be incorrect.

[loganmc10]

Am I doing something wrong? In the latest master things still look messed up for me:

This is with mupen64plus

My gliden64.log has a bunch of [GLideN64]: error - unknown ucode!!! messages

[Frank-74]

Mostly fine here, but I get the odd piece of background in front.

[AmbientMalice]

@Frank-74 Do you have shader cache on or off?

[Frank-74]

@AmbientMalice I have shader storage/cache on. I'll delete the cache and try again.
Just noticed this in the log too.
OpenGL Error: invalid operation (502)Error while writing shader with key key=0x00000000FF2FFFFF

Edit: Nope, deleted shader cache, and turned it off. Same parts of background are appearing in front.
I cannot use accurate N64 depth compare option (< OpenGL 4.3), is this the reason?

[loganmc10]

Using @Gillou68310 's re2 ucode patch for mupen64plus-rsp-hle fixes my issues. Is this something that Project64 already has implemented? Are you guys playing this in LLE or HLE mode?

@Gillou68310 is there a reason that re2 ucode patch hasn't been merged into mupen64plus-rsp-hle?

[gonetz]

@loganmc10 The game works in HLE, but default hle rsp for mupen64plus fails. cxd4 plugin works well.

@Frank-74 You need image textures support (OpenGL 4.3) for correct depth compare. N64 depth compare option is not required.

And yes, I forgot to up shader cache version again. Please clear shaders folder before use.

[loganmc10]

When I try cxd4 it looks like this for me:

[loganmc10]

I got cxd4 working, I had to set DisplayListToGraphicsPlugin to true

[loganmc10]

The game works in HLE, but default hle rsp for mupen64plus fails. cxd4 plugin works well.

Actually, looking at Project64's code, it doesn't fully work in HLE. It's just that Project64's RSP can fall back to LLE if the HLE ucode isn't found. This is similar to what DisplayListToGraphicsPlugin does in the cxd4 plugin I believe.

[LegendOfDragoon]

Is this something that Project64 already has implemented? Are you guys playing this in LLE or HLE mode?

Project64's RSP just forces LLE for that certain scenario, since HLE graphics plugins didn't emulate it.

If Gillou68310's code works for this, then shouldn't it be ported to GLideN64 as well? That way, RSP plugins wouldn't need to use a workaround and force LLE.

[Frank-74]

N64 depth compare option is not required.

Even with shader storage turned off, I still get the same background tiles appearing in front of the 3d models. I've toggled just about every option. Intel HD graphics, Windows 8.1.

Offtopic, for some reason, CPU Idle in PJ64 stays at 0.00% with VSync turned on, and audio thread suffers badly here. VSync turned OFF and Idle goes back to ~50-75%.

[loganmc10]

I cannot use accurate N64 depth compare option (< OpenGL 4.3), is this the reason?

This is why it doesn't work @Frank-74 , though it doesn't require the N64 depth compare option, it uses the same OpenGL features (Image Textures), and your GPU doesn't support it.

[Frank-74]

@loganmc10

though it doesn't require the N64 depth compare option, it uses the same OpenGL features (Image Textures), and your GPU doesn't support it.

Thanks for clarification. From Gonetz reply, I thought it should work without >=4.3, if it didn't need accurate N64 depth compare. Now I know, cheers. My GFX only supports upto 4.0.

I probably should get something written into the log if it's not supported? I get no log at the moment, no errors...

[loganmc10]

I probably should get something written into the log if it's not supported? I get no log...

You should get a log entry if you try to enable N64 Depth Compare and it's not supported, but yes, there is no log for the other things, like the fog in Beetle Adventure racing, or this case.

[Frank-74]

Just to add, your contributions this past few weeks have greatly helped Intel users (myself included).
To @loganmc10 and @fzurita
Have high hopes for the awaiting threaded GL, which Intel has the biggest problem with managing. Thank you.

[Gillou68310]

@loganmc10 the main reason I worked on the ucode in the first place was to be able to run the game at full speed on mobile devices. Since the game was unplayable due to graphical issues I decided not to merge my work until those issues are fixed. As a side note the FMV ucode still needs to ported for full HLE support.

@gonetz if I understand correctly the game will not work properly on GLES < 3.1 devices due to lack of ImageTexture support? Is there anything we can do about that?

[gonetz]

Is there anything we can do about that?

Yes. Depth compare needs zlut texture. It is currently image texture, but it can be ordinary texture as well, because its content never changes. Some code need to be refactored.

[Gillou68310]

Thanks for the info ;-)

[fzurita]

I tried an Adreno device with GLES 3.2 and this doesn't seem to work. All the backgrounds render in front, no 3D geometry shows. This works fine with Glide64 on android, so I know the non-video plugin settings are correct.

Edit: It's probably bugging drivers. Adreno has issues with N64 depth compare as well.

[Gillou68310]

I finally found some time to implement the video decoding ucode!
RE2 should now be completely playable in HLE!

Here's the code:
https://github.com/mupen64plus/mupen64plus-rsp-hle/pull/53

[gonetz]

Cool! How it works today? Does RSP plugin switches to LLE to decode video?

[olivieryuyu]

Woa nice!!!

should it be implemented in the graphic plugin or in the RSP plugin?

I know that the jpeg ucode were also reversed but I wonder why it is not in the graphic plugin instead of the RSP plugin.

[Gillou68310]

Cool! How it works today? Does RSP plugin switches to LLE to decode video?

Right now you need to use rsp-cxd4 in HLE mode. It means that display lists are send to gfx plugin but other ucodes are processed in LLE by rsp plugin.

Woa nice!!!

should it be implemented in the graphic plugin or in the RSP plugin?

I know that the jpeg ucode were also reversed but I wonder why it is not in the graphic plugin instead of the RSP plugin.

Now that you talk about it I think this could definitely be moved to the gfx plugin!
Both resize_bilinear_task and decode_video_frame_task are referenced as gfx tasks (TASK_TYPE == 1).
Right now we are using a hack inside the rsp plugin to detect that those tasks are not display lists to be processed so we can execute them into the rsp plugin.

The only thing that will be a bit confusing is that the ProcessDlist API will process both display list and non display list ucodes.

@gonetz what do you think?

[Gillou68310]

I know that the jpeg ucode were also reversed but I wonder why it is not in the graphic plugin instead of the RSP plugin.

jpeg ucodes are not referenced as gfx tasks thus they are not forwarded to the gfx plugin. That's why they are processed within the rsp plugin.

[Gillou68310]

@gonetz which command is used to draw video frame? I'd like to check the address of the buffer in RDRAM!

[theboy181]

didn't realize that the RSP was so crafty. Does it make things more difficult when trying to figure out if the RSP has stepped into LLE mode?

[Gillou68310]

@gonetz which command is used to draw video frame? I'd like to check the address of the buffer in RDRAM!

Ok nevermind video are not drawn using Dlist.
Like I was expecting the framebuffer address (REG.VI_ORIGIN) is constantly switching between 2 addresses 0x0063e418 and 0x0076a418.
Right now only the buffer at the first address is populated, this is done by the decode_video_frame task. The buffer at the second address is populated by another ucode which is not reversed engineered yet.

So work is not finished here.

[gonetz]

Like I was expecting the framebuffer address (REG.VI_ORIGIN) is constantly switching between 2 addresses 0x0063e418 and 0x0076a418.

Yes, graphics plugin just renders buffers in RDRAM to screen during video. No display lists send to it at this moment.

[Gillou68310]

Thanks ;-)
BTW do you have any opinion about moving re2's ucodes from rsp to gfx plugin?

[gonetz]

You mean, video decoding ucodes?
Why do that? It will not work faster or with better quality.

[Gillou68310]

Both resize_bilinear_task and decode_video_frame_task are referenced as gfx tasks (TASK_TYPE == 1).
Right now we are using a hack inside the rsp plugin to detect that those tasks are not display lists to be processed so we can execute them into the rsp plugin.

The only thing that will be a bit confusing is that the ProcessDlist API will process both display list and non display list ucodes.

The main reason is to get rid of hacks.

[tony971]

Outside perspective: fix whatever is in your ability to fix without relying on outside sources. It's easier on everyone to say "RE2 works with GLideN64" than to say "RE2 works with GLideN64 and this specific RSP plugin"

[Gillou68310]

good point

[gonetz]

Hmm, if I understand things right, adding this ucode to GLideN64 will cause "RE2 works with GLideN64 and this specific RSP plugin" situation, because we will need specific plugin, which will not do that job itself but send it to graphics plugin. Correct me if I'm wrong.

I don't see a problem to add another specific ucode to the project. Especially, when it is already implemented.

[Gillou68310]

That's correct ;-)

[Gillou68310]

@gonetz do you already have an idea on how you would like to integrate those ucodes into GLideN64 or do you want me to do it?

[theboy181]

@gonetz what is the goal of GLideN64 accuracy, performance, or both?

Reason I ask is I can’t seem to get a handle on what is an acceptable suggestion, or PR guidelines.

Some people talk about hacks as a dirty word then others say let’s just add a hack.

Would it be safer to maintain GLideN64 as hack free, and have it branch into other experiments?

I want hacks and enhancements available, but on the other hand I would like clean code that respects the HW and acts how the N64 is designed.

If the rsp is expected to do a job it should be allowed to do that job. Rsp developers should get some input on what the outlines of the Rsp should be.

My suggestion is to place some parameters on GLideN64 culture.

I have never expected your plugin to replace the Rsp, or core features the emulator should have.

[gonetz]

@Gillou68310 I would prefer to get ready solution from you :)

@theboy181 Actually, when graphics plugin works in HLE mode, it does both RSP and RDP work. Microcode implementation is RSP work. RSP plugin takes display list from CPU and sends it as is to graphics plugin. It works as proxy in that case. 1964 can work without RSP plugin in HLE mode.
Plugin does not emulate RSP only in LLE mode.

Adding new ucode is not a hack, if it is not sound processing of course. If graphics plugin emulates all RSP work for graphics ucode, it can do the same for video decoding ucode. I'm not sure how it should be implemented. I hope that Gillou68310 will solve that, but I'm ready to help.

[Gillou68310]

@gonetz It looks like project64 is also using a hack to avoid those ucodes to be send to the gfx plugin. So right now even if we move the ucodes to GLideN64 they won't be used by project64. The same is true for cxd4 rsp plugin.

[olivieryuyu]

It is an interesting debate to know whether graphic ucodes should be dealt with graphic plugins nowadays.

In my opinion, as N64 emulation started to have HLE graphic plugins, those latters should support all kind of microcodes, including FMV ones (RE2 and HVQM are the only ones which I am aware of).

It should be the same for jpeg in my opinion.

Anyway first it would be good to reverse engineered them and then we may see what is the best way to implement them.

[loganmc10]

GLideN64 isn't the default plugin for Project64, so it's unlikely that Project64 will forward these RE2 tasks to the GFX plugins, since it would break Jabo and Glide64, which are the bundled plugins. Unless the RSP has some kind of if gfx.plugin == GLideN64: forward task; else: don't I don't think it's going to happen.

Just thinking practically, it probably makes sense to have the RSP plugins handle these (the RE2) tasks.

[AmbientMalice]

The game is a catastrophic train wreck on Jabo's. I played through the game once on Jabo's and I have no idea what I was thinking in retrospect. RE2 is kinda special because it literally only runs on Glide64 (terribly), GLideN64 (less terribly), and Angrylion's (well). No other plugins are an option. Jabo's is broken beyond all belief.

Is there any particular reason why this couldn't be backported to Glide64?

[olivieryuyu]

We are in a weird situation where we accommodate a hack from PJ64. PJ64 should have the option to do the right things according to the standard it has imposed in the past.

[gonetz]

@olivieryuyu should it be closed?

[olivieryuyu]

we could, however then I would then open 2 new tickets:

1) for HLE of FMV
2) purplemarshmallow idea of copy buffers and recalculating texel position in copy shader.

[gonetz]

for HLE of FMV

Is it ready to add? I thought that changes on emulator / RSP plugin side needed first.

purplemarshmallow idea of copy buffers and recalculating texel position in copy shader.

Ok

[olivieryuyu]

_Is it ready to add? I thought that changes on emulator / RSP plugin side needed first._

That is still on debate actually :)

_purplemarshmallow idea of copy buffers and recalculating texel position in copy shader._

Ok so should i open a new ticket for this?

[gonetz]

Yes. It will be reminder for me.

[olivieryuyu]

ok let's close this ticket and create two other tickets, it would be cleaner than the current ticket.