PaulsCode Forum

Mupen64Plus AE => General Discussion => Topic started by: Kris on March 27, 2013, 10:31:21 PM

Title: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 27, 2013, 10:31:21 PM
This is a work-in-progress version of a OpenGL ES 2.0 compatible version of the glide64mk2 plugin.

Source: https://github.com/paulscode/mupen64plus-ae/tree/Metricity/glide (https://github.com/paulscode/mupen64plus-ae/tree/Metricity/glide)

https://bitbucket.org/Metricity/mupen64plus-ae (https://bitbucket.org/Metricity/mupen64plus-ae)

This is an early version, expect performance and graphical issues.


Java Changes:
   Added option to select glide plugin.

Changes from glide64mk2:
Glitch64/combiner.cpp:
   Alpha Test implemented in shader.
   Custom attributes instead of unsupported built-in attributes (gl_Vertex, gl_MultiTexCoord, gl_Fog, gl_Color).

Glitch64/geometry.cpp:
   Vertex arrays used instead of glBegin/glEnd.
   Some calculations are done in the vertex shader so the data can be passed without being modified.
   
Glitch64/main.cpp:
   Android context and swapbuffers.

Glitch64/textures.cpp:
   Use supported texture formats.


Status
Working, perhaps with some issues:
   Geometry, Textures, Shaders, Fog, Alpha Test, Framebuffer
Significant issues:
   Depth buffer related glitches. (On Adreno, OK on PC)
High-res textures:
   This uses boost and is not setup to compile. I have compiled it previously but never got around to testing it.
Screen Size:
   You need to set Width and Height in mupen64plus.cfg [Video-General]
Performance:
   Work on performance hasn't begun and I know of a few places where some easy fixes/optimizations can be made.



My thanks to the original developers and maintainers: Dave2001,Sergey 'Gonetz' Lipski,Gugaman,Hiroshi 'KoolSmoky' Morii, warhaft, ecsv

This is work in progress and I hope to fix the mentioned issues.

Looking forward to your feedback and queries.
   
Title: Re: Glide
Post by: littleguy on March 27, 2013, 10:33:02 PM
Stoked!!!  Looking forward to trying it out!
Title: Re: Glide
Post by: littleguy on March 27, 2013, 10:47:31 PM
Funny, I just started looking at glide today, just seeing how many source files I could get to compile while flying blind.  I knew a lot of the gl stuff would balk but I wasn't expecting to have such trouble with boost.  Dependency hell.  I eventually determined a fairly minimal subset of boost that would get the GlideHQ source to compile.  But when I reopened eclipse the indexer crashed and burned.  I was tinkering with the eclipse heap settings when this showed up in my inbox.  Judging by your comments, did you wall off the boost dependency or something?

One of the other things I'm looking at right now is the SDL startup mechanics used by mupen-AE, to see if we can simplify it at all, or even revert somehow to the vanilla mupen mechanics.  If I make any progress I'll keep you posted, would be nice to not have so many custom AE-specific changes to the upstream source.

Title: Re: Glide
Post by: Kris on March 27, 2013, 11:09:57 PM
Funny, I just started looking at glide today, just seeing how many source files I could get to compile while flying blind.  I knew a lot of the gl stuff would balk but I wasn't expecting to have such trouble with boost.  Dependency hell.  I eventually determined a fairly minimal subset of boost that would get the GlideHQ source to compile.  But when I reopened eclipse the indexer crashed and burned.  I was tinkering with the eclipse heap settings when this showed up in my inbox.  Judging by your comments, did you wall off the boost dependency or something?

I know the feeling, I had plenty of troubles with boost but did have everything compiling, it was only earlier today I looked at eliminating it to make it easier for people to test. It turned out to be really simple and I wish I knew it earlier see the changes to Glide64/TexCache.cpp and Glide64/rdp.h.

I did an draft of the post when I thought people would need to build boost which had some pointers:
Quote
I used the version at https://github.com/mcxiaoke/boost-ndk
Configured it to build with gcc4.6 by modifiying boost\tools\build\v2\user-config.jam
Then built the required modules `b2 -a --with-system --with-thread --with-filesystem toolset=gcc-android4.6 link=static runtime-link=static target-os=linux --stagedir=android --layout=system`
There is another boost for android that seems more popular by MysticTreeGames but I had problems with it.

Here is the user-config.jam
Code: [Select]
import os ;

if [ os.name ] = CYGWIN || [ os.name ] = NT
{
        androidPlatform = windows ;
}

else if [ os.name ] = LINUX
{
        androidPlatform = linux-x86 ;
}

else if [ os.name ] = MACOSX
{
        androidPlatform = darwin-x86 ;

}

modules.poke : NO_BZIP2 : 1 ;

ANDROID_NDK = .....................;
using gcc : android4.6 :
    $(ANDROID_NDK)/toolchains/arm-linux-androideabi-4.6/prebuilt/$(androidPlatform)/bin/arm-linux-androideabi-g++ :
    <archiver>$(ANDROID_NDK)/toolchains/arm-linux-androideabi-4.6/prebuilt/$(androidPlatform)/bin/arm-linux-androideabi-ar
    <ranlib>$(ANDROID_NDK)/toolchains/arm-linux-androideabi-4.6/prebuilt/$(androidPlatform)/bin/arm-linux-androideabi-ranlib
    <compileflags>--sysroot=$(ANDROID_NDK)/platforms/android-9/arch-arm
    <compileflags>-I$(ANDROID_NDK)/sources/cxx-stl/gnu-libstdc++/4.6/include
    <compileflags>-I$(ANDROID_NDK)/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi/include
<compileflags>-L$(ANDROID_NDK)/sources/cxx-stl/gnu-libstdc++/4.6/libs
    <compileflags>-DNDEBUG
    <compileflags>-D__GLIBC__
    <compileflags>-DBOOST_NO_INTRINSIC_WCHAR_T
<compileflags>-DPAGE_SIZE=2048
<compileflags>-lgnustl_static
<compileflags>-lsupc++
    <compileflags>-mthumb
    <compileflags>-fno-strict-aliasing
    <compileflags>-O2
        ;

Also check some of the commented out parts in the makefile for how I set it up.

I only eliminated it as it complicated the build process so it will return at some stage. I will test to see if it actually works soon.

Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on March 27, 2013, 11:13:42 PM
Priceless.  Thanks!
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 28, 2013, 12:07:35 AM
Setting width and height in the cfg doesn't seem to work anymore it was only a temporary method anyway. I had wanted to post it a few days ago but have been sorting out the release instead of doing any of the obvious small fixes.

I had done most of my testing with other dependencies and build settings and was used to it running slower so I was unsure about the performance but now it seems better.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on March 28, 2013, 07:48:00 AM
Great work, Kris!  You've made some amazing progress!
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on March 28, 2013, 08:12:11 AM
Cool, I just got around to actually pulling and building.  It took me a while to realize that you're using git (not hg) on bitbucket... kept getting hg 404 errors. ;)  Is there a reason you didn't branch (or fork) directly in github?

For those of you who (like me) are still working on your gitfu, you can do the following to pull Kris' work into your github-originated local repo:
Spoiler: git • show

Add bitbucket as a second remote: [code]git remote add [Metricity/glide] bitbucket https://bitbucket.org/Metricity/mupen64plus-ae[/code]
Adding [the-stuff-in-brackets] will only track Kris' glide branch, while omitting it will track all the branches (most of which are already tracked from origin).

Fetch the remote bitbucket branch(es): [code]git fetch --all[/code]

Checkout Kris' branch: [code]git checkout -B Metricity/glide bitbucket/Metricity/glide[/code]

From there you can checkout, branch, merge, etc. as always. 

Edit: Don't forget to reload your assets (Settings->Advanced->Reload app resources)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 28, 2013, 08:34:20 AM
I used bitbucket because I already had an account but mainly because I was expecting to need to add hundreds of files for boost and Regal and I wanted it separate as they would have been +400mb. As these are not necessary anymore I plan to use github as you mentioned.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on March 28, 2013, 08:38:28 AM
I used bitbucket because I already had an account but mainly because I was expecting to need to add hundreds of files for boost and Regal and I wanted it separate as they would have been +400mb. As these are not necessary anymore I plan to use github as you mentioned.

Ah, yes, thanks for sparing me all that data!

I made a local branch and merged the latest master without conflict. :D   I do get an FC however when I load a game so I'll have to check into it some more.  I'll post the logcat since I'm guessing you'll be interested, but please don't take this to be a support request (I can probably track it down on my own).

Spoiler: logcat • show
[code]
03-28 09:16:54.815: I/GameSurface(29639): surfaceCreated:
03-28 09:16:54.815: I/GameSurface(29639): surfaceChanged:
03-28 09:16:54.815: I/input-android(29639): jniInitInput()
03-28 09:16:54.815: I/SDL(29639): SDL_Android_Init()
03-28 09:16:54.825: V/front-end(29639): Using Android data folder '/storage/emulated/0/Android/data/paulscode.android.mupen64plusae' for config read/write functions
03-28 09:16:54.825: V/front_end(29639):  __  __                         __   _  _   ____  _             
03-28 09:16:54.825: V/front_end(29639): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___
03-28 09:16:54.825: V/front_end(29639): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __| 
03-28 09:16:54.825: V/front_end(29639): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \ 
03-28 09:16:54.825: V/front_end(29639): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/ 
03-28 09:16:54.825: V/front_end(29639):              |_|         http://code.google.com/p/mupen64plus/ 
03-28 09:16:54.825: V/front_end(29639): Mupen64Plus Console User-Interface Version 1.99.5
03-28 09:16:54.825: V/front_end(29639): UI-Console: attached to core library 'Mupen64Plus Core' version 1.99.5
03-28 09:16:54.825: V/front_end(29639): UI-Console:             Includes support for Dynamic Recompiler.
03-28 09:16:54.825: V/front_end(29639): Core: Updating parameter set version in 'Core' config section to 1.01
03-28 09:16:55.315: V/front_end(29639): Core: Goodname: Super Mario 64 (U) [!]
03-28 09:16:55.315: V/front_end(29639): Core: Name: SUPER MARIO 64     
03-28 09:16:55.315: V/front_end(29639): Core: MD5: 20B854B239203BAF6C961B850A4A51A2
03-28 09:16:55.315: V/front_end(29639): Core: CRC: 635a2bff 8b022326
03-28 09:16:55.315: V/front_end(29639): Core: Imagetype: .z64 (native)
03-28 09:16:55.325: V/front_end(29639): Core: Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
03-28 09:16:55.325: V/front_end(29639): Core: Version: 1444
03-28 09:16:55.325: V/front_end(29639): Core: Manufacturer: Nintendo
03-28 09:16:55.325: V/front_end(29639): Core: Country: USA
03-28 09:16:55.325: V/front_end(29639): UI-Console Status: Cheat codes disabled.
03-28 09:16:55.325: V/front_end(29639): UI-Console: using Video plugin: 'Glide64mk2 Video Plugin' v1.99.4
03-28 09:16:55.325: V/front_end(29639): UI-Console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v1.99.5
03-28 09:16:55.325: V/front_end(29639): UI-Console: using Input plugin: 'Mupen64Plus Android Input Plugin' v1.0.0
03-28 09:16:55.325: V/front_end(29639): UI-Console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v1.99.5
03-28 09:16:55.325: V/front_end(29639): Video: opening data/Glide64mk2.ini
03-28 09:16:55.435: V/front_end(29639): Video: Using TEXUMA extension.
03-28 09:16:55.435: I/SDL(29639): [STUB] GL_LoadLibrary
03-28 09:16:55.435: V/GameSurface(29639): Starting up OpenGL ES 2.0
03-28 09:16:55.445: I/SDL(29639): [STUB] GL_SetSwapInterval
03-28 09:16:55.445: I/SDL(29639): [STUB] GL_GetSwapInterval
03-28 09:16:55.485: V/front_end(29639): Video: Your video card doesn't support GL_ARB_texture_env_combine extension
03-28 09:16:55.485: V/front_end(29639): Video: Your video card doesn't support GL_ARB_multitexture extension
03-28 09:16:55.485: V/front_end(29639): Video: Your video card doesn't support GL_ARB_texture_mirrored_repeat extension
03-28 09:16:55.485: V/front_end(29639): Video: use_fbo 1
03-28 09:16:55.485: V/front_end(29639): Video: <<UNPRINTABLE-CHARACTERS>>
03-28 09:16:55.485: V/front_end(29639): Video: Compile OK shader 5
03-28 09:16:55.505: A/libc(29639): Fatal signal 11 (SIGSEGV) at 0x5469e1da (code=2), thread 29665 (d.mupen64plusae)
[/code]
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 28, 2013, 09:17:34 AM
I had it building with recent versions it's just I had a black screen so I went back. I don't know if it is the changes to SDL or GameSurface that caused me problems. Not sure about the crash did you try it without merging the later code?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on March 28, 2013, 09:38:35 AM
Yeah I was going to try that this evening.  That might be all it is.  As I said, don't sweat it right now.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on March 28, 2013, 10:18:40 AM
BTW, are you looking only for developer feedback at this particular stage, or are you ready to start reaching out to testers yet?  I've been compiling a list of emails for folks with various devices who have volunteered to test the new video plug-in (when it gets to that stage)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 28, 2013, 01:25:20 PM
BTW, are you looking only for developer feedback at this particular stage, or are you ready to start reaching out to testers yet?  I've been compiling a list of emails for folks with various devices who have volunteered to test the new video plug-in (when it gets to that stage)
I was used to it running at 5fps and thought the first version would be tricky to build but as I removed the dependencies and tried a non-debug build with a 2-3x improvement we're closer than I thought. On a high end device it might be playable already.

