[Feature Request] Add support for frame buffer extension API

[gonetz]

Need to implement the following extension to Zilmar's specs:

/** Function: FrameBufferRead Purpose: This function is called to notify the dll that the frame buffer memory is beening read at the given address. DLL should copy content from its render buffer to the frame buffer in N64 RDRAM DLL is responsible to maintain its own frame buffer memory addr list DLL should copy 4KB block content back to RDRAM frame buffer. Emulator should not call this function again if other memory is read within the same 4KB range input: addr rdram address val val size 1 = wxUint8, 2 = wxUint16, 4 = wxUint32 output: none ***/ EXPORT void CALL FBRead(wxUint32 addr)

/** Function: FrameBufferWriteList Purpose: This function is called to notify the dll that the frame buffer has been modified by CPU at the given address. input: FrameBufferModifyEntry plist size = size of the plist, max = 1024 output: none **/ EXPORT void CALL FBWList(FrameBufferModifyEntry *plist, wxUint32 size)

/** Function: FrameBufferWrite Purpose: This function is called to notify the dll that the frame buffer has been modified by CPU at the given address. input: addr rdram address val val size 1 = wxUint8, 2 = wxUint16, 4 = wxUint32 output: none ***/ EXPORT void CALL FBWrite(wxUint32 addr, wxUint32 size)

/**** Function: FBGetFrameBufferInfo Purpose: This function is called by the emulator core to retrieve frame buffer information from the video plugin in order to be able to notify the video plugin about CPU frame buffer read/write operations

size: = 1 byte = 2 word (16 bit) <-- this is N64 default depth buffer format = 4 dword (32 bit)

when frame buffer information is not available yet, set all values in the FrameBufferInfo structure to 0

input: FrameBufferInfo pinfo[6] pinfo is pointed to a FrameBufferInfo structure which to be filled in by this function output: Values are return in the FrameBufferInfo structure Plugin can return up to 6 frame buffer info ****/ EXPORT void CALL FBGetFrameBufferInfo(void *p)

[AmbientMalice]

Try 1964 think this is Mupen's fault

On 1964, the numbers keep disappearing. Mupen is much worse, but 1964 is still wrong.

[gonetz]

Yep, Dr Mario pills do not work. It seems I broke it somehow before commit to git.

Update: the situation is even worse. Debug build works ok, release does not to work.

[gonetz]

What kind of patch should I provide? Should I introduce the new setting as suggested?

I don't quite understand, what you suggest. I need updated .cpp to compare before-after.

[gonetz]

The problem with copyFromRDRAM in release build is really weird. It is not directly related to FBInfo changes. I found, that if VI_UpdateScreen() is called from a virtual method, copyFromRDRAM does not work properly. More exactly, the function works correct, but the result is wrong. No idea, what happens.

[purplemarshmallow]

I don't quite understand, what you suggest. I need updated .cpp to compare before-after.

Here is a .cpp you can compare before/after VI.zip

[gonetz]

Here is a .cpp you can compare before/after

Thanks! Ok, I'll disable that check if emulator provides FBInfo support.

[gonetz]

I found a workaround for release build. Now should work properly.

New binary https://drive.google.com/file/d/0B0YqMPjGo3B2UFFDb29fUGR3U0U/view?usp=sharing

[AmbientMalice]

Jet Force Gemini numbers look a lot better now. Game crashes with auxiliary FB to RAM enabled, but that's a side issue.

Quake II loadscreen doesn't work. (Not that it has so far.) Major League Baseball now has heavily embossed splash screens with 1964.

Something has gone very wrong with mupen64 and CPU FB writes.

[gonetz]

Jet Force Gemini numbers look a lot better now.

I can say that now it works correct :)

Game crashes with auxiliary FB to RAM enabled, but that's a side issue.

Does it work with master? If yes, it is regression, which must be fixed.

Quake II loadscreen doesn't work.

Forget about QII. Plugin does not get the help from emulator here.

Major League Baseball now has heavily embossed splash screens with 1964.

Yep, it is strange problem.

Something has gone very wrong with mupen64 and CPU FB writes.

Is it Superman again?

[AmbientMalice]

Is it Superman again?

Yes.

Does it work with master? If yes, it is regression, which must be fixed.

I don't think aux FB to RAM is present in the master? So yea, it's not an issue with master.

[gonetz]

I don't think aux FB to RAM is present in the master?

It presents, but don't have GUI handle. You may manually enable it in .ini file.

[purplemarshmallow]

When I tested Biofreaks with Mupen my gfx driver crashed. The first transition looks correct but then the emulator crashes and it says my driver had to be restored

[olivieryuyu]

tested with 1964.

So compared to Glide64, fb notification seems to way better.

However well as soon as notification is done, it is very very slow (99% core impact)

