[Feature Request] Add support for frame buffer extension API #808

Closed
gonetz opened this Issue Nov 23, 2015 · 154 comments

Comments

Projects
None yet
9 participants
@gonetz
Owner

gonetz commented Nov 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Nov 23, 2015

Contributor

Gonetz, shouldn't this be posted on the PJ64 github page?

Contributor

AmbientMalice commented Nov 23, 2015

Gonetz, shouldn't this be posted on the PJ64 github page?

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Nov 23, 2015

Owner

Nope. These are gfx plugin API functions. Would be great to see support of them from PJ64 side.

Owner

gonetz commented Nov 23, 2015

Nope. These are gfx plugin API functions. Would be great to see support of them from PJ64 side.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Nov 23, 2015

Contributor

I see your point. Does mupen64plus have all the API features you need, or will work have to be done there, too?

Contributor

AmbientMalice commented Nov 23, 2015

I see your point. Does mupen64plus have all the API features you need, or will work have to be done there, too?

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Nov 23, 2015

Owner

I don't know about mupen64plus. Please test and let me know.
I tested with Mupen64 only.

Owner

gonetz commented Nov 23, 2015

I don't know about mupen64plus. Please test and let me know.
I tested with Mupen64 only.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Nov 23, 2015

Owner

WIP code pushed to FBinfo feature branch:

https://github.com/gonetz/GLideN64/tree/FBInfo

phew!

Owner

gonetz commented Nov 23, 2015

WIP code pushed to FBinfo feature branch:

https://github.com/gonetz/GLideN64/tree/FBInfo

phew!

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Nov 23, 2015

Contributor

I did some tests (Mupen 0.5.1)
Zelda OOT and MM: sometimes coronas disappear behind walls but most of the time it does not work.
Banjo Kazooie: crash at intro during jigsaw effect. The image looks weird
Pokemon Snap: crash at title screen
Bomberman 64: images during intro show up but they look strange
1

Contributor

purplemarshmallow commented Nov 23, 2015

I did some tests (Mupen 0.5.1)
Zelda OOT and MM: sometimes coronas disappear behind walls but most of the time it does not work.
Banjo Kazooie: crash at intro during jigsaw effect. The image looks weird
Pokemon Snap: crash at title screen
Bomberman 64: images during intro show up but they look strange
1

@Papermanzero

This comment has been minimized.

Show comment
Hide comment
@Papermanzero

Papermanzero Nov 23, 2015

You can use the newest builds from mupen64plus from here:
https://bitbucket.org/ecsv/mupen64plus-mxe-daily/overview

You can use the newest builds from mupen64plus from here:
https://bitbucket.org/ecsv/mupen64plus-mxe-daily/overview

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Nov 24, 2015

Owner

I know about issues, it is WIP. Tell me what I don't know, namely why it does not work? I had not enough time for debug.

Owner

gonetz commented Nov 24, 2015

I know about issues, it is WIP. Tell me what I don't know, namely why it does not work? I had not enough time for debug.

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Nov 24, 2015

Contributor

When I tested with 1964 it worked as good but really slow. I guess 1964 can call the same address multiple times. With a check for duplicate calls it should work with 1964 as well

Contributor

purplemarshmallow commented Nov 24, 2015

When I tested with 1964 it worked as good but really slow. I guess 1964 can call the same address multiple times. With a check for duplicate calls it should work with 1964 as well

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Nov 24, 2015

Contributor

So when using mupen with this branch, should FB to RDRAM and such be enabled or disabled? I assume disabled.

edit:

Unfortunately, I get a bunch of build errors, and can't test this. Using VS2013.

Contributor

AmbientMalice commented Nov 24, 2015

So when using mupen with this branch, should FB to RDRAM and such be enabled or disabled? I assume disabled.

edit:

Unfortunately, I get a bunch of build errors, and can't test this. Using VS2013.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Nov 24, 2015

Owner

FB to RDRAM and such should be disabled.
I use VS2013 also.

Owner

gonetz commented Nov 24, 2015

FB to RDRAM and such should be disabled.
I use VS2013 also.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Nov 25, 2015

Contributor

Build errors fixed by 004b882 but nothing seems to work. Castlevania menu FB effect don't work, for example.