When it is working with the latest version and the depth and screensize issues are fixed testing would be great. Until then anyone is welcome to post an early apk I just didn't want to be swamped with issues when I know there are problems affecting all or many games.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on March 28, 2013, 01:40:04 PM
Ok, sure.  I'll hold of on the big test for now until a few more of the big issues are worked out.

Anyone who wants a "work in progress" apk in the mean time, just PM me and I'll send you a link.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on March 28, 2013, 04:02:05 PM
Works almost perfect for me. Few minor graphical glitches, relatively stable, and no sort order problem on my phone. Framebuffer->VRAM support would be the icing on the cake
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: scorpio16v on March 29, 2013, 08:53:02 AM
First, thank you for the provided download.
After a first short test with mario, I can confirm xperia64's experience for Tegra 3, the Allwinner A31 has the sort order Problem. On Nexus 4, I get only a black screen. Going back to menu, I can see the graphics in background.
At this stage, this plugin looks like a mixture of the 2 given plugins of the emulator.
For example on gles2n64, I get flickering parts of background on zelda 2 intro. On rice, I get black textures.
Glide does fix both.
Maybe you can patch the problems in the other plugins with some code of Glide ?

Should be only my first short impression of this plugin on my 3 different hardware devices. As Kris stated, it needs some more polish for regulare use.

Nevertheless, a very good start.  :)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 29, 2013, 11:36:58 AM
I pushed some changes. Screensize and depth issues are better.

The screensize problems were related to config code I hadn't touched, just setting the width and height when you call SDL_SetVideoMode is not enough and I didn't want to change the other parts of the plugin.

I made the changes to add these in CoreInterface.syncConfigFiles but this may be neater if placed in HardwareInfo? I'm more familiar with the native parts of mupen so you may know something more suitable.

I was a bit surprised about glPolygonOffset affecting the waterfall I was used to it affecting smaller decal type things. It being hardware dependent is a nuisance. There is code to find a value which I am not using but it seems to search for values much larger than those for android devices.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on March 29, 2013, 12:54:33 PM
Do you think the polygon offset values will probably be equivalent to the ones use by gles2n64 and rice?  If so, I put in a JNI interface function to query the "hardware type" and use that to look up the value to use (should be able to copy/ paste that code from one of the other plug-ins).  I wish there were a way to calculate this programmatically rather than setting it manually, but could be a usable workaround until a better solution is discovered (might be worth looking at that code you mentioned for finding a value, to see if anything they are doing could be useful)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on March 29, 2013, 01:07:42 PM
Just to keep you all in the loop, I'm currently pulling out all the paulscode-specific code (unique features, polygon offset hacks, etc) and consolidating them into a separate shared library.  The idea being (among other things) that Kris will only have to sprinkle a few one-liners into the glide plugin rather than manually copying big blocks of code between the plugins to get compatibility with the android app.  This should also further reduce the upstream diff for rice, sdl, front-end, and core.  So my suggestion is that you guys not sink lots of time smoothing over the interface between glide and the rest of mupen-ae... because it should hopefully be much simpler in the next week or so.

Also, regarding the java side, there are plenty of other devs who can smooth that stuff out so it's totally fine to just put something rough in there.  There's only one Kris who can make such headway on the native stuff. ;)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 29, 2013, 01:42:48 PM
Do you think the polygon offset values will probably be equivalent to the ones use by gles2n64 and rice?  If so, I put in a JNI interface function to query the "hardware type" and use that to look up the value to use (should be able to copy/ paste that code from one of the other plug-ins).  I wish there were a way to calculate this programmatically rather than setting it manually, but could be a usable workaround until a better solution is discovered (might be worth looking at that code you mentioned for finding a value, to see if anything they are doing could be useful)

Yep I think there is a good chance similar values would work. One thing that might be different is that the values are not constant in glide they do change as the frame is being drawn.

There is code to get a good value in glide but I don't know how well it will work, on the pc it used a value of 32 which I tried; that caused the water in mario and turok to be offset by like 3 metres. The pc was with a 24bit zbuffer though which did help on android too.

Just to keep you all in the loop, I'm currently pulling out all the paulscode-specific code (unique features, polygon offset hacks, etc) and consolidating them into a separate shared library.  The idea being (among other things) that Kris will only have to sprinkle a few one-liners into the glide plugin rather than manually copying big blocks of code between the plugins to get compatibility with the android app.  This should also further reduce the upstream diff for rice, sdl, front-end, and core.  So my suggestion is that you guys not sink lots of time smoothing over the interface between glide and the rest of mupen-ae... because it should hopefully be much simpler in the next week or so.

Also, regarding the java side, there are plenty of other devs who can smooth that stuff out so it's totally fine to just put something rough in there.  There's only one Kris who can make such headway on the native stuff. ;)
Some of that might be a good fit for the CoreVideo functions in api/vidext.c. I've mentioned to littleguy before that ideally the code to setup gl and swapbuffers should be the same whatever the platform.

Whatever you can do to make it easier sounds good.

Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on March 29, 2013, 01:53:55 PM
Some of that might be a good fit for the CoreVideo functions in api/vidext.c. I've mentioned to littleguy before that ideally the code to setup gl and swapbuffers should be the same whatever the platform.

Sure, that's good to keep in mind.  For now I'm just consolidating all paulscode features into one shared lib.  That should keep the traceability clearest.  From there we can see if anything makes sense pushing upstream, then split out that code and do a pull request then.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 30, 2013, 12:30:49 PM
I gave it a closer inspection and found the code to find the biasFactor needs functionality not supported on ES 2.0 so it looks like it will have to select based on hardware type. It should be possible to select it based on GL_RENDERER so the hardware type shouldn't need to be passed in from java, the latest commit has some rough code to do this but it just uses 0.2f for all devices.

The value is used a bit differently to in rice so they will probably need different values.

Maybe it is a good time to put a build or various builds with different offset values in the Testers Corner? If there are problems in the late stages of a game if the bug reporter could post a savestate that would be helpful too.

I know about the following problems and will try to sort them out soon:
In an older release there may have been some things the wrong colour (e.g, Perfect Dark Logo).

Anyone have any reports so far?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on March 30, 2013, 12:43:22 PM
Sometimes certain textures get wonky, but a reload of the emulator fixes them. In paper mario, the "switch ocean" glitch is present, where when one of the blue switches is hit, it keeps expanding and flattening even though it should've disappeared (happens in rice too).  I have the older release as the perfect dark logo is not colored correctly.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: scorpio16v on March 30, 2013, 01:10:23 PM
I don't know, if it has something to do with the known error, but as I said on Nexus 4 I have only a black screen.
Strange thing is, if I make a screenshoot with DDMS I can grab the graphic.
Don't know if a logcat is helpful. But I attached one.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on March 30, 2013, 07:10:23 PM
I really like the idea of doing the hardware profiling based on glGetString(GL_RENDERER) instead of the values in proc/cpuinfo.  I'm going to look at using that moving forward (this will be a great place to start - I can kill two birds with one stone).  I'm working on building the tests - should have them up soon.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on March 30, 2013, 10:09:53 PM
Sorry for the delay.  I'm having trouble figuring out what range of values to use for the test.  I ran through the following range of values on my Galaxy Nexus so far:

-4.0, -3.5, -3.0, -2.5, -2.0, -1.5, -1.0, -0.5, -0.2, 0.0, 0.2, 0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, and 4.0

None had any effect on the sort problem with Mario's head:

