Author Topic: Gles2glide64 plugin orientation issue  (Read 37995 times)

Offline storm20200

  • bit
  • Posts: 4
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #15 on: November 19, 2013, 04:00:34 PM »
I tried the test version too. The issue still remains the same, portrait mode is used in landscape and reverse landscape modes. Immersive mode works beautifully though, having it enabled or disabled doesn't change the orientation issue though.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #16 on: November 19, 2013, 04:47:31 PM »
Thanks a lot guys.

I only seem to have received one crash report from nighthawk and unfortunately didn't have the information I hoped it would.  This test was a bit of a long shot anyhow... the main thing I thought might help was changing some build configuration stuff to explicitly include KitKat SDK.

Immersive mode will be coming in one of the next releases, probably 2.5.0 in the next week or two.  Until then you can enjoy the test version posted here.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #17 on: November 19, 2013, 04:51:38 PM »
BTW, if you find any other app that had this problem and got it resolved recently, please let us know.  May hold the clue to the issue.  For now it looks like a graphics driver issue since I don't have this problem on my 2012 Nexus 7 running KitKat.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline storm20200

  • bit
  • Posts: 4
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #18 on: November 19, 2013, 04:58:40 PM »
How unfortunate, Qualcomm don't seem like the best at making graphics drivers. Is there anything else we could do to help figure this out?

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #19 on: November 19, 2013, 05:07:32 PM »
Not sure yet because I still haven't had much time to look at this (and no way to test).  But once I do I'll post back here for help.  The best way to help right now would be to see if any other apps (a) had the problem and (b) resolved it.  Then let us know.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline puppy

  • bit
  • Posts: 3
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #20 on: December 14, 2013, 07:01:22 PM »
Hello,

Registered to say I have the same problem on my Nexus 5 running android 4.4.2.

Just to give a slightly more accurate description of the problem, there is a difference between portrait and landscape. On landscape mode it stretches the screen to the proper size for landscape, but then the actual graphics are sideways and very stretched since the aspect ratio is reversed. Portrait mode works as it should.

Hopefully I explained that well enough, haha. If you don't understand let me know and I can take some screenshots.

Hopefully this helps in your debugging efforts.

Thanks for all your hard work.

Offline Naked_Snake

  • bit
  • Posts: 1
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #21 on: January 04, 2014, 12:09:27 PM »
Hi,

Juste adding a little stone too the wall, I have the exact same issue on my Nexus 4 with Android 4.4.2. It's a shame, because playing majora mask whenever I want is a dream I had for a long time !

Thanks for your hard work, and for bringing littles dreams to reality. I hope this can get fixed some way.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #22 on: January 04, 2014, 04:00:31 PM »
Of course it does.  This issue will affect all users with Adreno 320 chipsets and KitKat because the Adreno drivers are broken.  If the right dev joins the team, or the rest of us get more free time, we may be able to find a workaround.  Until then, keep pestering Qualcomm to fix their drivers.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Dragoth

  • byte
  • *
  • Posts: 10
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #23 on: January 06, 2014, 06:45:49 AM »
Damn, it really looks like a driver problem.
According to the qualcomm support forums and the dolphin blog:

  • glBlitFramebuffer to a hardware buffer rotates the output of the buffer by 90.

This problem is really frustrating. GLES2Glide64 is the only plugin that works best for me. Very accurate and fast.

I'm no Android specialist or coding specialist in perticular, but i took a look at some files and was trying to find where the function glBlitFramebuffer was beeing used and found this in SDL_opengl.h under jni/SDL2/include:

Code: [Select]
GLAPI void APIENTRY glBlitFramebuffer (GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1, GLint dstX0, GLint dstY0, GLint dstX1, GLint dstY1, GLbitfield mask, GLenum filter);
Now my relative "primitive" idea was to swap GLint srcX0 with GLint srcY0 to bend the image back to landscape (negate the 90 error). This would just be a quick hack to identify the problem. If it works we would only need to identify devices with an adreno 320 and apply that hack to fix qualcomms damn bug in the driver.