Contributor

AmbientMalice commented Nov 25, 2015

Build errors fixed by 004b882 but nothing seems to work. Castlevania menu FB effect don't work, for example.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Nov 25, 2015

Owner

This is WIP, alpha version of the feature. I published it for devs who want to dig the code and find what is wrong in it and how it can be fixed. I know about issues, no need to report about them atm.

Owner

gonetz commented Nov 25, 2015

This is WIP, alpha version of the feature. I published it for devs who want to dig the code and find what is wrong in it and how it can be fixed. I know about issues, no need to report about them atm.

@weinerschnitzel

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Dec 5, 2015

@gonetz I see that you are making some more commits. Could you vaguely point out internal issues you already know about that need attending? That would give the rest of us clues as to what to look for

@gonetz I see that you are making some more commits. Could you vaguely point out internal issues you already know about that need attending? That would give the rest of us clues as to what to look for

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Dec 5, 2015

Contributor

In Bomberman64 the bottom of the image is missing. This has been investigated and it happens because Mupen64 misses some fb reads. This implementation is very accurate and if the emulator provides wrong information the result will be wrong

I tested more games (Mupen 0.5.1). I need to find out is the problem on Mupen's side or in GLideN64

  • Glover2: strange black stripes inside the image. bottom is missing like bomberman.
  • Castlevania/Castlevania2: fully working
  • Mario Kart: black square inside the monitor
  • Banjo Kazooie jigsaw effect: The result is random. Sometimes the bottom of the image is missing like Bomberman. Sometimes the whole image is buggy and broken. In both cases the emulator crashes afterwards.
  • Ocarina of Time: Sometimes coronas work correctly sometimes coronas are visible through walls.
  • Jet force gemini: The top of the monitors is buggy.
  • Majora's Mask: camera shows nothing.
  • Conker/Mickey's speedway: pause menu background is completely missing
  • Mario Tennis: fb read is often called when the pause menu is opened and causes a slowdown.
  • Shadowman: pause menu takes a long time to open. Sometimes the whole image is missing sometimes the bottom is missing like Bomberman.
  • 1080: freeze at intro, I can't get ingame.
  • Pokemon Snap: freeze at title screen
  • Mini Racers: fully working
  • Clay Fighters sc: bottom of the image is missing like Bomberman
  • bakushou jinsei 64: not working but strange dots appear inside the image
  • Heiwa Pachinko World 64: bottom of the image is missing like Bomberman

There is a bug introduced in GLideN64. Buffers can be copied to the wrong destination. It's very noticeable if you enable copy auxiliary and test Pokemon Stadium games.

Contributor

purplemarshmallow commented Dec 5, 2015

In Bomberman64 the bottom of the image is missing. This has been investigated and it happens because Mupen64 misses some fb reads. This implementation is very accurate and if the emulator provides wrong information the result will be wrong

I tested more games (Mupen 0.5.1). I need to find out is the problem on Mupen's side or in GLideN64

  • Glover2: strange black stripes inside the image. bottom is missing like bomberman.
  • Castlevania/Castlevania2: fully working
  • Mario Kart: black square inside the monitor
  • Banjo Kazooie jigsaw effect: The result is random. Sometimes the bottom of the image is missing like Bomberman. Sometimes the whole image is buggy and broken. In both cases the emulator crashes afterwards.
  • Ocarina of Time: Sometimes coronas work correctly sometimes coronas are visible through walls.
  • Jet force gemini: The top of the monitors is buggy.
  • Majora's Mask: camera shows nothing.
  • Conker/Mickey's speedway: pause menu background is completely missing
  • Mario Tennis: fb read is often called when the pause menu is opened and causes a slowdown.
  • Shadowman: pause menu takes a long time to open. Sometimes the whole image is missing sometimes the bottom is missing like Bomberman.
  • 1080: freeze at intro, I can't get ingame.
  • Pokemon Snap: freeze at title screen
  • Mini Racers: fully working
  • Clay Fighters sc: bottom of the image is missing like Bomberman
  • bakushou jinsei 64: not working but strange dots appear inside the image
  • Heiwa Pachinko World 64: bottom of the image is missing like Bomberman