(http://www.paulscode.com/source/Mupen64Plus-AE/glide-tests/30MAR2013/head.png)

I did notice something between -0.2 and -0.5 with the waterfall.  -0.2 and larger always looks the same with the waterfall drawn on top of everything else:

(http://www.paulscode.com/source/Mupen64Plus-AE/glide-tests/30MAR2013/water-0.2.png)

-0.5 and less always looks the same with the waterfall missing entirely, but other background objects still drawn on top of foreground objects:

(http://www.paulscode.com/source/Mupen64Plus-AE/glide-tests/30MAR2013/water-0.5.png)

What I'm going to look at next is a finer granularity between -0.2 and -0.5 to see how it transitions between those last two images, and then expanding out from the values I've looked at so far.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on March 30, 2013, 10:12:42 PM
I should point out that this looks more like a lack of depth buffer than related to the bias.  Perhaps I am looking at the wrong behavior for determining a range of values for the bias factor?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 30, 2013, 10:32:44 PM
That looks like no depth buffer altogether. Try changing it from 24 to 16 in glitch64/main.cpp line 436.
I did think that the request for 16 bits in GameSurface.Java would be the one used and the sdl one ignored.

I did mean to keep it 16 when submitting as I remembered PowerVR not supporting it but I guess it slipped in.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on March 30, 2013, 10:34:17 PM
Yeah looks like depth test is disabled or buggy.  In my experience polygon offset is only for fixing z fighting with coplanar faces...

Edit. Ninja'd haha
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 30, 2013, 10:47:10 PM
Thanks for the info xperia64 and scorpio16v. The bug which goes away if you restart sounds like it could have be the one caused by me disabling something during testing and I think it should be better now. I will try to give the Paper Mario one a closer look, is that far into the game?

The nexus4 problems sound a bit familiar to what was happening when I tried using later versions of the emulator so when that is dealt with it may work, if not I should be able to do a bit of testing with a nexus4 at some stage.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on March 30, 2013, 11:34:24 PM
Try changing it from 24 to 16 in glitch64/main.cpp line 436.
I did think that the request for 16 bits in GameSurface.Java would be the one used and the sdl one ignored.

Changing it had no effect.  I'll do a couple tests to grab some information about what profile is getting chosen to make sure it is one of the ones with a depth buffer.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on March 31, 2013, 08:57:29 AM
Try using 24 in both both places. Looking at the docs it seems I was wrong and PowerVR does support 24bit. You could also try changing it from GL_DEPTH_COMPONENT16 to GL_DEPTH_COMPONENT24_OES at main.cpp line 881. Sorry I don't have a suitable device to test.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on March 31, 2013, 11:16:05 PM
The first switch is at the end of the path leading back to the town from goomba village which isnt that far (after you beat the goomba king)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: CatalystG on April 02, 2013, 12:38:51 PM
Awesome! Would you mind if I tried this on my BlackBerry port?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 02, 2013, 02:34:55 PM
Awesome! Would you mind if I tried this on my BlackBerry port?

Go for it, when it does work it seems to work quite well but there are devices and configurations with problems. You will probably need to tweak the biasFactor for glPolygonOffset, if you find a good value that would helpful to know as it should apply to other PowerVR devices. Currently there seems to be problems creating a depth buffer on android for PowerVR so look out for that too.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: CatalystG on April 02, 2013, 07:33:31 PM
It seems to work well on the BlackBerry Z10 so far, which is a Qualcomm S4. Tried Zelda OoT, Diddy Kong Racing and Super Mario. No depth issues that I've seen, though I'm creating the context in the frontend natively rather than through SDL. The glPolygonOffset seems to be okay too at it's default. A bit of flicker on some shadows in Super Mario but not bad at all. Speed seems a bit slower from my short test (that's with using the optimization flags). DKR has a fairly consistent stutter which doesn't happen on other plugins. Zelda doesn't have the subscreen crash which is nice. I've noticed a number of issues from Rice were fixed like the wood backing on the DKR menus. Seems to be the best of both gles2n64 and rice so far. Overall, an amazing start.

I'll give it a try on the PlayBook sometime (OMAP4/PowerVR) and see what issues there are.

Let me know if there's anything in particular you'd like me to test.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on April 02, 2013, 07:53:36 PM
No luck for me with the depth problem after tinkering in the settings.  I've tried with "SDL_GL_DEPTH_SIZE, 16", changing to 24 in GameSurface, and with using GL_DEPTH_COMPONENT24_OES.  Anyway, here is the test for other folks to use.  I still need to do some diagnostics to see what profile is getting selected to make sure its one with some depth.

Glide64 Test (http://www.paulscode.com/source/Mupen64Plus-AE/02APR2013/mupen64plus-ae.apk)

I added a preference dialog to the Video settings for selecting the bias factor, which is easier than posting a series of tests builds with different values :)

If depth is working and you find a good bias factor, please post it and send me the logcat output so I can see what string it returned for the renderer.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on April 02, 2013, 08:12:23 PM
I can't find a good bias factor. It worked perfectly in the old build (except for a few gaps in some of the polys)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Evil King Stan on April 02, 2013, 08:54:08 PM
I tried using this but I'm running into a bit of a speed bump. The test apk installs separately just like all of your other tests do, that's normal other than the fact that the app is named Mupen64 Plus AE like the official build instead of just Mupen64Plus like other tests. I open it fine, change the plugin to Glide, everything is fine. When I press Controller option to do my key mappings, android asks me which application to complete the action with, both are named Mupen64 Plus AE. The top one has a caption under it that says paulscode.android.mupen64plus, the bottom one has a caption that reads paulscode.android.mupen64plusae. I tried both just to be sure and keys mapped fine on both. (Although I'm certain that the bottom app is the Glide test as paulscode.android.mupen64plusae was the folder it told me it was downloading the resources to when I first started the app.) After that I selected Mario 64 in the game menu and clicked Play. Android again asked me to pick an app, I chose the bottom one and I was brought to the menu to chose Resume or Restart. Either one immediately force closes the emulator. I then tried the top app and picked restart. The emulator then chose to run Ocarina of Time, (the game I have selected in the official build) and is playing it using what I am absolutely sure is gels2n64. (The video plugin I have selected on the official build.) Choosing the top app makes it use the official build. (I'm sure of this because changing the game in the official build to Banjo-Kazooie makes the test apk play Banjo-Kazooie. Unless I chose the bottom app in which case it doesn't run at all.) I also tried uninstalling and reinstalling, without messing with any settings other than switching to the Glide plugin, same result. I'd love to test, but I can't until I can sort this out. Any insight would be appreciated.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 02, 2013, 09:34:28 PM
Thanks for sorting out the test. It seems like 0.2 is a bit high for adreno, shadows render solid but in-front of the object. Maybe other gpus will also need finer than 0.2 adjustments.

I don't know why the depthbuffer is not working assuming that is really the problem and it doesn't just look like it. I just tried to initialize the same way as the other plugins.

You can see how many bits are actually being used by doing something like the following after SDL_SetVideoMode in glitch64/main.cpp
Code: [Select]
GLint depthBits;
glGetIntegerv(GL_DEPTH_BITS,&depthBits);

The plugin works with the first commit that changed it from SurfaceView to GLSurfaceView so something between then and current version is causing the problems I look again soon.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: scorpio16v on April 02, 2013, 11:44:23 PM
Test on Super Mario 64:
On my tablet with A31 CPU, graphics are messed like in the old version.
On Nexus 4, I can see only only the "Super Mario64" screen for a second. After that, the screen is black again.
If I go back to menu, the graphics is shown for a second. Same as the first test, but the graphic looks fine now.
If you can solve the black screen issue, maybe that could be the right setting for this hardware.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Tom.K on April 03, 2013, 09:13:03 AM
No luck for me with the depth problem after tinkering in the settings.  I've tried with "SDL_GL_DEPTH_SIZE, 16", changing to 24 in GameSurface, and with using GL_DEPTH_COMPONENT24_OES.  Anyway, here is the test for other folks to use.  I still need to do some diagnostics to see what profile is getting selected to make sure its one with some depth.

Glide64 Test (http://www.paulscode.com/source/Mupen64Plus-AE/02APR2013/mupen64plus-ae.apk)

I added a preference dialog to the Video settings for selecting the bias factor, which is easier than posting a series of tests builds with different values :)

If depth is working and you find a good bias factor, please post it and send me the logcat output so I can see what string it returned for the renderer.
I'm not able to launch any game using any video plugin.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: scorpio16v on April 03, 2013, 09:01:41 PM
Some remark about the black screen on N4. It doesn't seem related to the plugin.
If I switch the volume buttons up or down and the loudness bar is faded onscreen, the graphics are visible.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 04, 2013, 04:22:25 PM
I found out was was causing a blank screen when using glide with the latest version, it wasn't even related to graphics.  ::)

When the window is opened glide changes the window caption, this used to change the title on android too but for some reason in the more recent versions it causes an exception.

I pushed the fix to not set the title and merged the latest version, there shouldn't be any other noteworthy changes to glide but maybe with the other changes to the emulator it might work for more devices.

I plan to look try an online device testing service to help with some of the issues. Samsung (http://developer.samsung.com/remotetestlab/rtlDeviceList.action#) have a free one and there are others, anyone have experience with these?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on April 04, 2013, 05:28:57 PM
Whoops, looks like its actually framebuffer->RDRAM copy thats needed, not framebuffer->vram. Curious as to if Glide64 even has that, I know napalm does..
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 04, 2013, 06:09:43 PM
Whoops, looks like its actually framebuffer->RDRAM copy thats needed, not framebuffer->vram. Curious as to if Glide64 even has that, I know napalm does..
I've found most of the framebuffer stuff to work as it does with glide64mk2 on the PC. The large screen in Mario Kart is blank for me on android and pc unless I enable fb_read_always. You can change this in glide64mk2.ini [DEFAULT] not [SETTINGS] section. I don't think exposing every gfx option in the app is a good idea.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on April 04, 2013, 06:26:28 PM
Wow!! The puzzle piece intro in banjo-kazooie actually works, albeit a lot slower
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: mudlord on April 06, 2013, 08:12:19 PM
of course its slower, you need to read every single frame for a CPU based fb effect to work.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 16, 2013, 02:05:44 PM
Can this be mirrored over to the github repo now?  I'd like to start test merges with the new ae-bridge library and SDL 2.0.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 16, 2013, 07:57:06 PM
Just got around to checking this out again.  I was getting force closes on launch due to a segfault, regardless of whether I merged to master first or not.  I traced it down to some SDL initialization stuff in main.cpp, which was easily solved by reverting some lines of code back to the upstream version:

Spoiler: "patch" • show
[code]
diff --git a/jni/gles2glide64/src/Glitch64/main.cpp b/jni/gles2glide64/src/Glitch64/main.cpp
index 664cf26..1983768 100644
--- a/jni/gles2glide64/src/Glitch64/main.cpp
+++ b/jni/gles2glide64/src/Glitch64/main.cpp
@@ -426,32 +426,21 @@ grSstWinOpen(
   viewport_offset = 0; //-10 //-20;
 
   // ZIGGY not sure, but it might be better to let the system choose
-//  CoreVideo_GL_SetAttribute(M64P_GL_DOUBLEBUFFER, 1);
-//  CoreVideo_GL_SetAttribute(M64P_GL_SWAP_CONTROL, vsync);
-//  CoreVideo_GL_SetAttribute(M64P_GL_BUFFER_SIZE, 16);
-     SDL_GL_SetAttribute(SDL_GL_BUFFER_SIZE, 32);
-     SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
-     SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
-     SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);
-     SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 24);
-  //CoreVideo_GL_SetAttribute(M64P_GL_DEPTH_SIZE, 24);
-
-//  printf("(II) Setting video mode %dx%d...\n", width, height);
-
-  if (SDL_InitSubSystem( SDL_INIT_VIDEO ) == -1)
+  CoreVideo_GL_SetAttribute(M64P_GL_DOUBLEBUFFER, 1);
+  CoreVideo_GL_SetAttribute(M64P_GL_SWAP_CONTROL, vsync);
+  CoreVideo_GL_SetAttribute(M64P_GL_BUFFER_SIZE, 16);
+  //   SDL_GL_SetAttribute(SDL_GL_BUFFER_SIZE, 32);
+  //   SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
+  //   SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
+  //   SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);
+  //   SDL_GL_SetAttribute(SDL_GL_ALPHA_SIZE, 8);
+  CoreVideo_GL_SetAttribute(M64P_GL_DEPTH_SIZE, 16);
+
+  printf("(II) Setting video mode %dx%d...\n", width, height);
+  if(CoreVideo_SetVideoMode(width, height, 0, fullscreen ? M64VIDEO_FULLSCREEN : M64VIDEO_WINDOWED) != M64ERR_SUCCESS)
   {
-      LOGINFO( "Error initializing SDL video subsystem: %s\n", SDL_GetError() );
-      return false;
-  }
-
-
-
-  SDL_Surface* hScreen;
-  if (!(hScreen = SDL_SetVideoMode( width, height, 32, SDL_HWSURFACE )))
-  {
-     LOGINFO("Problem setting videomode %dx%d: %s\n", width, height, SDL_GetError());
-      SDL_QuitSubSystem( SDL_INIT_VIDEO );
-      return false;
+    printf("(EE) Error setting videomode %dx%d\n", width, height);
+    return false;
   }
 
   char caption[500];
[/code]


This might fix the issue Paul was having with the depth buffer, possibly.

Anyhow, some recent bugfixes and cleanups on master have removed the need to even touch the java code for glide plugin compatibility.  E.g. CoreVideo_SetCaption is now safe and the config file is now populated with the correct screen dimension.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 16, 2013, 08:35:43 PM
Ok once again I spoke too soon. ::)  Nevermind what I just said, turns out the glide library wasn't even loading so the core was quietly reverting to Rice instead of crashing.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 16, 2013, 09:28:27 PM
This might fix the issue Paul was having with the depth buffer, possibly.
I haven't heard back about whether it worked when when I first disabled CoreVideo_SetCaption. As things are setup with the java egl code neither SDL_GL_SetAttribute or CoreVideo_GL_SetAttribute probably do anything useful anyway. I will try remote testing a PowerVR device again soon although yesterday when I tried it just timed out.

Anyhow, some recent bugfixes and cleanups on master have removed the need to even touch the java code for glide plugin compatibility.  E.g. CoreVideo_SetCaption is now safe and the config file is now populated with the correct screen dimension.
The fewer changes needed the better. I think there is room to simplify some things further maybe just being source files to pick and choose instead of being a library. I mentioned that the polygon offset stuff should be possible without passing the hardware type from java but as they are used differently in rice vs glide I don't think it can be shared.

Has it been considered to pass all the frameskip, screenstrech, bit-depth etc by config or as one big struct instead of separately?

Ok once again I spoke too soon. ::)  Nevermind what I just said, turns out the glide library wasn't even loading so the core was quietly reverting to Rice instead of crashing.
I ran into that too, when CoreVideo_SetCaption worked it changed the title so you could tell. It might be the removal of SDL_InitSubsystem you mention in that patch.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 16, 2013, 09:51:02 PM
As things are setup with the java egl code neither SDL_GL_SetAttribute or CoreVideo_GL_SetAttribute probably do anything useful anyway.
You're right, they don't do anything in SDL 1.3, but they actually do get used in SDL 2.0.  Which is now integrated in a test branch on github.

The fewer changes needed the better. I think there is room to simplify some things further maybe just being source files to pick and choose instead of being a library. I mentioned that the polygon offset stuff should be possible without passing the hardware type from java but as they are used differently in rice vs glide I don't think it can be shared.
I agree, would be best not to involve java at all for polygon offset.  I just noticed your code that grabs the gl renderer.  Pretty slick, definitely worth developing on, as it would be much more transparent to the user and java, and easier to maintain in the long run.

Has it been considered to pass all the frameskip, screenstrech, bit-depth etc by config or as one big struct instead of separately?
That's actually next on my agenda after we get the last kinks out of the SDL 2.0 integration.  Most of the custom JNI functions in the ae-bridge are just this kind of static stuff, which really belongs in the config file.

I ran into that too, when CoreVideo_SetCaption worked it changed the title so you could tell. It might be the removal of SDL_InitSubsystem you mention in that patch.
Yeah, could be.  Either way, using the mupen CoreVideo abstraction rather than the SDL api directly is more in the "mupen spirit" and would sit better with me if it works.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 16, 2013, 10:02:43 PM
By the way, I just tested glide with SDL 2.0 and it worked without a hiccup 8) (on my xperia play that is).  First impression, didn't notice any performance improvement (or regression) in a quick run around the outside of the mario 64 castle (~18-25 FPS).