As well some color of the framebuffer part seems incorrect.

i.e. Bakushou Jinsei 64 - Mezease! Resort Ou

Seems how clearer a part of the screen appears. I cannot see fading effects.

[AmbientMalice]

tested with 1964.

Normal 1964 is buggy, assuming you used it. You have to use a custom build. https://github.com/gonetz/GLideN64/issues/808#issuecomment-173846957

[olivieryuyu]

1964 can be buggy, still we need to check how the plugin acts.

Here same game with mupen 5.1

It is faster but we have missing gfx with this emulator!

[gonetz]

@olivieryuyu Official release of 1964 is incorrect in FBInfo support, that's why it is slow: https://github.com/gonetz/GLideN64/issues/808#issuecomment-172302227

The problem with Bakushou Jinsei 64 - Mezease! Resort Ou looks like general problem of GLideN64 and 2D. I already saw similar issue, don't remember the game though.

[purplemarshmallow]

Something else is wrong with Bakushou Jinsei 64 - Mezease! Resort Ou If you disable read color buffer by chunks you only get some colored dots

[olivieryuyu]

micro machine 64: see the blue square at the bottom. Seems the same issue

Is it a mupen64 error?

[olivieryuyu]

it doesn't work with Mickey's Speedway USA

[olivieryuyu]

Mia Soccer 64: weird bug: the transition effects work & the title screen appears, but the titel screen is never cleared from the frame buffer is reused again & again when a new transition effect occurs.

[olivieryuyu]

works very well with Doraemon - Mittsu no Seireiseki

purplemarshmallow: now it doesn't work properly with the normal framebuffer, even in sync mode. Looks like a regression :(

[olivieryuyu]

works well with famista 64

[olivieryuyu]

oops

World Cup 98 is buggy with fb notification.

[gonetz]

@purplemarshmallow "When I tested Biofreaks with Mupen my gfx driver crashed. The first transition looks correct but then the emulator crashes and it says my driver had to be restored"

Biofreaks with Mupen works stable for me.

[gonetz]

@AmbientMalice "Something has gone very wrong with mupen64 and CPU FB writes."

The game's logo works strange. The game reads and writes to the same buffer and to other buffer. I'm not sure what is going on. Something peculiar.

[gonetz]

@olivieryuyu > it doesn't work with Mickey's Speedway USA

It works with (E) version. FB effects in (U) version do not work with Mupen64, but ok with PJ64. This regression is hardly related to FBInfo feature. Nothing changes if I use dummy FBInfo functions.

Also, pause screen in Mickeys has the same issue with garbage on the right, as on your screens from Bakushou Jinsei 64 - Mezease! Resort Ou. Just to note.

[gonetz]

@olivieryuyu

micro machine 64: see the blue square at the bottom. Seems the same issue Is it a mupen64 error?

Yes. Fixed version of 1964 works correct with that game.

[gonetz]

@olivieryuyu

works very well with Doraemon - Mittsu no Seireiseki now it doesn't work properly with the normal framebuffer, even in sync mode. Looks like a regression

Text in the game needs copy from RDRAM (render buffer as texture). It works ok with PJ64

[weinerschnitzel]

Does the banjo kazoo fix affect superman64?

[gonetz]

No. superman64 logo does not work with or without BK fix.

[weinerschnitzel]

I got some time to test and found that Superman64 FBInfo worked improperly for mupen64, 1964, and 1964 with filtered FBReads. My build looked more complete and less flashy as the other 2, but I'm getting the same issues as @AmbientMalice. I think the green color has intensified, and it looks like the Titus logo is being written over itself again and again without being cleared between frames.

Banjo Kazooie freezes come back with Mupen and vanilla 1964.

The full screen puzzle transition in BK is broken (when using filtered FBReads) and so are the TV screens in MK64 and the Bomberman64 intro (in 1964 1.1, and my filtered build.)

Correction: Bomberman64 has FBRead misses in intro. Mupen's fault.

EDIT: I had a wrong build of GLideN64 in my Mupen64 plugin folder. Test results updated.

I'm on Intel, disabling FBInfo fixes effects.

[gonetz]

@weinerschnitzel thanks, I'll check the issues.

[gonetz]

@weinerschnitzel I can't reproduce the issues you reported.

@olivieryuyu Yes, World Cup 98 is buggy with fb notification.

@purplemarshmallow "ingame the CPU draws many things, lines, squares around enemies and also the rain. This does not work at the moment." Yes. Strange. Update: found why.

[weinerschnitzel]

I have an amd machine i will continue with testing on and see if it is in fact an issue with intel

[purplemarshmallow]

"ingame the CPU draws many things, lines, squares around enemies and also the rain. This does not work at the moment." Yes. Strange. Update: found why.

Why?

[gonetz]

