Android Donkey kong 64 camera issue

[ghost]

UPDATE: the fix for this is to set "prioritize core options over ini" and "framebuffer emulation on"

mupen64 plus next gles 3 core, gliden64, snapdragon 765g , android 11

in donkey kong 64 (ntsc) on the windows version of retroarch mupen64plus next there is no camera glitch on default settings but on the android gles 3 version of mupen there is a camera glitch on default settings and i have tried playing with settings but the camera issue remains.

using mupen64plus ae standalone there is also no issue.

https://github.com/gonetz/GLideN64/issues/2392 they seem to have fixed this here but im not sure what to do

[ghost]

@fzurita any idea why this works on your standalone but not here ?

[fzurita]

If I remember correctly, the difference is software vs hardware depth buffer emulation. Try toggling the depth buffer emulation setting.

[ghost]

@fzurita mupen64plus next gles3 on retroarch only has options : "software", "from mem" and "off" and each one has the issue, @m4xw any idea why this issue is non existant on windows version by default settings and yet persists on gles3 no matter what settings ?

[fzurita]

Interesting, well, try toggling the setting in mupen64plus-ae, I think it will make the issue happen there.

[ghost]

@fzurita thanks :) and sorry to bother you , i see you guys are buzy dealing with that fog issue over there, nice one, btw it was me that first reported that fog issue to you

[fzurita]

I think I got the fog issue figured out. Now I'm working on my day job, lol.

[m4xw]

That used to be the old workaround:

DK64 Camera Issue workaround:
-    Start ROM
-    Turn FBEmu On
-    Set RDRAM Depth stuff: Software (fromMem does not work)
-    Close ROM & start ROM again
-    Get ingame
-    Do a Savestate
-    Turn FBEmuoff, RDRAM stuff back or whatever
-    Close ROM & start ROM again
-    Load Savestate
-    Stays fixed whenever u load that Savestate

It should be set via gliden ini, u sure its the correct gles3 version?

[ghost]

@m4xw thanks i have tried your solution but the issue persists, i fixed the issue by disabling the ini through core options, so something embedded into the core file was causing my issue, can i ask you are you guys embedding the latest version of glide/gliden custom inis etc ?

[m4xw]

yes they are the latest

[ghost]

understood, seems like the ini was overriding the depth buffer option, ok this can be closed now, thank you

[m4xw]

I will leave it open until i took a look. This shouldnt happen

[m4xw]

if i can reproduce with angle, that will make it a bit easier

[ghost]

understood, another thing @m4xw is it possible to get nightly gles 3 mupen64plusnext cores from the retroarchvdownloads page ? i have not been able to find them, only the regular mupen cores are available on the nightlies page

[m4xw]

You can always find my latest builds here: https://git.libretro.com/libretro/mupen64plus-libretro-nx/-/pipelines

[m4xw]

Also, you can click there as well:

[ghost]

thanks, so if i go to "pipelines" then "all", the latest ones are at the top ?

[m4xw]

ye, just make sure u pick one from "develop" branch, then u can select the job u want and download it for manual installation.

[ghost]

understood thanks, do you have nightlies for uwp gles 3 ? i see there is one called "angle_testing"

[m4xw]

Those are not on CI/CD and I did those builds manually. Also the branch is far behind. Its planned tho. At that point i would also start support for it.

[m4xw]

the whole port was literally a 10min effort with a hour or so of remote debugging. I spent zero effort on it, hence I dont support it. Its a "just works" situation. So stuff might or might not have issues^^

[m4xw]

Well that would explain it.

[ghost]

oops closed issue by mistake sorry, understood :) thanks thats much clearer to me now, also on uwp "ANGLE" xbox series s/x the "color buffer to rdram" option does not work at all and is needed for accuracy, i was about to make a seperate issue for the color buffer option but your statement above is enough, even though you spent a little time on it it still works amazingly well with a bit of tinkering so thank you for your effort there and thanks for everything that you do :)

[ghost]

the color buffer option is not the culprit for this donkey kong camera issue though, its disabling the ini and toggling depth buffer that solves this issue, for whatever reason, confirmed this fix solves this issue on xbox series and android gles3. Color buffer is needed for frame transition effects in games like banjo kazooie, perfect dark, color buffer option works flawlessly on android gles 3 but on xbox series "ANGLE" gles3 it doesnt work at all

[ghost]

@m4xw should i make a seperate issue for color buffer option on uwp xbox angle ? just so its like a reminder for a pretty big issue, or will we leave it ? maybe you can take note of it yourself ?

[m4xw]

@m4xw should i make a seperate issue for color buffer option on uwp xbox angle ? just so its like a reminder for a pretty big issue, or will we leave it ? maybe you can take note of it yourself ?

No need

the color buffer option is not the culprit for this donkey kong camera issue though, its disabling the ini and toggling depth buffer that solves this issue, for whatever reason, confirmed this fix solves this issue on xbox series and android gles3. Color buffer is needed for frame transition effects in games like banjo kazooie, perfect dark, color buffer option works flawlessly on android gles 3 but on xbox series "ANGLE" gles3 it doesnt work at all

if one is broken, i expect the other to be broken as well

[ghost]

understood thanks

[m4xw]

Btw feel free to try https://cdn.discordapp.com/attachments/876520593636335646/894907594123132938/angle_mupen64plus_next_libretro.dll (updated ANGLE build), untested. If it works, see if the issue persists.

[ghost]

@m4xw thanks, issue still persists and when i used the fix: "framebuffer emulation;on" and "priorotize core options over ini" , it solved the issue again, also gonetz has very recently fixed a few other major issues in the latest gliden64 rdp and please try to keep the cxd4 rsp in your Angle builds as it is needed for some games and for debugging, cheers :)

[m4xw]

I will need to doublecheck some things, just wanted to know if it still runs. Asked you to check with it since the other angle builds were old old code vs now. So lots of things changed anyway.

[m4xw]

try to keep the cxd4 rsp in your Angle builds as it is needed for some games and for debugging, cheers :)

If it can run it, I dont mind.

[ghost]

also, try keep angrylion in there too as it works as an lle workaround.

Edit: oops @m4xw when you sent me the link to download your updated angle build, i deleted my old one thinking your new one will have cxd4 rsp and angrylion rdp but it doesnt lol, i will wait until you re-integrate them into a modern angle build.

[m4xw]

https://cdn.discordapp.com/attachments/532533952603226112/895268765414096926/ANGLE_mupen64plus_next_libretro.dll

[ghost]

@m4xw i have not used retroarch since about 2 or 3 revisions ago, been buzy, have you managed to update your mupen angle builds at all ? cheers

[m4xw]

Didn't get around making actual full builds yet/rebase. only the core dll's that i posted. Cant remember what i wanted to do..

[ghost]

I think you wanted to take the ANGLE build and update it from a "just works" to something closer to main libretro core and rebase code, some settings on ANGLE build dont work at all.

[m4xw]

I lag behind on a lot of stuff regarding mupen :/

[ghost]

understood :) its no problem since the ANGLE build is not a priority, you can close this if you want man and thanks for all you guys do

[m4xw]

Nah I will get to it eventually. Just managed to scrape some time together to rebase mupen core as we speak..