Still getting a segfault with glide on my Nexus 7, no matter where I merge.  Any suggestions on how to track it down?  Looks like something in the Tegra gles2 drivers.  Here's the logcat (with backtrace) in case it helps:

Spoiler: logcat • show
[code]
04-16 22:57:47.132: V/front_end(26425):  __  __                         __   _  _   ____  _             
04-16 22:57:47.132: V/front_end(26425): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___
04-16 22:57:47.132: V/front_end(26425): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __| 
04-16 22:57:47.132: V/front_end(26425): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \ 
04-16 22:57:47.132: V/front_end(26425): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/ 
04-16 22:57:47.132: V/front_end(26425):              |_|         http://code.google.com/p/mupen64plus/ 
04-16 22:57:47.132: V/front_end(26425): Mupen64Plus Console User-Interface Version 1.99.5
04-16 22:57:47.132: I/UI-Console(26425): Info: attached to core library 'Mupen64Plus Core' version 1.99.5
04-16 22:57:47.132: I/UI-Console(26425): Info:             Includes support for Dynamic Recompiler.
04-16 22:57:47.132: I/Core(26425): Info: Updating parameter set version in 'Core' config section to 1.01
04-16 22:57:47.752: I/Core(26425): Info: Goodname: Super Mario 64 (U) [!]
04-16 22:57:47.752: I/Core(26425): Info: Name: SUPER MARIO 64     
04-16 22:57:47.752: I/Core(26425): Info: MD5: 20B854B239203BAF6C961B850A4A51A2
04-16 22:57:47.752: I/Core(26425): Info: CRC: 635a2bff 8b022326
04-16 22:57:47.752: I/Core(26425): Info: Imagetype: .z64 (native)
04-16 22:57:47.752: I/Core(26425): Info: Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
04-16 22:57:47.752: I/Core(26425): Info: Version: 1444
04-16 22:57:47.752: I/Core(26425): Info: Manufacturer: Nintendo
04-16 22:57:47.752: I/Core(26425): Info: Country: USA
04-16 22:57:47.762: D/UI-Console(26425): Status: Cheat codes disabled.
04-16 22:57:47.762: I/UI-Console(26425): Info: using Video plugin: 'Glide64mk2 Video Plugin' v1.99.4
04-16 22:57:47.762: I/UI-Console(26425): Info: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v1.99.5
04-16 22:57:47.762: I/UI-Console(26425): Info: using Input plugin: 'Mupen64Plus Android Input Plugin' v1.0.0
04-16 22:57:47.762: I/UI-Console(26425): Info: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v1.99.5
04-16 22:57:47.762: I/Video(26425): Info: opening data/Glide64mk2.ini
04-16 22:57:47.862: I/Video(26425): Info: Using TEXUMA extension.
04-16 22:57:47.862: I/SDL(26425): [STUB] GL_LoadLibrary
04-16 22:57:47.862: V/GameSurface(26425): Starting up OpenGL ES 2.0
04-16 22:57:47.872: I/SDL(26425): [STUB] GL_SetSwapInterval
04-16 22:57:47.872: I/SDL(26425): [STUB] GL_GetSwapInterval
04-16 22:57:47.912: I/Video(26425): Info: Your video card doesn't support GL_ARB_texture_env_combine extension
04-16 22:57:47.912: I/Video(26425): Info: Your video card doesn't support GL_ARB_multitexture extension
04-16 22:57:47.912: I/Video(26425): Info: Your video card doesn't support GL_ARB_texture_mirrored_repeat extension
04-16 22:57:47.912: I/Video(26425): Info: use_fbo 1
04-16 22:57:47.912: I/Video(26425): Info: Renderer:NVIDIA Tegra 3 biasFactor:0.200000
04-16 22:57:47.982: A/libc(26425): Fatal signal 11 (SIGSEGV) at 0x5469613a (code=2), thread 26451 (d.mupen64plusae)
04-16 22:57:48.082: I/DEBUG(124): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
04-16 22:57:48.082: I/DEBUG(124): Build fingerprint: 'google/nakasi/grouper:4.2.2/JDQ39/573038:user/release-keys'
04-16 22:57:48.082: I/DEBUG(124): Revision: '0'
04-16 22:57:48.082: I/DEBUG(124): pid: 26425, tid: 26451, name: d.mupen64plusae  >>> paulscode.android.mupen64plusae <<<
04-16 22:57:48.082: I/DEBUG(124): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 5469613a
04-16 22:57:48.622: I/DEBUG(124):     r0 00000001  r1 643e1960  r2 5469610e  r3 69845c38
04-16 22:57:48.622: I/DEBUG(124):     r4 5469610e  r5 643e1960  r6 69845c34  r7 69845c38
04-16 22:57:48.622: I/DEBUG(124):     r8 00000000  r9 643e1a98  sl 11698462  fp 00000001
04-16 22:57:48.622: I/DEBUG(124):     ip 00000005  sp 69845c08  lr 696175df  pc 695f48ca  cpsr 20000030
04-16 22:57:48.622: I/DEBUG(124):     d0  4010000040800000  d1  402a2dd63f800000
04-16 22:57:48.622: I/DEBUG(124):     d2  41cef8fd0368b75b  d3  c190000000000010
04-16 22:57:48.622: I/DEBUG(124):     d4  c18d0400c1890400  d5  40c0000041300000
04-16 22:57:48.622: I/DEBUG(124):     d6  41800000ffffffeb  d7  4080000000000000
04-16 22:57:48.622: I/DEBUG(124):     d8  0000000000000000  d9  0000000000000000
04-16 22:57:48.622: I/DEBUG(124):     d10 0000000000000000  d11 0000000000000000
04-16 22:57:48.622: I/DEBUG(124):     d12 0000000000000000  d13 0000000000000000
04-16 22:57:48.622: I/DEBUG(124):     d14 0000000000000000  d15 0000000000000000
04-16 22:57:48.622: I/DEBUG(124):     d16 4010000000000000  d17 4030000000000000
04-16 22:57:48.622: I/DEBUG(124):     d18 41c257e054800000  d19 41cef8fd03000000
04-16 22:57:48.622: I/DEBUG(124):     d20 0000000004040404  d21 0000000000000000
04-16 22:57:48.622: I/DEBUG(124):     d22 0707070703030303  d23 0000001200000011
04-16 22:57:48.622: I/DEBUG(124):     d24 0000000000000001  d25 000000000000018a
04-16 22:57:48.622: I/DEBUG(124):     d26 0100010001000100  d27 0100010001000100
04-16 22:57:48.622: I/DEBUG(124):     d28 0100010001000100  d29 0100010001000100
04-16 22:57:48.622: I/DEBUG(124):     d30 0000000100000001  d31 0000000100000001
04-16 22:57:48.622: I/DEBUG(124):     scr 60000090
04-16 22:57:48.632: I/DEBUG(124): backtrace:
04-16 22:57:48.632: I/DEBUG(124):     #00  pc 0018c8ca  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #01  pc 001af5dd  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #02  pc 001af703  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #03  pc 001af7db  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #04  pc 001af8ff  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #05  pc 0018c811  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #06  pc 001afcb1  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #07  pc 00193721  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #08  pc 0019c96b  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #09  pc 0018a033  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #10  pc 001787e1  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #11  pc 000fbb45  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #12  pc 000a618b  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #13  pc 000a6455  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #14  pc 000a4123  /system/lib/libcgdrv.so (CgDrv_Compile+374)
04-16 22:57:48.632: I/DEBUG(124):     #15  pc 00009320  /system/lib/egl/libGLESv2_tegra.so
04-16 22:57:48.632: I/DEBUG(124):     #16  pc 000095fc  /system/lib/egl/libGLESv2_tegra.so
04-16 22:57:48.632: I/DEBUG(124):     #17  pc 00035708  /system/lib/egl/libGLESv2_tegra.so
04-16 22:57:48.632: I/DEBUG(124):     #18  pc 00004d94  /system/lib/libnvos.so
04-16 22:57:48.632: I/DEBUG(124):     #19  pc 0000e3d8  /system/lib/libc.so (__thread_entry+72)
04-16 22:57:48.632: I/DEBUG(124):     #20  pc 0000dac4  /system/lib/libc.so (pthread_create+160)
04-16 22:57:48.632: I/DEBUG(124): stack:
04-16 22:57:48.632: I/DEBUG(124):          69845bc8  643e7b18 
04-16 22:57:48.632: I/DEBUG(124):          69845bcc  643e19d8 
04-16 22:57:48.632: I/DEBUG(124):          69845bd0  643e7b18 
04-16 22:57:48.632: I/DEBUG(124):          69845bd4  00000000 
04-16 22:57:48.632: I/DEBUG(124):          69845bd8  00000000 
04-16 22:57:48.632: I/DEBUG(124):          69845bdc  00000000 
04-16 22:57:48.632: I/DEBUG(124):          69845be0  00000000 
04-16 22:57:48.632: I/DEBUG(124):          69845be4  00000000 
04-16 22:57:48.632: I/DEBUG(124):          69845be8  00000000 
04-16 22:57:48.632: I/DEBUG(124):          69845bec  643e1960 
04-16 22:57:48.632: I/DEBUG(124):          69845bf0  00000042 
04-16 22:57:48.632: I/DEBUG(124):          69845bf4  643e1960 
04-16 22:57:48.632: I/DEBUG(124):          69845bf8  00000042 
04-16 22:57:48.632: I/DEBUG(124):          69845bfc  00000000 
04-16 22:57:48.632: I/DEBUG(124):          69845c00  df0027ad 
04-16 22:57:48.632: I/DEBUG(124):          69845c04  00000000 
04-16 22:57:48.632: I/DEBUG(124):     #00  69845c08  69845c38 
04-16 22:57:48.632: I/DEBUG(124):          69845c0c  69845d58 
04-16 22:57:48.632: I/DEBUG(124):          69845c10  69845d1f 
04-16 22:57:48.632: I/DEBUG(124):          69845c14  695f48af  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):          69845c18  00000001 
04-16 22:57:48.632: I/DEBUG(124):          69845c1c  643eca70 
04-16 22:57:48.632: I/DEBUG(124):          69845c20  11698462 
04-16 22:57:48.632: I/DEBUG(124):          69845c24  696175df  /system/lib/libcgdrv.so
04-16 22:57:48.632: I/DEBUG(124):     #01  69845c28  69845c34 
04-16 22:57:48.632: I/DEBUG(124):          69845c2c  00000002 
04-16 22:57:48.632: I/DEBUG(124):          69845c30  00000042 
04-16 22:57:48.632: I/DEBUG(124):          69845c34  00000000 
04-16 22:57:48.632: I/DEBUG(124):          69845c38  00000000 
04-16 22:57:48.632: I/DEBUG(124):          69845c3c  00000001 
04-16 22:57:48.632: I/DEBUG(124):          69845c40  ffffffff 
04-16 22:57:48.632: I/DEBUG(124):          69845c44  00000000 
04-16 22:57:48.642: I/DEBUG(124):          69845c48  00000001 
04-16 22:57:48.642: I/DEBUG(124):          69845c4c  00000000 
04-16 22:57:48.642: I/DEBUG(124):          69845c50  ffffffff 
04-16 22:57:48.642: I/DEBUG(124):          69845c54  00000000 
04-16 22:57:48.642: I/DEBUG(124):          69845c58  00000002 
04-16 22:57:48.642: I/DEBUG(124):          69845c5c  00000000 
04-16 22:57:48.642: I/DEBUG(124):          69845c60  ffffffff 
04-16 22:57:48.642: I/DEBUG(124):          69845c64  00000000 
04-16 22:57:48.642: I/DEBUG(124):          ........  ........
04-16 22:57:48.642: I/DEBUG(124):     #02  69845d10  00000001 
04-16 22:57:48.642: I/DEBUG(124):          69845d14  69845d1f 
04-16 22:57:48.642: I/DEBUG(124):          69845d18  69845e50 
04-16 22:57:48.642: I/DEBUG(124):          69845d1c  643e1960 
04-16 22:57:48.642: I/DEBUG(124):          69845d20  643eca70 
04-16 22:57:48.642: I/DEBUG(124):          69845d24  00000000 
04-16 22:57:48.642: I/DEBUG(124):          69845d28  69845e50 
04-16 22:57:48.642: I/DEBUG(124):          69845d2c  643eca70 
04-16 22:57:48.642: I/DEBUG(124):          69845d30  643e1960 
04-16 22:57:48.642: I/DEBUG(124):          69845d34  00000000 
04-16 22:57:48.642: I/DEBUG(124):          69845d38  69845e50 
04-16 22:57:48.642: I/DEBUG(124):          69845d3c  00000001 
04-16 22:57:48.642: I/DEBUG(124):          69845d40  0000000c 
04-16 22:57:48.642: I/DEBUG(124):          69845d44  696177df  /system/lib/libcgdrv.so
04-16 22:57:48.652: I/DEBUG(124): memory near r1:
04-16 22:57:48.652: I/DEBUG(124):     643e1940 00000000 00000000 00000004 00000000 
04-16 22:57:48.652: I/DEBUG(124):     643e1950 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     643e1960 643e1250 643e2458 0000005e 000001f6 
04-16 22:57:48.652: I/DEBUG(124):     643e1970 643ece50 643e8748 00000000 643eb320 
04-16 22:57:48.652: I/DEBUG(124):     643e1980 00000002 00000002 0000003a 643e60a8 
04-16 22:57:48.652: I/DEBUG(124):     643e1990 00000006 000001f6 00000001 00000028 
04-16 22:57:48.652: I/DEBUG(124):     643e19a0 643ec238 00000007 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     643e19b0 00000000 00000000 643e4d70 643e8490 
04-16 22:57:48.652: I/DEBUG(124):     643e19c0 643e55d0 00000001 000001f4 643e4db8 
04-16 22:57:48.652: I/DEBUG(124):     643e19d0 00000000 000001f4 643e7b18 00000008 
04-16 22:57:48.652: I/DEBUG(124):     643e19e0 000001f6 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     643e19f0 643e8950 00000028 000001f6 643e9150 
04-16 22:57:48.652: I/DEBUG(124):     643e1a00 00000001 000001f6 00000000 00000008 
04-16 22:57:48.652: I/DEBUG(124):     643e1a10 ffffffff 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     643e1a20 00000000 643e8938 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     643e1a30 00000001 00000001 643ed380 00000003 
04-16 22:57:48.652: I/DEBUG(124): memory near r2:
04-16 22:57:48.652: I/DEBUG(124):     546960ec 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     546960fc 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469610c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469611c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469612c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469613c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469614c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469615c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469616c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469617c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469618c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469619c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     546961ac 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     546961bc 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     546961cc 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     546961dc 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124): memory near r3:
04-16 22:57:48.652: I/DEBUG(124):     69845c18 00000001 643eca70 11698462 696175df 
04-16 22:57:48.652: I/DEBUG(124):     69845c28 69845c34 00000002 00000042 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845c38 00000000 00000001 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845c48 00000001 00000000 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845c58 00000002 00000000 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845c68 00000003 00000000 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845c78 00000005 00000000 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845c88 00000006 00000000 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845c98 00000007 00000000 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845ca8 00000008 00000000 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845cb8 00000009 00000000 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845cc8 0000000a 00000000 ffffffff 00000000 
04-16 22:57:48.652: I/DEBUG(124):     69845cd8 0000000b 00000000 643e88a8 643e1960 
04-16 22:57:48.652: I/DEBUG(124):     69845ce8 643eb3f0 69845e50 00000000 69846101 
04-16 22:57:48.652: I/DEBUG(124):     69845cf8 69845d58 643e1960 643eca70 11698462 
04-16 22:57:48.652: I/DEBUG(124):     69845d08 00000001 69617707 00000001 69845d1f 
04-16 22:57:48.652: I/DEBUG(124): memory near r4:
04-16 22:57:48.652: I/DEBUG(124):     546960ec 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     546960fc 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469610c 00000000 00000000 00000000 00000000 
04-16 22:57:48.652: I/DEBUG(124):     5469611c 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     5469612c 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     5469613c 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     5469614c 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     5469615c 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     5469616c 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     5469617c 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     5469618c 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     5469619c 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     546961ac 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     546961bc 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     546961cc 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     546961dc 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124): memory near r5:
04-16 22:57:48.662: I/DEBUG(124):     643e1940 00000000 00000000 00000004 00000000 
04-16 22:57:48.662: I/DEBUG(124):     643e1950 00000000 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     643e1960 643e1250 643e2458 0000005e 000001f6 
04-16 22:57:48.662: I/DEBUG(124):     643e1970 643ece50 643e8748 00000000 643eb320 
04-16 22:57:48.662: I/DEBUG(124):     643e1980 00000002 00000002 0000003a 643e60a8 
04-16 22:57:48.662: I/DEBUG(124):     643e1990 00000006 000001f6 00000001 00000028 
04-16 22:57:48.662: I/DEBUG(124):     643e19a0 643ec238 00000007 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     643e19b0 00000000 00000000 643e4d70 643e8490 
04-16 22:57:48.662: I/DEBUG(124):     643e19c0 643e55d0 00000001 000001f4 643e4db8 
04-16 22:57:48.662: I/DEBUG(124):     643e19d0 00000000 000001f4 643e7b18 00000008 
04-16 22:57:48.662: I/DEBUG(124):     643e19e0 000001f6 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     643e19f0 643e8950 00000028 000001f6 643e9150 
04-16 22:57:48.662: I/DEBUG(124):     643e1a00 00000001 000001f6 00000000 00000008 
04-16 22:57:48.662: I/DEBUG(124):     643e1a10 ffffffff 00000000 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     643e1a20 00000000 643e8938 00000000 00000000 
04-16 22:57:48.662: I/DEBUG(124):     643e1a30 00000001 00000001 643ed380 00000003 
04-16 22:57:48.662: I/DEBUG(124): memory near r6:
04-16 22:57:48.662: I/DEBUG(124):     69845c14 695f48af 00000001 643eca70 11698462 
04-16 22:57:48.662: I/DEBUG(124):     69845c24 696175df 69845c34 00000002 00000042 
04-16 22:57:48.662: I/DEBUG(124):     69845c34 00000000 00000000 00000001 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845c44 00000000 00000001 00000000 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845c54 00000000 00000002 00000000 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845c64 00000000 00000003 00000000 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845c74 00000000 00000005 00000000 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845c84 00000000 00000006 00000000 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845c94 00000000 00000007 00000000 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845ca4 00000000 00000008 00000000 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845cb4 00000000 00000009 00000000 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845cc4 00000000 0000000a 00000000 ffffffff 
04-16 22:57:48.662: I/DEBUG(124):     69845cd4 00000000 0000000b 00000000 643e88a8 
04-16 22:57:48.662: I/DEBUG(124):     69845ce4 643e1960 643eb3f0 69845e50 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845cf4 69846101 69845d58 643e1960 643eca70 
04-16 22:57:48.662: I/DEBUG(124):     69845d04 11698462 00000001 69617707 00000001 
04-16 22:57:48.662: I/DEBUG(124): memory near r7:
04-16 22:57:48.662: I/DEBUG(124):     69845c18 00000001 643eca70 11698462 696175df 
04-16 22:57:48.662: I/DEBUG(124):     69845c28 69845c34 00000002 00000042 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845c38 00000000 00000001 ffffffff 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845c48 00000001 00000000 ffffffff 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845c58 00000002 00000000 ffffffff 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845c68 00000003 00000000 ffffffff 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845c78 00000005 00000000 ffffffff 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845c88 00000006 00000000 ffffffff 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845c98 00000007 00000000 ffffffff 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845ca8 00000008 00000000 ffffffff 00000000 
04-16 22:57:48.662: I/DEBUG(124):     69845cb8 00000009 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845cc8 0000000a 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845cd8 0000000b 00000000 643e88a8 643e1960 
04-16 22:57:48.672: I/DEBUG(124):     69845ce8 643eb3f0 69845e50 00000000 69846101 
04-16 22:57:48.672: I/DEBUG(124):     69845cf8 69845d58 643e1960 643eca70 11698462 
04-16 22:57:48.672: I/DEBUG(124):     69845d08 00000001 69617707 00000001 69845d1f 
04-16 22:57:48.672: I/DEBUG(124): memory near r9:
04-16 22:57:48.672: I/DEBUG(124):     643e1a78 00000000 00000000 00000000 0001d528 
04-16 22:57:48.672: I/DEBUG(124):     643e1a88 00000001 643e1a98 643e2260 00000000 
04-16 22:57:48.672: I/DEBUG(124):     643e1a98 6973ed88 643e1960 643e2048 643e2108 
04-16 22:57:48.672: I/DEBUG(124):     643e1aa8 00000000 00000000 00000000 00000000 
04-16 22:57:48.672: I/DEBUG(124):     643e1ab8 00000000 00000000 00000000 00010000 
04-16 22:57:48.672: I/DEBUG(124):     643e1ac8 00000001 00000001 00000001 00000001 
04-16 22:57:48.672: I/DEBUG(124):     643e1ad8 00000000 00000101 00000000 00000000 
04-16 22:57:48.672: I/DEBUG(124):     643e1ae8 00000001 00000001 00000001 00000001 
04-16 22:57:48.672: I/DEBUG(124):     643e1af8 00000001 00000001 00000001 00000001 
04-16 22:57:48.672: I/DEBUG(124):     643e1b08 00000001 00000001 00000000 00000000 
04-16 22:57:48.672: I/DEBUG(124):     643e1b18 00000000 00000000 00000000 00000000 
04-16 22:57:48.672: I/DEBUG(124):     643e1b28 00000000 00000000 00000000 00000000 
04-16 22:57:48.672: I/DEBUG(124):     643e1b38 00000000 00000000 00000000 00000000 
04-16 22:57:48.672: I/DEBUG(124):     643e1b48 00000000 00000000 00000000 00000000 
04-16 22:57:48.672: I/DEBUG(124):     643e1b58 00000000 00000000 00000000 00000000 
04-16 22:57:48.672: I/DEBUG(124):     643e1b68 00000000 00000000 00000000 00000000 
04-16 22:57:48.672: I/DEBUG(124): memory near sl:
04-16 22:57:48.672: I/DEBUG(124):     11698440 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     11698450 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     11698460 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     11698470 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     11698480 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     11698490 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     116984a0 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     116984b0 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     116984c0 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     116984d0 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     116984e0 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     116984f0 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     11698500 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     11698510 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     11698520 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124):     11698530 ffffffff ffffffff ffffffff ffffffff 
04-16 22:57:48.672: I/DEBUG(124): memory near sp:
04-16 22:57:48.672: I/DEBUG(124):     69845be8 00000000 643e1960 00000042 643e1960 
04-16 22:57:48.672: I/DEBUG(124):     69845bf8 00000042 00000000 df0027ad 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845c08 69845c38 69845d58 69845d1f 695f48af 
04-16 22:57:48.672: I/DEBUG(124):     69845c18 00000001 643eca70 11698462 696175df 
04-16 22:57:48.672: I/DEBUG(124):     69845c28 69845c34 00000002 00000042 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845c38 00000000 00000001 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845c48 00000001 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845c58 00000002 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845c68 00000003 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845c78 00000005 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845c88 00000006 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845c98 00000007 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845ca8 00000008 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845cb8 00000009 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845cc8 0000000a 00000000 ffffffff 00000000 
04-16 22:57:48.672: I/DEBUG(124):     69845cd8 0000000b 00000000 643e88a8 643e1960 
04-16 22:57:48.672: I/DEBUG(124): code around pc:
04-16 22:57:48.672: I/DEBUG(124):     695f48a8 20c3f3c0 e92dbd10 200147f0 461f9e08 
04-16 22:57:48.672: I/DEBUG(124):     695f48b8 912cf8d1 0800f04f 4614460d 8000f8c6 
04-16 22:57:48.672: I/DEBUG(124):     695f48c8 6ad36058 5380f423 d0162bc2 2b38d805 
04-16 22:57:48.672: I/DEBUG(124):     695f48d8 2b39d03b 80c9f040 2bf4e03c 2bf5d03a 
04-16 22:57:48.672: I/DEBUG(124):     695f48e8 80c3f040 f7f34610 230cfa83 fb031e42 
04-16 22:57:48.672: I/DEBUG(124):     695f48f8 6ba14402 f140034a 210080b8 f04f2201 
04-16 22:57:48.672: I/DEBUG(124):     695f4908 f1b830ff d0190f04 f8996833 eb0743e8 
04-16 22:57:48.672: I/DEBUG(124):     695f4918 f0141c03 bf140401 2004f8cc 4004f8cc 
04-16 22:57:48.672: I/DEBUG(124):     695f4928 011b6833 8003f847 eb076833 f8cc1c03 
04-16 22:57:48.682: I/DEBUG(124):     695f4938 f8cc0008 6833100c 60333301 0801f108 
04-16 22:57:48.682: I/DEBUG(124):     695f4948 0f0cf1b8 e8bdd1dd 683087f0 1a00eb07 
04-16 22:57:48.682: I/DEBUG(124):     695f4958 8004f8ca f04f4620 f7f3080c 1ec1fa49 
04-16 22:57:48.682: I/DEBUG(124):     695f4968 4001fb08 30384629 fc69f7f3 46826845 
04-16 22:57:48.682: I/DEBUG(124):     695f4978 d12b2d04 46206833 50bd011a 2d026b25 
04-16 22:57:48.682: I/DEBUG(124):     695f4988 f7f3d10a 1e45fa35 4805fb08 1038f8d8 
04-16 22:57:48.682: I/DEBUG(124):     695f4998 000ff001 e0090085 fa2af7f3 fb083801 
04-16 22:57:48.682: I/DEBUG(124): code around lr:
04-16 22:57:48.682: I/DEBUG(124):     696175bc 20004770 e92d4770 461d4ff0 6803b0b1 
04-16 22:57:48.682: I/DEBUG(124):     696175cc af03ac04 681f9700 f8dd4623 9e3b80e8 
04-16 22:57:48.682: I/DEBUG(124):     696175dc 270047b8 e02b46bb a000f8d5 458259e0 
04-16 22:57:48.682: I/DEBUG(124):     696175ec f1b8d123 d0030f01 685119e2 d11c2901 
04-16 22:57:48.682: I/DEBUG(124):     696175fc 100beb04 f7ff4629 b1b0ffb1 e0092700 
04-16 22:57:48.682: I/DEBUG(124):     6961760c 58230138 d1044553 46291820 ffc0f7ff 
04-16 22:57:48.682: I/DEBUG(124):     6961761c 3701b110 dbf3454f f04f454f bf080001 
04-16 22:57:48.682: I/DEBUG(124):     6961762c d00a7030 70312100 f10be007 37100b01 
04-16 22:57:48.682: I/DEBUG(124):     6961763c 900cf8dd dbcf45cb b0312000 8ff0e8bd 
04-16 22:57:48.682: I/DEBUG(124):     6961764c 47ffe92d 681b461e 46044690 1c9a460f 
04-16 22:57:48.682: I/DEBUG(124):     6961765c 2022f850 6850b112 d0284580 f04f3316 
04-16 22:57:48.682: I/DEBUG(124):     6961766c f10d0900 f8540a0f e00f5023 0600e88d 
04-16 22:57:48.682: I/DEBUG(124):     6961767c 46394620 4633686a ff9df7ff 4620b128 
04-16 22:57:48.682: I/DEBUG(124):     6961768c 686a4639 f7ff4643 682dff5b d1ed2d00 
04-16 22:57:48.682: I/DEBUG(124):     6961769c 20086839 f97bf72e 8004f8c0 1c8b6831 
04-16 22:57:48.682: I/DEBUG(124):     696176ac 2023f854 68316002 f8441c8b e8bd0023 
04-16 22:57:48.682: I/DEBUG(124): memory map around fault addr 5469613a:
04-16 22:57:48.682: I/DEBUG(124):     421e5000-427c3000 /dev/ashmem/dalvik-heap (deleted)
04-16 22:57:48.682: I/DEBUG(124):     427c3000-59a9f000 /dev/ashmem/dalvik-heap (deleted)
04-16 22:57:48.682: I/DEBUG(124):     59a9f000-61a9f000 /dev/ashmem/dalvik-mark-stack (deleted)
04-16 22:57:48.802: I/BootReceiver(484): Copying /data/tombstones/tombstone_07 to DropBox (SYSTEM_TOMBSTONE)
04-16 22:57:48.822: W/InputDispatcher(484): channel '42cf4068 paulscode.android.mupen64plusae/paulscode.android.mupen64plusae.MenuActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
04-16 22:57:48.822: E/InputDispatcher(484): channel '42cf4068 paulscode.android.mupen64plusae/paulscode.android.mupen64plusae.MenuActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
04-16 22:57:48.822: W/InputDispatcher(484): channel '425b1d48 paulscode.android.mupen64plusae/paulscode.android.mupen64plusae.PlayMenuActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
04-16 22:57:48.822: E/InputDispatcher(484): channel '425b1d48 paulscode.android.mupen64plusae/paulscode.android.mupen64plusae.PlayMenuActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
04-16 22:57:48.822: W/InputDispatcher(484): channel '42b25330 Toast (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
04-16 22:57:48.822: E/InputDispatcher(484): channel '42b25330 Toast (server)' ~ Channel is unrecoverably broken and will be disposed!
04-16 22:57:48.822: W/InputDispatcher(484): channel '42bee600 paulscode.android.mupen64plusae/paulscode.android.mupen64plusae.GameActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
04-16 22:57:48.822: E/InputDispatcher(484): channel '42bee600 paulscode.android.mupen64plusae/paulscode.android.mupen64plusae.GameActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
04-16 22:57:48.892: D/Zygote(126): Process 26425 terminated by signal (11)
[/code]
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 17, 2013, 09:27:28 AM
Segfault is occurring in init_combiner(.) in combiner.cpp, on line 292.  This is the first line where glCompileShader is called.  If I put a return statement right before this line, I can successfully launch the emulator (though I get a black screen of course).  If I put a return statement right after this line, I get the segfault.  Hope this helps...