Am i going into the right direction? If not, where could i look?
I'd be interested in fixing this... but would probably need alot of time.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #24 on: January 06, 2014, 07:11:09 AM »
Thanks for digging into that.  Are you a developer?  If so then by all means give it a shot.  You can just submit a pull request on github or post a patch on the forum.  I don't have an Adreno 320 device but could probably put up a few test builds later this week if no one else has jumped on it by then.  xperia64 might be a good person to try it since he's familiar with all the code and has a 2013 nexus 7.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #25 on: January 06, 2014, 07:25:48 AM »
Wait, no that won't solve the issue.  I should have read more carefully.  SDL_opengl.h isn't compiled into the app.  Plus it's just a declaration so changing the variable names wouldn't do anything anyhow.  But I'll take a look in the rest of the code, I think I heard that mentioned before about the blitting being buggy.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Dragoth

  • byte
  • *
  • Posts: 10
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #26 on: January 06, 2014, 08:47:04 AM »
Thanks for digging into that.  Are you a developer?  If so then by all means give it a shot.  You can just submit a pull request on github or post a patch on the forum.  I don't have an Adreno 320 device but could probably put up a few test builds later this week if no one else has jumped on it by then.  xperia64 might be a good person to try it since he's familiar with all the code and has a 2013 nexus 7.

No, i'm no Android developer. I'm currently developing/developed a compiler at work that translates robot-code. I also programmed a small Android app a couple of years ago in college... but it's been a while.

I have no idea about OpenGL and the sorts but am very interested and currently going through some OpenGL ES 2.0 tutorials.
I'll try to make a pull request later this week.

If you need additional testers, i'll gladly help since my Nexus 4 also has an Adreno 320 GPU.

Quote
Wait, no that won't solve the issue.  I should have read more carefully.  SDL_opengl.h isn't compiled into the app.  Plus it's just a declaration so changing the variable names wouldn't do anything anyhow.  But I'll take a look in the rest of the code, I think I heard that mentioned before about the blitting being buggy.

Damn it... i was hoping that changing the declaration/switching the variables would do the trick. It would have been way to easy... should have known :P

I'll keep reading through the code. If there is anything i can help with, give me a shout.

Offline Dragoth

  • byte
  • *
  • Posts: 10
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #27 on: January 10, 2014, 04:29:53 AM »
Small update about the orientation issue on devices with an Adreno 320 using the gles2glide64 plugin (gles2n64 & gles2rice work fine):

This is how the current problem looks like:

Native resolution - no scaling - Landscape



Native resolution - no scaling - Reverse Landscape



Native resolution - no scaling - Portrait

http://s14.directupload.net/images/140110/mdcrbxjp.png

Native resolution - no scaling - Reverse Portrait

http://s14.directupload.net/images/140110/hznhgtal.png



The interesting part about this bug is that portrait mode renders correctly. As soon as you switch to landscape, the rendered image rotates 90. A dolphin developer said that the cause for this was that if you glBlitFramebuffer to a hardware buffer the output of the buffer gets rotated by 90 (which is a bug in the qualcomm drivers for the adreno 320).

Here you can see a similar/same problem with Dolphin for Android on an Adreno 320 device:



If you compare the two pictures between mupen64plus-ae and dolphin, you can see that the image gets cut in mupen and in dolphin the image that is missing gets drawn again and causes an overlaped image. So i'm not sure if we are experiencing the same problem in mupen. I couldn't find any function in the mupen64plus-ae repository that uses glBlitframebuffer either. Maybe the output of the buffer always gets rotated by 90 when copying to a backbuffer?

Since i'm a huge noob when it comes to developing for android and working with openGL i just tried to throw things at the code in hoping that i somehow magically find a solution for this bug that qualcomm so kindly put into their drivers...

My idea was to find specific code that renders the screen with x/y or width/height variables and tried to switch said variables to bend back the image to landscape.