There is a bug introduced in GLideN64. Buffers can be copied to the wrong destination. It's very noticeable if you enable copy auxiliary and test Pokemon Stadium games.

@LegendOfDragoon

This comment has been minimized.

Show comment
Hide comment
@LegendOfDragoon

LegendOfDragoon Dec 5, 2015

@purplemarshmallow what about 1964? Is it missing on that emulator as well?

@purplemarshmallow what about 1964? Is it missing on that emulator as well?

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Dec 5, 2015

Contributor

I did some testing with 1964. With 1964 there's a big slowdown during CPU reads. Does not happen with Mupen64.
Mario Kart: Correct image but really slow
Bomberman64: Correct image but really slow
Jet force gemini: correct monitors but slow
Banjo Kazooie: crash. Crashes with both 1964 and Mupen so there's likely a problem on GLideN64's side.

Contributor

purplemarshmallow commented Dec 5, 2015

I did some testing with 1964. With 1964 there's a big slowdown during CPU reads. Does not happen with Mupen64.
Mario Kart: Correct image but really slow
Bomberman64: Correct image but really slow
Jet force gemini: correct monitors but slow
Banjo Kazooie: crash. Crashes with both 1964 and Mupen so there's likely a problem on GLideN64's side.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Dec 5, 2015

Owner

Looks like 1964 has better support for FB extension. If it works, it works correct.
Mupen64 misses many fb reads, thus resulted images have black areas.

Owner

gonetz commented Dec 5, 2015

Looks like 1964 has better support for FB extension. If it works, it works correct.
Mupen64 misses many fb reads, thus resulted images have black areas.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Dec 5, 2015

Owner

Banjo Kazooie: crash. Crashes with both 1964 and Mupen so there's likely a problem on GLideN64's side.

Alas, it's not GLideN64 bug. It is problem of FBInfo conception.

The problem happens when the game needs to read the current color buffer for the puzzle effect.
At this moment only color buffer data is necessary. Depth buffer data is not used and CPU uses that memory area for its own needs. CPU writes something to that area and emulator sends bunch of FBWrite notifications to depth buffer area. Then CPU starts to read that data, and emulator sends FBRead notifications from depth buffer. The plugin reads the depth buffer from video card and writes it to RDRAM. Thus, the data written to depth buffer by CPU becomes broken and the game hangs. When I disable depth buffer writes, the game goes forward and the puzzle effect works (with a black line, but works).

I think that particular situation can be fixed: if game does writes and reads to the same buffer then do nothing.

Owner

gonetz commented Dec 5, 2015

Banjo Kazooie: crash. Crashes with both 1964 and Mupen so there's likely a problem on GLideN64's side.

Alas, it's not GLideN64 bug. It is problem of FBInfo conception.

The problem happens when the game needs to read the current color buffer for the puzzle effect.
At this moment only color buffer data is necessary. Depth buffer data is not used and CPU uses that memory area for its own needs. CPU writes something to that area and emulator sends bunch of FBWrite notifications to depth buffer area. Then CPU starts to read that data, and emulator sends FBRead notifications from depth buffer. The plugin reads the depth buffer from video card and writes it to RDRAM. Thus, the data written to depth buffer by CPU becomes broken and the game hangs. When I disable depth buffer writes, the game goes forward and the puzzle effect works (with a black line, but works).

I think that particular situation can be fixed: if game does writes and reads to the same buffer then do nothing.

@LegendOfDragoon

This comment has been minimized.

Show comment
Hide comment
@LegendOfDragoon

LegendOfDragoon Dec 5, 2015

Mario Kart: black square inside the monitor

It worked fine with Glide64 Final when I tested that a while back on Mupen64 0.5.

Mario Kart: Correct image but really slow

Slow as in < 60? If that's the case, then there's something wrong.

Mario Kart: black square inside the monitor

It worked fine with Glide64 Final when I tested that a while back on Mupen64 0.5.

Mario Kart: Correct image but really slow

Slow as in < 60? If that's the case, then there's something wrong.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Dec 5, 2015

Owner

It worked fine with Glide64 Final when I tested that a while back on Mupen64 0.5.