Edit: When I comment out this line, the emulator successfully launches and the video appears to be fine.  Getting full 30 FPS in mario on my nexus 7.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on April 17, 2013, 10:15:07 AM
This might fix the issue Paul was having with the depth buffer, possibly.
I haven't heard back about whether it worked when when I first disabled CoreVideo_SetCaption.

Sorry, I didn't realize that commit was related to the depth buffer problem (thought it was just to address the black screen behavior).  I just built the latest commit on Metricity/glide branch, and it still has the problem.  I haven't had much free time to run diagnostics to see whether it is just not picking a config with a depth buffer or what (been busy with a couple of contracts when I'm not at work).
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 17, 2013, 10:29:53 AM
Segfault is occurring in init_combiner(.) in combiner.cpp, on line 292.  This is the first line where glCompileShader is called.  If I put a return statement right before this line, I can successfully launch the emulator (though I get a black screen of course).  If I put a return statement right after this line, I get the segfault.  Hope this helps...

Edit: When I comment out this line, the emulator successfully launches and the video appears to be fine.  Getting full 30 FPS in mario on my nexus 7.
I thought I remembered an un-merged commit from the pc version with this removed but couldn't find it when I had a quick look. That shader writing to fragdepth needs an extension in ES although it should just fail to compile it shouldn't crash.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 17, 2013, 10:43:32 AM
That shader writing to fragdepth needs an extension in ES although it should just fail to compile it shouldn't crash.
I know practically nothing about shader programs, but a quick scan of the internet suggests the same... the driver should fail gracefully -- a total crash indicates a poorly written driver.

I looked through the original mupen history of this plugin, and then to gonitz's history even farther upstream.  This chunk of code hasn't changed since the start gonitz's repository in march 2009.  More evidence to suggest a driver bug.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 17, 2013, 11:29:56 AM
I couldn't find any device that supports the extension anyway. I guess it will need to be disabled for ES although I haven't found out which games use it yet either.

I must have misremembered that there was a change removing set_depth_shader...

Yep it does sound like a driver bug.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 17, 2013, 11:35:14 AM
I printed out the shader program source code and looks like the program is getting truncated before it compiles -- in the first shader the trailing '}' gets chopped off, leading to a malformed program, which the driver then balks at (still seems like it should be a graceful failure though).  I'm going to work through the strings and concatenations and see if I can figure out the reason for the truncation.

Edit: It might be a preprocessor concatenation error, not necessarily a strcat() error...
Edit2: Definitely something weird going on in the preprocessor.  Not concatenating #defined strings properly.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 17, 2013, 03:00:45 PM
There could be a bug there but I'd be more inclined to think it is just a problem with the log method handling long strings, var-args or newlines. There a bad mix between 1024 and 4096 buffers which might be the culprit. I think each plugin defines a few log methods then there is mupens which has a few callbacks then there are the changes to use logcat instead of print it's all a bit messy really.

I think it is just the nvidia driver crashing because 'gl_FragDepth = ... ' is illegal.

I pushed a related fix that I did a while ago to check the shaders compile and link ok, ironically I didn't push it earlier as I knew the part were discussing now would output a msg for every device. It's not a fix for the tegra problems though, I would just stick with the version you did with it commented out.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 17, 2013, 03:52:23 PM
Yeah, I think you're right about the log limiting the output.  Maybe the cleanest way to deal with this is to just surround that whole block with #ifndef ANDROID .... #endif to minimize diff/conflict with upstream.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 17, 2013, 07:06:26 PM
That remote testing payed off, with it running I noticed problems beyond what I saw in the screenshots like the smeared texture coordinates, this reminded me of the same issue with rice and by using high precision for the vertex attributes it works ok.

I will try and find the appropriate offset values for different devices next, and either comment out the code causing crashes on nvidia or let littleguy do it.

The latest commit works with SDL 2 (not tested 1 yet) and as littleguy mentioned using the CoreVideo functions now works so I will revert that code back.

I do think it's kinda cool using a device based in another country to fix a bug  8)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 17, 2013, 07:45:13 PM
I'm happy to help with whatever.  Should we mirror your work over to github now?  Would be nice to have everything in one place but I can work with it either way.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on April 17, 2013, 08:55:30 PM
@Kris I gave you write access to the github repository, if you want to bring it over yourself.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 17, 2013, 09:47:11 PM
I'm happy to help with whatever.  Should we mirror your work over to github now?  Would be nice to have everything in one place but I can work with it either way.
@Kris I gave you write access to the github repository, if you want to bring it over yourself.
Done.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 17, 2013, 09:49:56 PM
Awesome, thanks Kris.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 17, 2013, 10:05:17 PM
I'll post my additions on a separate branch tonight.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 17, 2013, 11:20:33 PM
Ok, pushed.

I branched from the commit prior to Kris's merge with SDL2.  That allowed me to cherry pick the fixes and my additions and keep with SDL 1.3.  Then as a last step I made another branch that combines glide and SDL2.  Just a safety precaution to help isolate bugs better.  I didn't cherry pick the adreno polygon offset change, since it seemed more experimental (plus would regress some non-adreno devices).  We might want to make a separate branch if we want to get serious with testing offset values.

A few changes I made:
 - Polished up the makefile to match the others, and put it in the "official" mupen plugin dir structure.
 - I took a less aggressive approach to the tegra segfault bugfix, only omitting a small portion of the code, and doing it with #ifndef ANDROID rather than comments (easier to diff with upstream)
 - When I did the merge with master, I did it in the reverse direction so that the changeset was smaller and easier to read.
 - Separated some merges/changes into separate commits for clarity.

I consider these branches completely public, so do with them as you please.  I'll probably make my own "tinkering" branches off of these.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on April 24, 2013, 08:13:16 PM
Animal Forest/Dobutsu no Mori inventory screen is buggy: http://imgur.com/58ZFqJZ
I don't mind the messed up colors but the black square in the upper left corner needs to be fixed.
For some reason when you dismiss the inventory, your character (in the center of the black square) appears fine. I do not believe it is a framebuffer issue but I could be mistaken.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 26, 2013, 12:31:58 PM
Animal Forest/Dobutsu no Mori inventory screen is buggy: http://imgur.com/58ZFqJZ
I don't mind the messed up colors but the black square in the upper left corner needs to be fixed.
For some reason when you dismiss the inventory, your character (in the center of the black square) appears fine. I do not believe it is a framebuffer issue but I could be mistaken.
Those issues do seem to happen on the PC too, I've seen the incorrect colours in other plugins too so maybe some pixelformat has problems.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 26, 2013, 02:27:08 PM
Has anyone tried using this to locate bottlenecks?
http://developer.android.com/tools/help/gltracer.html

Only works for Android 4.1 and up, though there seems to be a bug with it in the latest JB version.  Any dev out there with a 4.1 device?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on April 26, 2013, 03:28:21 PM
Has anyone tried using this to locate bottlenecks?
http://developer.android.com/tools/help/gltracer.html

Only works for Android 4.1 and up, though there seems to be a bug with it in the latest JB version.  Any dev out there with a 4.1 device?
It's much more basic than the tools provided by the gpu vendors. The adreno profiler was good when I used it on WebOS although when I tried it on android it was more unstable and had gfx problems. Tools for gl in general seem to be lacking compared to the directx ones.

Large parts of the of all the gfx plugins are executed on the cpu anyway including tasks like transform and lighting which is usually done on the gpu.

Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on April 26, 2013, 03:32:50 PM
I see.  Well I expected most of the bottlenecks would be inside the GPU calculations but thought perhaps a profiling tool could shed insight into what's consuming the most time.  Then again almost all my gl experience is with old 1.x and immediate mode.  Maybe shader programs make it harder to profile....
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 09, 2013, 07:25:27 AM
So where do we stand with this?  What are the remaining things left to do before we merge this to master? I think it would be ok to merge as long as we are feature-complete, even if performance isn't yet up to where we'd like.  I think most of the remaining things relate to wiring up the configuration stuff to the front-end, e.g.
 - making stretch-screen option work
 - exposing any glide-specific options to the front-end

Anything else?  Any show-stopper bugs we still need to fix?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on May 09, 2013, 08:32:30 AM
Not really major but occasionally when loading a game, certain textures go funky. A reload fixes it. (E.g. gray moving lines instead of a stone texture)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on May 09, 2013, 11:54:30 AM
So where do we stand with this?  What are the remaining things left to do before we merge this to master? I think it would be ok to merge as long as we are feature-complete, even if performance isn't yet up to where we'd like.  I think most of the remaining things relate to wiring up the configuration stuff to the front-end, e.g.
 - making stretch-screen option work
 - exposing any glide-specific options to the front-end

Anything else?  Any show-stopper bugs we still need to fix?
I have been working on improving the triangle batching and got some good results, (3x to 4x reduction in draw calls) which gives a few more fps however there is a gfx issue I need to fix before it's ready.
I have no objections with it being made more widely available but I think there may be lots of questions about texture packs and maybe performance, also I don't know if we're finished with the depth buffer tweaks.
Most users probably don't need to change the settings so leaving them in the cfg files would be my preference.
However screen stretching would be useful to have, I tend to test on a device with 4:3 screen so that's kind of why rice has glitchy borders. Hope to make some progress over the next few days.

Not really major but occasionally when loading a game, certain textures go funky. A reload fixes it. (E.g. gray moving lines instead of a stone texture)
I've seen problems with framebuffer textures and save states (usually green and blue noise) but I don't know if you are referring to something else here.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 09, 2013, 01:23:33 PM
Yeah, if there are still a lot of rendering artifacts I would say we should nail those down before release... don't want an avalanche of bug reports.  Once we're simply squeezing out more FPS and fixing more obscure artifacts, I say we publish then.

I (or another dev) should be able tackle the config stuff since that's mostly a Java programming task and only requires an understanding of the mupen core/config API.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on May 15, 2013, 06:41:38 PM
I pushed the vertex buffer changes. Quite a bit of code changed this time I hope it didn't cause any new issues.

If anyone is able to get some rough fps numbers before and after for various devices it would be nice to see.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 15, 2013, 10:20:57 PM
I just did a quick (unscientific) check on my Xperia Play running around outside the Mario 64 castle.  Before I was getting 18-25 FPS most of the time and now I'm getting 25-30 FPS based on crude observations.  Only a tad slower than Rice (but without any of Rice's artifacts).  Definitely worth using as my new default plugin.