Sadly, my noobish approach didn't bring any results. All i could accomplish was switching the variables width & height (stretch scale) in /persistent/UserPrefs and got the image to stretch in the right direction and not make it look so squashed anymore (while in landscape). But the rotation was still there:

Default stretch



Switch width & height while in stretch mode in /persistent/UserPrefs




I'm back here now asking for some advice.

Could anyone point me into the right direction? Where and how could i look to find the problem? I lack the knowledge of how exactly mupen64plus-ae puts its pieces of code together.
Which part of the code has the job of rendering? We compile the plugins into an .so file. We also have SDL2 which seems to provide access to graphics hardware via OpenGL.. But it also gets compiled into an .so file. Which part of the code executes these .so files?

It would be awesome if somebody could help me out. I really want to get this working... or help the real developers in some way to get it working.

edit: sorry for the 403 error. I thought that dropbox could link pics... it can't :(
« Last Edit: January 10, 2014, 08:32:37 AM by Dragoth »

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #28 on: January 10, 2014, 07:16:34 AM »
I can't seem to access the screenshot links (getting a 403 error).

Since we're not really fixing our own bug, but rather finding a workaround to someone else's, then in theory there may be more than one solution.  Or none at all.  The first place I'd look would be the gles2glide64 plugin itself.  The location of the source is
   - jni/gles2glide64/src/Glitch64
   - jni/gles2glide64/src/Glide64
You can ignore everything inside GlideHQ since that is not currently compiled into the app.

SDL2 is used mainly for OpenGL initialization, and is used by all three plugins.  I don't think any of its run-time rendering functions are being used anywhere.  You could maybe see if there are any SDL2 functions that glide uses that rice and gln64 do not, and see if a workaround could be inserted there.  But SDL2 isn't the first place I'd look for the solution.

Likewise, the java code only contains a bit of OpenGL initialization stuff (src/paulscode/android/mupen64plusae/jni/NativeSDL.java), so there's very little opportunity there to insert a workaround.

I'd start with the native code in Glitch64, then Glide64.  I think part of the solution will involve just doing a lot of googling to identify other apps with the same issue, and to see if anyone has found a workaround.  And although we don't use much SDL2 functionality, it may still be worthwhile to check their repository to see if they've had to deal with the issue.  Might not solve our problem directly, but could give us some more hints.  We're using the 2.0.0-release version of SDL2.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Dragoth

  • byte
  • *
  • Posts: 10
    • View Profile
Re: Gles2glide64 plugin orientation issue
« Reply #29 on: January 10, 2014, 08:36:17 AM »
I can't seem to access the screenshot links (getting a 403 error).

Since we're not really fixing our own bug, but rather finding a workaround to someone else's, then in theory there may be more than one solution.  Or none at all.  The first place I'd look would be the gles2glide64 plugin itself.  The location of the source is
   - jni/gles2glide64/src/Glitch64
   - jni/gles2glide64/src/Glide64
You can ignore everything inside GlideHQ since that is not currently compiled into the app.

SDL2 is used mainly for OpenGL initialization, and is used by all three plugins.  I don't think any of its run-time rendering functions are being used anywhere.  You could maybe see if there are any SDL2 functions that glide uses that rice and gln64 do not, and see if a workaround could be inserted there.  But SDL2 isn't the first place I'd look for the solution.

Likewise, the java code only contains a bit of OpenGL initialization stuff (src/paulscode/android/mupen64plusae/jni/NativeSDL.java), so there's very little opportunity there to insert a workaround.

I'd start with the native code in Glitch64, then Glide64.  I think part of the solution will involve just doing a lot of googling to identify other apps with the same issue, and to see if anyone has found a workaround.  And although we don't use much SDL2 functionality, it may still be worthwhile to check their repository to see if they've had to deal with the issue.  Might not solve our problem directly, but could give us some more hints.  We're using the 2.0.0-release version of SDL2.

Thanks for the info! I'll try my luck with the native code of Glitch64/Glide64.  :)