Glide GL ES 2.0 Port (WIP)

[xperia64]

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

[scorpio16v]

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. 

[Kris]

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.

[Paul]

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)

[littleguy]

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.

[Kris]

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.

[littleguy]

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.

[Kris]

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:

• Garbage around borders/ garbage when launching a game.
• Z-Fighting as discussed above.
• Texture filtering and seams.
• Only works with older version of emulator.
• Performance. This may take longer to improve but planned changes to triangle batching should be available soon and optimization flags can be adjusted.

In an older release there may have been some things the wrong colour (e.g, Perfect Dark Logo).

Anyone have any reports so far?

[xperia64]

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.

[scorpio16v]

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.

[Paul]

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.

[Paul]

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:



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:



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



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.

[Paul]

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?

[Kris]

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.

[littleguy]

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