On my Nexus 7 in the same part of mario, FPS are pegged at 30, which I think was where it was in the earlier build.

If you have other benchmark games/levels you want me to test, just let me know and I can compare the different builds more scientifically.

Nice work!!  :)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 16, 2013, 12:56:06 PM
Anyone mind if we call this plugin "gles2glide64" to distinguish it from the upstream version gles2glide64mk2?  That would also follow the current directory name for the plugin and mirror the naming of the other video ports in the app.

Also, was thinking we should update the plugin menu text a bit, something like:
Though I'm not exactly sure about some of the version numbers... need some confirmation.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 16, 2013, 03:17:44 PM
I have the 'stretch screen' option wired up to the front-end menu.  Will post tonight after I run a few tests.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 16, 2013, 06:46:32 PM
Just posted the changes to the front-end for the glide branch.  For now I disabled the screen position option (top/middle/bottom) when glide is selected, since that feature isn't implemented for glide yet.

Are there any glide-specific options we want to expose to the user via the settings menu?  A frameskip setting would be good, to avoid audio stutter when the video lags and to keep in-game clocks running at real-world speed.  Anyone know what option that is in the Glide64mk2.ini file?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Evil King Stan on May 16, 2013, 11:50:54 PM
Could we possibly see a new build for testing? I'd love to see the  progress made on this. Especially since it seems to be the only plugin to play Majora flawlessly, as well as many other games. And if the speed increase is as good as littleguy says it is then there's no reason anyone will be able to say n64oid is better.   :D
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on May 17, 2013, 12:51:04 AM
I'll post another build tomorrow during lunch break.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: karl_87 on May 17, 2013, 04:18:27 AM
So does anyone know what big improvements the glide64 port will bring to the emulator? From what I've read it seems loads better, but I'm not 100% sure.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 17, 2013, 07:26:23 AM
I've been playing a bit more now with glide and to me the main drawback is audio stutter and in-game clock drift, both symptoms of the same issue I think (frames taking a long time to render).  This is most apparent in racing games like Diddy Kong or SW Ep 1 Racer even on my relatively quick Nexus 7.  So I might have to retract my statement about it being my new default... for now :).

