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

[olivieryuyu]

nearly nothing works :(

[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.