Forget about Glide64. I made very simple and rough support for FBInfo in it. GLideN64 works as described in API. Problems with image are most likely result of error on emulator side. At least Bomberman and Mario Kart are such cases.

< Slow as in < 60?

yes, sometimes it is really slow.

Owner

gonetz commented Dec 5, 2015

It worked fine with Glide64 Final when I tested that a while back on Mupen64 0.5.

Forget about Glide64. I made very simple and rough support for FBInfo in it. GLideN64 works as described in API. Problems with image are most likely result of error on emulator side. At least Bomberman and Mario Kart are such cases.

< Slow as in < 60?

yes, sometimes it is really slow.

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Dec 5, 2015

Contributor

Alas, it's not GLideN64 bug. It is problem of FBInfo conception.

I don't think so. I can think of a good solution. The gfx plugin controls it. The gfx plugin must check if it's safe to make a copy. And send the depth buffer area only to the emulator if it's safe. The plugin already knows if it's safe to make a copy. The current depth buffer emulation method does not crash. Should be enough to tell the emulator that depth buffer area is not used.

Contributor

purplemarshmallow commented Dec 5, 2015

Alas, it's not GLideN64 bug. It is problem of FBInfo conception.

I don't think so. I can think of a good solution. The gfx plugin controls it. The gfx plugin must check if it's safe to make a copy. And send the depth buffer area only to the emulator if it's safe. The plugin already knows if it's safe to make a copy. The current depth buffer emulation method does not crash. Should be enough to tell the emulator that depth buffer area is not used.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Dec 6, 2015

Owner

You are wrong here. Re-read FBInfo specification and my explanation of the problem.

Our standard method of frame/depth buffer emulation copies the buffer during ProcessDList. At this moment RDP controls the workflow and it can safely write data to the buffers. That's why "the current depth buffer emulation method does not crash".

FBInfo works when CPU takes back the control. The assumption "The gfx plugin controls it" is wrong. Plugin controls nothing at this moment, it does what emulators commands to do. Plugin can't detect that CPU is going to re-use depth buffer memory for its own needs. CPU takes that decision. However, emulator knows that this memory area is used as a buffer because plugin informed about it via FBGetFrameBufferInfo callback. According to the FBInfo API specification emulator informs the plugin about writes to buffer area. The plugin now knows that CPU modified buffer content and thus the changes need to be shown on screen. Then emulator reads values from the buffer area. Again, it knows that it is a buffer and sends FBRead notifications. According to the specification: "This function is called to notify the dll that the frame buffer memory is beeing read at the given address. DLL should copy content from its render buffer to the frame buffer in N64 RDRAM". The buffer for which FB functions called is valid for the plugin, because it was set in latest DList. Plugin should read the data to the buffer in RDRAM. That data will overwrite CPU data and program will crash. Thus strict following to the API specification causes crash.

Owner

gonetz commented Dec 6, 2015

You are wrong here. Re-read FBInfo specification and my explanation of the problem.

Our standard method of frame/depth buffer emulation copies the buffer during ProcessDList. At this moment RDP controls the workflow and it can safely write data to the buffers. That's why "the current depth buffer emulation method does not crash".

FBInfo works when CPU takes back the control. The assumption "The gfx plugin controls it" is wrong. Plugin controls nothing at this moment, it does what emulators commands to do. Plugin can't detect that CPU is going to re-use depth buffer memory for its own needs. CPU takes that decision. However, emulator knows that this memory area is used as a buffer because plugin informed about it via FBGetFrameBufferInfo callback. According to the FBInfo API specification emulator informs the plugin about writes to buffer area. The plugin now knows that CPU modified buffer content and thus the changes need to be shown on screen. Then emulator reads values from the buffer area. Again, it knows that it is a buffer and sends FBRead notifications. According to the specification: "This function is called to notify the dll that the frame buffer memory is beeing read at the given address. DLL should copy content from its render buffer to the frame buffer in N64 RDRAM". The buffer for which FB functions called is valid for the plugin, because it was set in latest DList. Plugin should read the data to the buffer in RDRAM. That data will overwrite CPU data and program will crash. Thus strict following to the API specification causes crash.

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Dec 6, 2015

Contributor

Yes you are correct here. Strict following to the API specification causes crash.