Because at the moment on FBWrite the current buffer is an auxiliary buffer. drawTexturedRect uses sizes of current buffer and works incorrect. This is easy to fix.

What is hard, or may be impossible to fix is Banjo Kazzoie freeze issue. I explained, what happens in that game: https://github.com/gonetz/GLideN64/issues/808#issuecomment-162223042

Unfortunately, suggested solution not always work. It does not work with 1964. FBWrite and FBRead work in different threads, and while FBWrite detects the problem, FBRead has time to spoil the data in the buffer. Threads synchronization causes heavy slowdown when FBWrite is used because it is called many times per frame.

[purplemarshmallow]

Because at the moment on FBWrite the current buffer is an auxiliary buffer. drawTexturedRect uses sizes of current buffer and works incorrect. This is easy to fix.

This is also the problem here I guess: #603

[gonetz]

Most likely it is.

[purplemarshmallow]

What is hard, or may be impossible to fix is Banjo Kazzoie freeze issue. I explained, what happens in that game:

808 (comment)

Unfortunately, suggested solution not always work. It does not work with 1964. FBWrite and FBRead work in different threads, and while FBWrite detects the problem, FBRead has time to spoil the data in the buffer. Threads synchronization causes heavy slowdown when FBWrite is used because it is called many times per frame.

What if FBread is skipped if there are no dlists?

[gonetz]

What if FBread is skipped if there are no dlists?

You may try. I'm afraid, puzzle effect will be lost.

[gonetz]

I have pushed fix for JFG crosshair.

New binary: https://drive.google.com/file/d/0B0YqMPjGo3B2SFpIcUhVbzVYSHM/view?usp=sharing

pass: test

[AmbientMalice]

Seems to work perfectly with mupen64, but with mupen64plus, the JFG crosshairs now render, but incorrectly. And also only when looking in certain directions. Coincidentally, these directions correspond to the square doing its thing in the corner with the old system. Boxes around enemies don't work, either.

[purplemarshmallow]

You may try. I'm afraid, puzzle effect will be lost.

I will try. If it does not help one good solution is to sync everything on 1964's side and have just one thread for fbwrite and fbread.

[gonetz]

@AmbientMalice FBWrite does not work well with mupen64plus indeed. Dr.Mario looks bad also. I hardly can do anything about it.

@purplemarshmallow It can be not so easy. If FBRead will be called before FBWrite, RDRAM will be broken. FBRead is called when CPU needs data from RDRAM, thus FBRead must read data immediately. It would be much more optimal for the plugin to get list of all necessary buffer reads and writes, but it is hardly possible.

[gonetz]

@purplemarshmallow

This code breaks rain in JFG with PJ64:

        else if (!fbInfo.isSupported() && !pBuffer->isValid()) {
            gDP.changed |= CHANGED_CPU_FB_WRITE;
            if (config.frameBufferEmulation.copyToRDRAM == 0)
                pBuffer->copyRdram();
        }

Do you have a suggestion, how to fix it and not break anything else?

[purplemarshmallow]

Do you have a suggestion, how to fix it and not break anything else?

Also because of #867 I think the best thing is to add an ignore CFB option and disable this code for some games.

[LegendOfDragoon]

This code breaks rain in JFG with PJ64:

Does it break rain if you use CPU interpreter?

[gonetz]

@purplemarshmallow The set of options, which added to solve some particular issues turns the plugin into tangled system of crutches and props. The same problem plagued Glide64 development, where any step may cause chain of regressions. Unfortunately, I don't see a good alternative yet.

@LegendOfDragoon The rain issue should not depend on CPU emulation method. The problem is on plugin's side: CPU writes rain drops to current buffer. Plugin detects that buffer has changed outside, thus it is invalid and plugin must show the picture written by CPU. The picture contains only rain drops.

[AmbientMalice]

The set of options, which added to solve some particular issues turns the plugin into tangled system of crutches and props.

I agree completely. Look at what happened to Glide64 having to turn off the framebuffer to get a whole bunch of games rendering. That was unacceptable. Similarly, Toy Story 2's broken rendering could be "fixed" in GLideN64 by turning off the framebuffer, but this would be a wholly unacceptable solution.

On the issue of fbinfo crashing games, it may be necessary (temporarily) to fall back on per-frame copies in scenarios where fbinfo is unstable, which hopefully won't be many.

[LegendOfDragoon]

@purplemarshmallow if you're interested in figuring out how to speed up LLE performance in GLideN64, a great game to test is Tower & Shaft. It hardly uses the RSP, yet LLE is significantly slower than HLE with GLideN64. Although the game does not work on PJ64 w/o using a workaround, so you're better off using 1964 or Mupen for testing.

@gonetz I see. Just wanted to make sure, because Protect Memory still is not fixed for JFG.