I think this would be simple to address if we had a frameskip option, but after searching online it appears that Glide doesn't have that option anywhere :-\.  I'm guessing it's not a trivial feature to retrofit, even with the other plugins' source code as a reference.  Maybe I'll take a look at the core API, maybe there's something hiding in there ???.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on May 17, 2013, 08:40:14 AM
I'll have to give the stretch option a test on my phone.

I will have a look at implementing a frameskip it shouldn't be too complex, I think the other plugins use a similar approach where you just skip processing the displaylist when lagging.

There are some other areas that could be altered to help with performance too.

One thing I noticed a while back was it seemed the optimization flags were set for CFLAGS instead of CXXFLAGS which from what I've read would ignore c++ files, this may affect other modules too. There may be other possible improvements relating to the compiler as well.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 17, 2013, 09:03:51 AM
Sounds great, hope you can pull it off :)

One thing I noticed a while back was it seemed the optimization flags were set for CFLAGS instead of CXXFLAGS which from what I've read would ignore c++ files, this may affect other modules too. There may be other possible improvements relating to the compiler as well.

Yes, I recall that may have been the case initially.  The current glide makefile for Android does use CPPFLAGS (https://github.com/paulscode/mupen64plus-ae/blob/glide/jni/gles2glide64/projects/android/Android.mk#L66) as well, which are just the common optimization flags (https://github.com/paulscode/mupen64plus-ae/blob/glide/jni/Android.mk#L23) used by most of the native modules.  If you know any good optimizations to try, go for it.  Maybe stick them just in the glide makefile for now so that we don't accidentally regress one of the other modules.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 20, 2013, 10:28:30 PM
For now I disabled the screen position option (top/middle/bottom) when glide is selected, since that feature isn't implemented for glide yet.

Just a minor update on this - we're all set with the front-end stuff once we merge in the new-screensizing branch.  More info here  (http://www.paulscode.com/forum/index.php?topic=1029)if you're interested.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: snapuswip3 on May 21, 2013, 04:14:25 AM
Is it possible to add the option to enable 'frame buffer read always'? Ive tried enabling it in the .INI but it still doesn't work in the emulator
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 21, 2013, 07:14:23 AM
Just to clarify, you should still be able to manually set glide settings by modifying the file <sdcard>Android/data/paulscode.android.mupen64plusae/data/Glide64mk2.ini   (not Glide64.ini)

If modifying that file doesn't change the behavior, then I will have to do some digging to see if it's even still possible (the plugin has been adapted to different frameworks and occasionally things get lost in porting).  Can you say a bit about why you want to change this setting?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on May 21, 2013, 07:48:51 AM
Is it possible to add the option to enable 'frame buffer read always'? Ive tried enabling it in the .INI but it still doesn't work in the emulator

You need to change the setting in the [DEFAULT] section not [SETTINGS], game specific ones should also work.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: snapuswip3 on May 21, 2013, 09:40:54 AM
Frame buffer always read fixes certain graphical effects at the cost of performance. I was just interested to see if it improved the item inventory screen in animal forest, but I know that it fixes the video monitors in Mario kart and 1080
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 21, 2013, 09:52:02 AM
Thanks.  If there's a consensus that enough people would want (and know how to use) this preference, I have no problem exposing it through the front end menu.  I'd just need some suggestions for the wording.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: snapuswip3 on May 21, 2013, 10:02:21 AM
Frame Buffer - Read Every Frame: Enable to fix certain frame buffer effects (at the cost of performance).

I'm fairly sure that on the PC version it adds extra load to the GPU, if its the same on android, is the GPU even a bottleneck when running mupen64plus AE?


*edit, got it working following your advice, noticable performance hit on xperia play, I will try on my nexus 7 when I get home

**edit no I think its just glide is slower generally on xperia play (lack of frameskip)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on May 21, 2013, 11:57:08 AM
Does glide have a fog option?  That would be a good one to expose if it does.

--EDIT-- Looks like it does.  I'm a little confused about the redundancy of fog=1 under [SETTINGS] and fog=1 under [DEFAULT] though.  Does [SETTINGS] override [DEFAULT] and game-specific sections?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on May 21, 2013, 06:31:58 PM
Settings is ignored afaik. I hope the paper mario texture regression with squares gets fixed.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 21, 2013, 06:36:47 PM
@xperia - Was it a regression from an earlier glide build?  Or just never worked at all?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on May 21, 2013, 06:40:50 PM
It worked in the one with changeable bias factor values and no 24bit z-buffering. Currently using the latest From the gles2glide64 tests thread. A lot of textures have a square around them like the dust near mario's feet in this picture: (http://s20.postimg.org/umjflllct/Square_Dust.png) The battle menu and most other things are fine though.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 21, 2013, 06:43:07 PM
Thanks.  A git-bisect should isolate that quickly.  Would you mind posting a savestate where it's immediately obvious?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on May 21, 2013, 06:52:35 PM
http://db.tt/rsnio3hj
Though anywhere you walk around should show it
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on May 21, 2013, 07:44:14 PM
It worked in the one with changeable bias factor values and no 24bit z-buffering. Currently using the latest From the gles2glide64 tests thread. A lot of textures have a square around them like the dust near mario's feet in this picture:
I can confirm this problem. Originally I thought the issue was similar to how the clouds on Lakitu are squareish but in paper mario it is more serious and I understand the regression.

Edit: Pushed a fix, if you notice any other differences after you've tried it please let us know. Thanks for the info and the savestate made it much easier to identify too.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 21, 2013, 09:31:45 PM
Nice, that fixed it for me on my Nexus 7 (at least for the savestate that xperia64 provided).
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on May 23, 2013, 09:24:41 PM
I just posted an experimental branch to share some hacking I did for frameskip.  I have no plans to ever merge it... just wanted to share some of my findings... in case it helps someone who actually knows what they're doing ;D

Can anyone recommend a game that has issues with frameskip (I seem to recall a lockup in Majora's Mask...)  A savestate would be ideal if you have one.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on May 23, 2013, 11:42:20 PM
Looks the right place for the skip , course it just halves the frames drawn at the moment. To only skip when necessary the main hurdle is that different games have different target framerates, it shouldn't be too much of an issue I'll look later.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on May 25, 2013, 04:54:04 PM
The Mario party games seem to have some missing/flashing polys. Mario party 1 is missing the pipe at the start of every board and the character's torsos tend to fidapeear at random.  In mario party 2, the map entrance pipe has 1/5 missing or flashing.  In mario party 3, that annoying  dice block with hands and feet has a flashing shoe. I dont think this happens with the first public glide builds. Oh yeah,  and in paper mario the game over screen is mirrored so there is an upside down game over screen below it
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: snapuswip3 on May 25, 2013, 08:35:42 PM
The filtering is set to force biliniar at the moment in Mario 64, when it looks way better set to automatic (text is crisp whilst sky is filtered)

Also the resolution seems to be set to 800 By 600, could 640 by 480 offer better performance?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on June 25, 2013, 10:50:46 PM
Resurrecting this thread.  I just added the auto-frameskip feature to the glide plugin.  It's the same frameskip logic used by gles2n64.  It makes a HUGE difference on my devices - no audio stutter, in-game clocks are accurate, and the frameskips are hardly noticeable.  A lot of games that weren't playable before are now very playable.

It should probably be tested a bit before release.  Just to make sure I spliced everything into the right places.  Also, we should decide on a default.  Right now it's "no more than 5" (auto-frameskip enabled, max frameskip 5), which honestly seems just fine by me.  Personally, I prefer smooth audio and accurate clocks over occasional drops to 10 FPS, but maybe that's just me.  I might not be as sensitive to framerate as some people are.

For git users, this feature is on the "glide-frameskip" branch.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on June 26, 2013, 07:20:05 AM
Wow, I was expecting a less sophisticated frameskip initially.  I'll put up a test build during lunch break for testers to try out.  If it doesn't have a huge impact on compatibility like Auto Frameskip does for gles2rice, it should definitely be on by default.  From my experience with gles2n64, I would recommend "no more than 4" by default (was getting random ~.5 second freezes on some games with "no more than 5" (will have to get feedback from testers on this - maybe not relevant for gles2glide64 anyway).
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on June 26, 2013, 07:52:15 AM
Sounds great.  Interesting about the random freezes on N64, that's good to know.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on June 26, 2013, 01:04:02 PM
I posted the test build in Testers Corner.  It is really nice to be able to play Zelda OOT with the fog like it's supposed to look, and not have the skipping.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on June 26, 2013, 01:10:55 PM
I'm thinking we should have gles2glide64 set as the default video plug-in in the next update.  The switch will of course affect users with slower phones, but they can always switch to gles2n64 if they want to.  And it wouldn't affect the preference for existing users.  The much better compatibility outweighs the now relatively small speed difference, IMO.  What do you guys think?  Maybe should wait for some test results first to decide..
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on June 26, 2013, 01:26:00 PM
It would be great to have the most compatible plugin be the default, then the others are more for corner cases (e.g. gles2n64 for really slow devices running a non-problem ROM).  But yeah we should wait for some tests to come in.

Assuming this becomes the default, what I'm actually concerned about are the users who are unaware and sit quietly suffering through the old problems with the old plugins.  It's like we need an in-your-face nag screen for the existing user base that says something to the effect of "For best compatibility, we now recommend the gles2glide plugin for most users and games.  Would you like to change it now? [yes, no, stop reminding me]".  It would only show for people upgrading a previous version.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: xperia64 on July 05, 2013, 09:42:47 AM
When you have time, could you look at the garbage that appears on the inventory menu of animal forest/doubutsu no mori? This is what it should look like:
Spoiler: show
(http://86bb71d19d3bcb79effc-d9e6924a0395cb1b5b9f03b7640d26eb.r91.cf1.rackcdn.com/wp-content/uploads/2008/12/animal-crossing-inventory-screenshot.jpg)

I'll post a screenshot later of what it does on my phone.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on July 07, 2013, 04:53:53 PM
Resurrecting this thread.  I just added the auto-frameskip feature to the glide plugin.  It's the same frameskip logic used by gles2n64.  It makes a HUGE difference on my devices - no audio stutter, in-game clocks are accurate, and the frameskips are hardly noticeable.  A lot of games that weren't playable before are now very playable.

Good work on the frameskip, I'll try it out soon. I was hesitant to do it like that as the target framerate is not as simple as pal = 25, ntsc = 30 and I couldn't find whatever info file had the correct framerates. But as it's an option it's not such a problem.

Maybe the files (ticks & frameskip) could be merged and simplified as the logic isn't that complex.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on July 07, 2013, 05:31:21 PM
Yep, I was going to clean up and condense that code a bit, probably move it into the ae-bridge library since it's used by both gles2glide and gles2n64.  As for framerates, I'm pretty much ignorant; I was just following the gles2n64 example.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Paul on July 15, 2013, 07:46:14 AM
I spent some time yesterday testing Paper Mario, and noticed frameskip seems to wreak havoc with this game.  If set to "Exactly [any odd number]", all you see is the background, and doing a load-state results in a black screen.  If set to "Exactly [any even number]", then it flashes consistently between the background and foreground.  If set to any of the "No more than" values, ot is much better, but the background still randomly flashes over the foreground.  Only working setting is "Never" for this game.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on July 15, 2013, 08:47:50 AM
Great catch.  Might be time to start thinking about a version 3.0, where more preferences have an "Auto" setting that configures based on game.  Auto video plugin, Auto video settings, Auto R4300, etc...
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: snapuswip3 on July 15, 2013, 09:21:39 AM
Some games don't seem to render to the full screen (f-zero, smash brothers) they do in gles2n64 though, in rice they have garbled borders (happens on jxd s7300 and xperia play).

Loving the new update BTW, and have you considered a more media based GUI with box art etc. (Maybe after auto settings for games is implemented)
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: littleguy on July 15, 2013, 09:30:48 AM
Box art like SuperGNES would be cool, but two questions:
 - Copyright issues?
 - Source for the cover art?
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: snapuswip3 on July 15, 2013, 10:48:20 AM
Surreal 64 for the original xbox always comes with a full set of boxart, www.emuxtras.net collect game art covers video previews walkthroughs etc for adding to emus (specifically the xbox1 but with a view to other uses I think). Mupen64ae being a free program should be fine? Im not too sure about copyright
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Kris on July 15, 2013, 11:41:31 AM
Box art like SuperGNES would be cool, but two questions:
 - Copyright issues?
 - Source for the cover art?
I've thought about doing some interface work like boxart and screenshots of savestates and hope to work on these at some stage. In the port for the touchpad I allowed boxart if the user downloaded it by themselves. I linked to the boxart for daedalusx64 (http://daedalusx64.svn.sourceforge.net/viewvc/daedalusx64/data/Resources/Preview/) which was good quality and complete.
Title: Re: Glide GL ES 2.0 Port (WIP)
Post by: Mikhail on August 08, 2013, 10:51:53 AM
Going through Sainte Devote & Nouvelle Chicane on F1 World GP 2 part of the track texture blurs / stretches itself with glide, rice shows it correctly but it looks pale compared to gln64 so it doesn't colour match the rest of the track, with gln64 it has a white block on the right hand side but the colour matchup is slighly better, you'll also notice with gln64 the lane line in middle of the track doesn't have the spaces, it wrongly appears as one whole line.