1080 still crashes. But depth buffer writes are not the problem here. Color buffer writes cause the crash. And there's an additional problem. If I disable color buffer writes I can get ingame. But it takes a very long time. The fb write code slows things down. If i disable the fb write code I'm ingame immediately (Mupen).

Contributor

purplemarshmallow commented Dec 6, 2015

Yes you are correct here. Strict following to the API specification causes crash.

1080 still crashes. But depth buffer writes are not the problem here. Color buffer writes cause the crash. And there's an additional problem. If I disable color buffer writes I can get ingame. But it takes a very long time. The fb write code slows things down. If i disable the fb write code I'm ingame immediately (Mupen).

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Dec 9, 2015

Contributor

I noticed a regression. The top row of pixels is not copied. Maybe the bottom row is also incorrect. This can cause crashes if the plugin writes into game data.
And copy from RDRAM does not seem to work anymore. If I try it the plugin just crashes.
1

Contributor

purplemarshmallow commented Dec 9, 2015

I noticed a regression. The top row of pixels is not copied. Maybe the bottom row is also incorrect. This can cause crashes if the plugin writes into game data.
And copy from RDRAM does not seem to work anymore. If I try it the plugin just crashes.
1

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Jan 17, 2016

Owner

I found why 1964 works so slow. It does not follow FBRead specification: "Emulator should not call this function again if other memory is read within the same 4KB range".
FBRead calls come from near addresses in no particular order:
FBRead addr=8032d1b2
FBRead addr=8032d1b0
FBRead addr=8032d1b6
FBRead addr=8032d1b4
FBRead addr=8032d1ba

Owner

gonetz commented Jan 17, 2016

I found why 1964 works so slow. It does not follow FBRead specification: "Emulator should not call this function again if other memory is read within the same 4KB range".
FBRead calls come from near addresses in no particular order:
FBRead addr=8032d1b2
FBRead addr=8032d1b0
FBRead addr=8032d1b6
FBRead addr=8032d1b4
FBRead addr=8032d1ba

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Jan 17, 2016

Owner

I optimized FBRead calls. Number of buffer reads reduced from hundred to 6 in Mario Kart with 1964.
However 1964 still works much slower. I think it is because 1964 calls plugin's FBRead too often. 1964 has slowdown near Mario Kart monitor even if FBRead does nothing.

Owner

gonetz commented Jan 17, 2016

I optimized FBRead calls. Number of buffer reads reduced from hundred to 6 in Mario Kart with 1964.
However 1964 still works much slower. I think it is because 1964 calls plugin's FBRead too often. 1964 has slowdown near Mario Kart monitor even if FBRead does nothing.

@weinerschnitzel

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Jan 20, 2016

@LegendOfDragoon, we should look into this. Pinging you because I can't find time on IRC

@LegendOfDragoon, we should look into this. Pinging you because I can't find time on IRC

@weinerschnitzel

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Jan 21, 2016

@gonetz, can you upload your optimized build? or email me at gmail.com... I would like to try a few things with 1964 to prevent calls when the FBRead addr is within 4KB of the last call and see if results help.

@gonetz, can you upload your optimized build? or email me at gmail.com... I would like to try a few things with 1964 to prevent calls when the FBRead addr is within 4KB of the last call and see if results help.

@weinerschnitzel

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Jan 22, 2016

Ok. I modified VIDEO_FrameBufferRead in 1964 to skip FBReads that are within 4KB of the last read address, and this fixes the slowdowns in MK64. I saw that FBReads per second would exceed 60000 with RiceVideo, although Rice wouldn't slowdown. Skipping FBReads that are "too close" brings the count below 200 with Rice or GLideN64.

I don't notice any visual degradation or things breaking, but I may not be keen enough to see a difference. I'll try more test cases.

Ok. I modified VIDEO_FrameBufferRead in 1964 to skip FBReads that are within 4KB of the last read address, and this fixes the slowdowns in MK64. I saw that FBReads per second would exceed 60000 with RiceVideo, although Rice wouldn't slowdown. Skipping FBReads that are "too close" brings the count below 200 with Rice or GLideN64.

