-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Advertise the GLES2 macro #1765
Comments
What happens if you build without -DGLES2=On? You shouldn't need that to get it working with GLES2, the Android version supports GLES2 without doing that. |
Don't know why it's trying to include |
You are right, that should not be getting included. The GLES2 macro should not be getting included anywhere because the code uses EGL, so this sounds like a mistake in the code. |
I am working on fixing it. GLideNHQ still has direct references to OpenGL names/types. I am refactoring it to use the Graphics backend system instead, I'll submit a PR soon |
I can confirm that this now building for me with However on actually testing the plugin it causes a segmentation fault. This I had hoped would be resolved by building the "proper way", but unfortunately not. I've tried gradually reducing the options I passed to cmake until I reached a minimum of Any "classic causes" you are aware of? |
You'll have to use gdb to produce a backtrace, it should tell you where the segfault is happening. |
|
This is happening because your OpenGL libraries are in a different spot than usual (it looks like If you look here: https://github.com/gonetz/GLideN64/blob/master/src/Graphics/OpenGLContext/GLFunctions.cpp#L185-L189 https://github.com/gonetz/GLideN64/blob/master/src/Graphics/OpenGLContext/GLFunctions.cpp#L8 You can see what we've done for the Raspberry Pi and the ODroid. You'll need to submit PR that does a similar thing (don't forget to update CMakeLists.txt as well, you can see here for the commit that added ODroid support: cc3e1e6#diff-8d00b77b579260ee0345a82be1c5fe6d) |
Many thanks for the direction! Looks promising. I shall get on that. |
Well that was easy enough. You were right about the required path and I now have a
|
Ok I know what the issue is but I'm not in front of my computer now, I can fix it tomorrow. For now, if you look in your mupen64plus.cfg file for an option called "EnableShadersStorage" and set that to false, that should work around the issue for now |
I think that can be fixed by updating the compiler version. So make sure you are using the latest GCC or clang. Edit: Actually, this is a different problem. It's crashing when calling a GL function. glProgramParameteri is somehow not available for your device, which makes sense for GLES. |
It's because glProgramParameteri isn't valid in GLES2, it's an optional hint to give the driver, so we just need to skip calling that in GLES2 |
I'm surprised it's not crashing in Android for GLES2 devices. |
Yeah I'm surprised as well, maybe they don't support shader storage? That function is mentioned in GL_ARB_get_program_binary but not GL_OES_get_program_binary |
I'm surprised it works at all, the main function for the GLES2 version is supposed to be glGetProgramBinaryOES, not glGetProgramBinary, which is what we use |
This is probably returning false for most GLES2 devices. In his it must be returning true:
|
@hissingshark can you try this commit: You can apply if to your current system by downloading https://github.com/loganmc10/GLideN64/commit/eddfa190325438ce3c852df67df0fdf05d0cd8a0.patch and then:
Or if you have some other system to test it out that is good too. |
FYI - I know I can just use the configuration fix going forward, but I'm happy to keep testing any patches you want to try to get that cleared. |
Can you look inside If it still crashes then I would just say shader storage doesn't work on your device. I would either disable shader storage using the VERO4K definition or disable it for GLES2 in general, depending on @fzurita's preference. I'd be surprised if it worked on any GLES2 devices before given the crash you saw on your device |
Although that crash might just be related to your compiler, it looks kind of strange, @fzurita might have more insight |
Try using the latest GCC or clang. This looks very similar to a crash we had before when someone was using an older compiler. |
Deleting the shader folder does let it run - BUT it must be deleted prior to each run otherwise it gives the seg fault I published above. You know I was sure the patched build had worked when I tested it the first time but after that no dice so I thought I'd mixed up my builds or config! My gcc is currently at 6.3 I believe. |
This last crash looks like a bug in the code. Not sure why it's happening though. |
@hissingshark Can it be closed? |
I'm happy with respect to the original issue.
Does this need to be taken this elsewhere then? A new issue? |
@hissingshark |
Hi,
I've been building on the Vero4k (Amlogic s905x box running OSMC/debian).
My platform is GLESv2. I could only build by using
-DEGL=On
and an unadvertised macro-DGLES2=On
. Thereadme
andCMakeLists
make no mention of this. I just found it when going through the source to debug. Might be worth a mention in those places to aid the unwary in future.I hope that's helpful to you devs.
Many thanks.
The text was updated successfully, but these errors were encountered: