search

gonetz / GLideN64

A new generation, open-source graphics plugin for N64 emulators.
Other
770 stars 179 forks source link

Framebuffer Emulation is broken on Raspberry Pi (OpenGL Driver) #1084

Open AlessandroPorcelli91 opened 8 years ago

AlessandroPorcelli91 commented 8 years ago

The game starts beautifully and runs great, though in about half an hour the textures corrupt in a very specific way: wherever the objects are (eg: Link, a tree, a NPC etc.) the terrain becomes transparent, and the transparency stays for as long as the emulator is running effectively making the game unplayable. I am currently running configuration version 12 according to mupen64plus.cfg. What can I do? Thanks.

loganmc10 commented 8 years ago

I would suggest rebooting the Pi (to clear any CLFAGS that might be in your environment), and then emptying the projects/cmake folder (like go into projects/cmake, do a rm -rf *) and then run cmake and make again

AlessandroPorcelli91 commented 8 years ago

@loganmc10 That fixed it, I now have a compiled binary. I had to remove both the options above though, I don't know what am I missing.

AlessandroPorcelli91 commented 8 years ago

@loganmc10 Alright, I have been testing it but sadly it looks like the problem is still there (I ran it through retropie putting the compiled mupen64plus-video-GLideN64.so into /opt/retropie/emulators/mupen64plus/lib/mupen64plus).

loganmc10 commented 8 years ago

Really? thats fascinating, I'm really not sure why it works in GLupeN64 and not mupen64plus then. It's the same problem, just that things become transparent randomly over time?

AlessandroPorcelli91 commented 8 years ago

Yup, I have uploaded a zip file some posts ago called "the glitch gremlin" in which I put some screenshots of the thing.

AlessandroPorcelli91 commented 8 years ago

Actually, since I don't trust retropie's filesystem...let me check from inside raspbian through command line. I usually avoid using raspbian for mupen because fullscreen is completely broken in my personal experience.

AlessandroPorcelli91 commented 8 years ago

Ok, maybe you actually fixed it...I'm saying this because I realized that it runs just as slow as it does in GLupeN64 :dart: I don't know what the hell retropie is loading as I explicitly gave it the correct plugin directory...640x480 is unviable but that's besides the point for now, I will try it windowed in a lower resolution and see if it goes full ISIS after a while. THEN I'll have to find out what's wrong with my retropie.

AlessandroPorcelli91 commented 8 years ago

@loganmc10 I swear I'll stop posting this much...but I have bad news. The problem is still present in both GLupeN64 and the compiled GLideN64 plugin, apparently I just got lucky with the first run :( Sorry I made you port the code, I should have tested it better in the first place...

loganmc10 commented 8 years ago

Oh that's ok, at least that makes sense (that they both act the same).

I'll try a few things over the next couple days, but this shows that adding glDiscardFramebufferEXT in additional places isn't going to do anything, there will need to be another solution.

AlessandroPorcelli91 commented 8 years ago

Yeah, at least there's some logic behind it. It looks like it happens more often if I stand still or if I stay for a while in some locations (like the Market), I'm talking like less than 5 minutes for it to trigger. I don't yet know if it's just placebo but every longer session I had I actually ran around everywhere, so it could be that rendering the same thing over and over again makes it go crazy.

gizmo98 commented 8 years ago

This problems happens in Zelda Majoras Mask and Conker BfD as well. Mario Tennis and Golf have glitches as well. I hope there will be a rpi4 with a better gpu.

AlessandroPorcelli91 commented 8 years ago

Yeah...I can confirm Majora's Mask to have the same issue, too. So, do you think that's ultimately a hardware issue?

loganmc10 commented 8 years ago

It's actually more of a driver thing than a problem with the GPU hardware. This problem doesn't happen with Eric Anholt's open source (mesa) GL driver (https://www.raspberrypi.org/blog/another-new-raspbian-release/)

However, the last time I tried mupen64plus with the opensource GL driver the performance was quite poor (this was a few months ago)

https://github.com/anholt/linux/issues/57 https://github.com/anholt/mesa/issues/32

gizmo98 commented 8 years ago

I don't know if there is anything new for you but Eric Anholt has written down some VC4 performance tricks: https://github.com/anholt/mesa/wiki/VC4-Performance-Tricks

loganmc10 commented 8 years ago

I think I looked at that a while ago. Anyway I haven't tried it in a while maybe some improvements have been made. I'll try it out again sometime in the next few weeks.

anholt commented 7 years ago

Note that GL_EXT_discard_framebuffer does allow discards on the default framebuffer (0). This would be useful if you're using GLX, which normally doesn't discard depth on swaps (sigh).

I'm not sure which driver you're testing against here, but if it's the open source driver, we're unfortunately not doing anything with glDiscardFramebufferEXT() at all, but we need to .

loganmc10 commented 7 years ago

@anholt all these issues are happening with the closed source driver, your driver doesn't suffer from these issues

m-goetz commented 7 years ago

Hi, I'm also facing the exact same issue when playing LOT:OOT on my RPi 3. Just as you said, the textures corrupt after an unpredictable amount of time, but I also tried Banjo Tooie, where I get the corrupted textures right at the beginning (the spinning "N" is missing parts for example). When I go through the menu to actually start the game, its imho the exact same effect as in OOT after some time. Maybe this helps you debugging...

dankcushions commented 6 years ago

thinking out-loud, does the recent change to allow non-0 framebuffer affect this issue? https://github.com/gonetz/GLideN64/pull/1819

ie, could we force a non-0 framebuffer for raspberry pi? if someone could give me some hints on how i could create such a build, i could give it a try!

loganmc10 commented 6 years ago

ie, could we force a non-0 framebuffer for raspberry pi? if someone could give me some hints on how i could create such a build, i could give it a try!

That change was just to support different rendering backends. The Raspberry Pi uses SDL, which uses "0" for the default framebuffer, so that change won't make any difference for the Pi.

quicksilver7837 commented 5 years ago

This issue may have been solved inadvertently. Previously after running a game for about 20 mins using gliden64 on a raspberry pi the textures would corrupt and the Pi would freeze. (See https://retropie.org.uk/forum/topic/16739/n64-crashes-after-10-min/26). However after recently updating from source I no longer get the texture corruption/freeze issue and have been able to play using gliden64 on my pi for hours at a time.