I don't notice any visual degradation or things breaking, but I may not be keen enough to see a difference. I'll try more test cases.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Jan 22, 2016

Contributor

@weinerschnitzel Would you mind uploading your 1964 for testing when it's acceptably working?

Contributor

AmbientMalice commented Jan 22, 2016

@weinerschnitzel Would you mind uploading your 1964 for testing when it's acceptably working?

@weinerschnitzel

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Jan 22, 2016

https://www.dropbox.com/s/dp1pm782ez9do3i/1964%20test.7z?dl=0

Here is the little test build I've been working on. 1964.exe is built with the FBRead modification, and the VI/s counter is swapped with an FBRead/s counter. 1964_11.exe is vanilla 1964 1.1. I'll make a clean PR to @LegendOfDragoon's 1964 repository that we can scrutinize.

FBInfo seems to work really well. My only concern is if skipping FBReads makes the MK64 video monitor choppier. I can't tell.

https://www.dropbox.com/s/dp1pm782ez9do3i/1964%20test.7z?dl=0

Here is the little test build I've been working on. 1964.exe is built with the FBRead modification, and the VI/s counter is swapped with an FBRead/s counter. 1964_11.exe is vanilla 1964 1.1. I'll make a clean PR to @LegendOfDragoon's 1964 repository that we can scrutinize.

FBInfo seems to work really well. My only concern is if skipping FBReads makes the MK64 video monitor choppier. I can't tell.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Jan 22, 2016

Owner

You may test your fix on full-screen fb effects. Banjo-Kazooie puzzle effect is a good example. If image has no missing (black) parts - the fix works correct.

Owner

gonetz commented Jan 22, 2016

You may test your fix on full-screen fb effects. Banjo-Kazooie puzzle effect is a good example. If image has no missing (black) parts - the fix works correct.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Jan 22, 2016

Contributor

So I've been doing some testing. Why is 1964's audio eating up 70% or more? Mario Kart is glitchy with black lines across the displays. Banjo Kazooie shows white puzzle pieces before freezing.

Contributor

AmbientMalice commented Jan 22, 2016

So I've been doing some testing. Why is 1964's audio eating up 70% or more? Mario Kart is glitchy with black lines across the displays. Banjo Kazooie shows white puzzle pieces before freezing.

@weinerschnitzel

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Jan 22, 2016

1964audio can be expensive at times. I'm also not seeing any black squares when skipping FBReads. MK64 video monitors work fine, Banjo Kazooie puzzle effect works fine, and Bomberman64 into works fine. I'm on Intel, maybe your issue is vendor related @AmbientMalice? Thanks for the testing

1964audio can be expensive at times. I'm also not seeing any black squares when skipping FBReads. MK64 video monitors work fine, Banjo Kazooie puzzle effect works fine, and Bomberman64 into works fine. I'm on Intel, maybe your issue is vendor related @AmbientMalice? Thanks for the testing

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Jan 22, 2016

Contributor

I'm on Nvidia. GTX 750Ti. Windows 10.

With optimisation:
with

Without:
without

Contributor

AmbientMalice commented Jan 22, 2016

I'm on Nvidia. GTX 750Ti. Windows 10.

With optimisation:
with

Without:
without

@weinerschnitzel

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Jan 22, 2016

Do you get the same issue with RiceVideo/1964video when you have Framebuffer with Emulator enabled?

Do you get the same issue with RiceVideo/1964video when you have Framebuffer with Emulator enabled?

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Jan 22, 2016

Contributor

Seems to work fine with 1964video. So it's obviously a GLideN64-side bug.

Contributor

AmbientMalice commented Jan 22, 2016

Seems to work fine with 1964video. So it's obviously a GLideN64-side bug.

@olivieryuyu

This comment has been minimized.

Show comment
Hide comment
@olivieryuyu

olivieryuyu Feb 7, 2016

works well with famista 64

famista

works well with famista 64

famista

@olivieryuyu

This comment has been minimized.

Show comment
Hide comment
@olivieryuyu

olivieryuyu Feb 7, 2016

oops

World Cup 98 is buggy with fb notification.

sdfdf

oops

World Cup 98 is buggy with fb notification.

sdfdf

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 8, 2016

Owner

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

Owner

gonetz commented Feb 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 8, 2016

Owner

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

Owner

gonetz commented Feb 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 8, 2016

Owner

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

Owner

gonetz commented Feb 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 8, 2016

Owner

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

Owner

gonetz commented Feb 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 8, 2016

Owner

@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

Owner

gonetz commented Feb 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Feb 8, 2016

Does the banjo kazoo fix affect superman64?

Does the banjo kazoo fix affect superman64?

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 8, 2016

Owner

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

Owner

gonetz commented Feb 8, 2016

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

@weinerschnitzel

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Feb 9, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 9, 2016

Owner

@weinerschnitzel thanks, I'll check the issues.

Owner

gonetz commented Feb 9, 2016

@weinerschnitzel thanks, I'll check the issues.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 11, 2016

Owner

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

Owner

gonetz commented Feb 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Feb 11, 2016

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

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

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Feb 13, 2016

Contributor

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

Contributor

purplemarshmallow commented Feb 13, 2016

"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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 13, 2016

Owner

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:
#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.

Owner

gonetz commented Feb 13, 2016

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:
#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.

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Feb 13, 2016

Contributor

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

Contributor

purplemarshmallow commented Feb 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 13, 2016

Owner

Most likely it is.

Owner

gonetz commented Feb 13, 2016

Most likely it is.

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Feb 13, 2016

Contributor

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?

Contributor

purplemarshmallow commented Feb 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 13, 2016

Owner

What if FBread is skipped if there are no dlists?

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

Owner

gonetz commented Feb 13, 2016

What if FBread is skipped if there are no dlists?

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

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 13, 2016

Owner

I have pushed fix for JFG crosshair.

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

pass: test

Owner

gonetz commented Feb 13, 2016

I have pushed fix for JFG crosshair.

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

pass: test

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Feb 13, 2016

Contributor

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.

Contributor

AmbientMalice commented Feb 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Feb 13, 2016

Contributor

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.

Contributor

purplemarshmallow commented Feb 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 14, 2016

Owner

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

Owner

gonetz commented Feb 14, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 14, 2016

Owner

@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?

Owner

gonetz commented Feb 14, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Feb 14, 2016

Contributor

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.

Contributor

purplemarshmallow commented Feb 14, 2016

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 comment has been minimized.

Show comment
Hide comment
@LegendOfDragoon

LegendOfDragoon Feb 14, 2016

This code breaks rain in JFG with PJ64:

Does it break rain if you use CPU interpreter?

This code breaks rain in JFG with PJ64:

Does it break rain if you use CPU interpreter?

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Feb 15, 2016

Owner

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

Owner

gonetz commented Feb 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Feb 15, 2016

Contributor

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.

Contributor

AmbientMalice commented Feb 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@LegendOfDragoon

LegendOfDragoon Feb 15, 2016

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

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

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Feb 17, 2016

Contributor

@purplemarshmallow It can be not so easy. If FBRead will be called before FBWrite, RDRAM will be broken.

This still sounds like a problem on 1964's part. The emulator must call FBwrite immediately and this will warn the plugin.

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

Thanks. This might be a good game to test

Contributor

purplemarshmallow commented Feb 17, 2016

@purplemarshmallow It can be not so easy. If FBRead will be called before FBWrite, RDRAM will be broken.

This still sounds like a problem on 1964's part. The emulator must call FBwrite immediately and this will warn the plugin.

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

Thanks. This might be a good game to test

@weinerschnitzel

This comment has been minimized.

Show comment
Hide comment
@weinerschnitzel

weinerschnitzel Feb 17, 2016

For emulator, ignore FBRead if FBWrite has not been called at least once?

For emulator, ignore FBRead if FBWrite has not been called at least once?

@purplemarshmallow

This comment has been minimized.

Show comment
Hide comment
@purplemarshmallow

purplemarshmallow Feb 17, 2016

Contributor

If FBwrite is called then GLideN64 ignores FBread
See #808 (comment)

Contributor

purplemarshmallow commented Feb 17, 2016

If FBwrite is called then GLideN64 ignores FBread
See #808 (comment)

@gonetz

This comment has been minimized.

Show comment
Hide comment
Owner

gonetz commented Feb 27, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment