PaulsCode Forum

Mupen64Plus AE => General Discussion => Topic started by: Paul on April 19, 2013, 02:27:47 PM

Title: Glide64 Bias Factor Test
Post by: Paul on April 19, 2013, 02:27:47 PM
Calling all Glide64 testers!  We need to have this test run on as many different devices as possible:

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

Steps:

1) Install the above APK
2) Navigate to Settings->Plug-ins->Video, and select glide64mk2
2) Navigate to Settings->Video->Bias Factor
3) Enter a decimal value (positive or negative)
4) Launch Mario 64
5) Check for if the shadows and waterfall are missing or flickering
6) Repeat Steps 2-5 until you find a good value (no flickering)
7) Navigate to Settings->Video->Show GL Renderer
8) Post here the good Bias Factor value and the GL Renderer value (EXACTLY as it appears)

If you experience a crash, let me know so we can track down the problem.  The above test also includes the SDL2 update, so a crash could be related to it instead of Glide64 (be sure to check if using gles2n64 instead still crashes)
Title: Re: Glide64 Bias Factor Test
Post by: Kris on April 19, 2013, 03:12:31 PM
Just a bit more info:
For qualcomm 0.007 seems about right if that could be confirmed it would be good.
If the shadow is invisible or partially visible try increasing the value, if it being rendered in-front of trees or mario it needs to be decreased. You could repeatedly use a value halfway between low and high (Binary Search).

Title: Re: Glide64 Bias Factor Test
Post by: xperia64 on April 19, 2013, 03:22:53 PM
I cant install it. It says that it can't uncompress libgles2rice.so because of a size mismatch of 85 bytes short
Title: Re: Glide64 Bias Factor Test
Post by: Paul on April 19, 2013, 03:28:25 PM
Well, that's a new one  ???

I'll try building it on my PC at home when I have some time later (or you could try building it yourself if you prefer - source is at commit 04f03245a9 (https://github.com/paulscode/mupen64plus-ae/commit/04f03245a95ba14afc31cfa2047421471db46040)).
Title: Re: Glide64 Bias Factor Test
Post by: xperia64 on April 19, 2013, 04:07:16 PM
Looks like it got corrupted when I downloaded it over 3g/4g multiple times in the exact same way. I did a pm install from my computer and it appears to work
Title: Re: Glide64 Bias Factor Test
Post by: Kris on April 19, 2013, 04:19:48 PM
I tried a Galaxy S III remotely, it's not perfect hopefully someone can find a better value but "Mali-400 MP" and bias 5.0
Title: Re: Glide64 Bias Factor Test
Post by: xperia64 on April 19, 2013, 04:22:06 PM
I tried a Galaxy S III remotely, it's not perfect hopefully someone can find a better value but "Mali-400 MP" and bias 5.0
I have a Mali-400 MP on my S2 so hopefully I can find something...
Title: Re: Glide64 Bias Factor Test
Post by: xperia64 on April 19, 2013, 04:51:50 PM
S2 Mali-400 MP seems to have a bias factor of 69.5
Try values between 68 and 71 if it looks messed up in other games

Edit: 64.9 seems to be better.
Title: Re: Glide64 Bias Factor Test
Post by: Evil King Stan on April 19, 2013, 06:11:23 PM
Tested with the Xperia Play. The 0.2 bias factor seems to work right off the bat. No problem in Mario 64, although it is a bit slow. Although I expect that will get better as the plugin is developed further. Also, Glide renders most correctly in OoT. No flickering Navi or missing heart like in Rice. And the model of Link in the menu displays correctly. Plus it renders the town and field in Majora's Mask prefectly.  :) Also the stretch screen option doesn't seem to work.

Edit: Oops, I made a tiny mistake. The shadows below Mario and the trees were a bit too high. Bias factor of 0.02 fixes that, and also improves speed quite a bit.
Title: Re: Glide64 Bias Factor Test
Post by: Blizzard64 on April 20, 2013, 08:45:35 AM
I using Bias factor 0.0099 and it works good (In Mario 64 and Zelda Oot/MM). No shadow flickering.
I have a Samsung Galaxy S Plus with a Qualcomm Snapdragon 1.4 GHZ Singlecore CPU and an Andreno 205 GPU. The Setting for the Resolution in Glide would be great!  ;D
Title: Re: Glide64 Bias Factor Test
Post by: scorpio16v on April 20, 2013, 09:37:38 AM
Acer A511: GL Renderer " NVIDIA TEGRA 3 " - Bias Factor: 0.2
Nexus 4: GL Renderer " Adreno (TM) 320 " - Bias Factor: 0.007
Onda v812: GL Renderer " PowerVR SXG 544MP " - Bias Factor: ????

Can't find a good setting for PowerVR.  :(

Besides this, interestingly the hardware with the worst performance (stuttering sound and sometimes graphics) is the Nexus 4 with the most powerful hardware.  :o
Title: Re: Glide64 Bias Factor Test
Post by: xperia64 on April 20, 2013, 11:08:25 AM
Acer A511: GL Renderer " NVIDIA TEGRA 3 " - Bias Factor: 0.2
Nexus 4: GL Renderer " Adreno (TM) 320 " - Bias Factor: 0.007
Onda v812: GL Renderer " PowerVR SXG 544MP " - Bias Factor: ????

Can't find a good setting for PowerVR.  :(

Besides this, interestingly the hardware with the worst performance (stuttering sound and sometimes graphics) is the Nexus 4 with the most powerful hardware.  :o
Try 1000 or -1000 and work down from there for PowerVR.
Title: Re: Glide64 Bias Factor Test
Post by: Kris on April 20, 2013, 11:22:17 AM
Acer A511: GL Renderer " NVIDIA TEGRA 3 " - Bias Factor: 0.2
Nexus 4: GL Renderer " Adreno (TM) 320 " - Bias Factor: 0.007
Onda v812: GL Renderer " PowerVR SXG 544MP " - Bias Factor: ????

Can't find a good setting for PowerVR.  :(

Besides this, interestingly the hardware with the worst performance (stuttering sound and sometimes graphics) is the Nexus 4 with the most powerful hardware.  :o

I'm going to look at using a 24bit z buffer on PowerVR, Adreno and Mali and then use an nvida extension on tegra. That change might need different values but it should minimize these problems.


That performance problem seems fairly common, the latest bit of info was that n64oid didn't have the problems and the menu bar had some correlation. Does disabling the input plugin have any affect?
Title: Re: Glide64 Bias Factor Test
Post by: scorpio16v on April 20, 2013, 12:08:27 PM
Does disabling the input plugin have any affect?

No, I've disabled touchscreen and controller, but the sound stutters sometimes if graphic activities are increased.
That doesn't happen on the other plugins, even without frameskip.

Try 1000 or -1000 and work down from there for PowerVR.

Yes, but if I should try all values, including 3 digits after comma, that'll be a 24/7 job  :-\
The problem is, that low and high values mostly don't produce (visibly) changes. So it's nearly impossible to track down the search area to a small sector.
Title: Re: Glide64 Bias Factor Test
Post by: littleguy on April 20, 2013, 12:16:59 PM
NVIDIA Tegra 3
  Using only Mario 64 to test, I would be comfortable with anything between 0.2 and 0.8.  To be nitpicky, using 0.2, the shadow under Mario's feet is sometimes incomplete when you transition between facets of the ground.  Using 0.8 reduces that effect, at the cost of the shadow just starting to cover the soles of the feet.  I can post screenshots if you like, but my point is not to worry about nailing an *exact* value for Tegra 3 as long as it's in this range.
Title: Re: Glide64 Bias Factor Test
Post by: littleguy on April 20, 2013, 12:28:04 PM
I'm going to look at using a 24bit z buffer on PowerVR, Adreno and Mali...

That might be an all-around good idea for all the video plugins.  The obvious ways to implement this would be
Title: Re: Glide64 Bias Factor Test
Post by: xperia64 on April 20, 2013, 12:33:24 PM
Does disabling the input plugin have any affect?

No, I've disabled touchscreen and controller, but the sound stutters sometimes if graphic activities are increased.
That doesn't happen on the other plugins, even without frameskip.

Try 1000 or -1000 and work down from there for PowerVR.

Yes, but if I should try all values, including 3 digits after comma, that'll be a 24/7 job  :-\
The problem is, that low and high values mostly don't produce (visibly) changes. So it's nearly impossible to track down the search area to a small sector.
What I did was pick an extreme value and see how the shadows were affected. If I started at -1000 and the shadows were in the ground/flickering, I would then try -500, -250, etc until they stopped flickering. Decimals don't do much when the numbers are that big.
Title: Re: Glide64 Bias Factor Test
Post by: Kris on April 20, 2013, 12:51:11 PM

No, I've disabled touchscreen and controller, but the sound stutters sometimes if graphic activities are increased.
That doesn't happen on the other plugins, even without frameskip.
Glide is definitely slower as a lot of the time triangles are drawn individually when they can be grouped together that's something I'm working on. I was thinking you were experiencing the slowdowns for all plugins like the threads about sgs3 and droid dna.

NVIDIA Tegra 3
  Using only Mario 64 to test, I would be comfortable with anything between 0.2 and 0.8.  To be nitpicky, using 0.2, the shadow under Mario's feet is sometimes incomplete when you transition between facets of the ground.  Using 0.8 reduces that effect, at the cost of the shadow just starting to cover the soles of the feet.  I can post screenshots if you like, but my point is not to worry about nailing an *exact* value for Tegra 3 as long as it's in this range.
I've seen that too.

That might be an all-around good idea for all the video plugins.  The obvious ways to implement this would be
 - on the native side, call CoreVideo_SetVideoMode() with z buffer at 24 (or 32?) and if it fails, try again with 16.  This seems most natural, but it would also cause a diff with the upstream versions of plugins.
 - on the java side, in GameSurface.createGLContext() do the same thing, trying progressively lower values until it succeeds.  Doing it in java wouldn't be a performance hit since it's only called once.  The benefit would be not having to change all the plugins or creating diffs with upstream.  On the other hand, if the polygon offset values need to be a function of z buffer bits, doing this way might actually make things more complicated.
There are places in the plugin code that might need to be touched (framebuffer stuff) but I don't know why the same thing needs to be set before SetVideoMode and with egl in CoreInterface.java.

I think egl can query all available formats and one be chosen instead of requesting a specific combination. Looking through capabilities on glBenchmark site even the low-end ones of those chipsets support it.
Title: Re: Glide64 Bias Factor Test
Post by: scorpio16v on April 20, 2013, 12:56:02 PM
I'm using the carpet in the entrance hall of the castle in SM64 for my tests.
On my other devices, I can see a difference and Mario appeared over or under the carpet if I change the values. But not on PowerVR.

Shadow and carpet are always flickering like in the attached picture.
https://dl.dropboxusercontent.com/u/17774073/Screenshot_2013-04-20-19-51-01.png
Title: Re: Glide64 Bias Factor Test
Post by: littleguy on April 20, 2013, 01:08:16 PM
There are places in the plugin code that might need to be touched (framebuffer stuff) but I don't know why the same thing needs to be set before SetVideoMode and with egl in CoreInterface.java.

Sorry for the confusion -- meant to say that you can implement the 24-bit/16-bit fallback in two different ways (you only need to implement *one* of the bullet items).  Just pointing out pros and cons for doing it in one place or another.

Edit: clarified original post.
Title: Re: Glide64 Bias Factor Test
Post by: littleguy on April 20, 2013, 01:13:30 PM
Adreno 205
  Anywhere in the range 0.005 - 0.02 would be fine.  Same discussion as with my earlier post for Tegra 3.

Note that this conflicts with Evil King Stan's result for the same handset.  I thought the default 0.2 was fine too until I looked closer and saw that mario's feet were covered in shadow.  @Evil King Stan - you mind running it one more time with these values, see what you think?

Title: Re: Glide64 Bias Factor Test
Post by: scorpio16v on April 20, 2013, 01:26:06 PM
I don't know if the logcats containing any helpful output for you.
But just in case.
Title: Re: Glide64 Bias Factor Test
Post by: Tom.K on April 21, 2013, 06:06:39 AM
X10 Mini Pro with Adreno 200 GPU with Bias Factor 0.2 runs Mario 64 with no issues (except that it's too slow to render, but it works as it should) for now.

However, "Show GL Renderer" option causes app to close.

http://pastebin.com/8FbZgkSm
Title: Re: Glide64 Bias Factor Test
Post by: Blizzard64 on April 21, 2013, 07:22:39 AM
However, "Show GL Renderer" option causes app to close.
I have got the same problem here.
Title: Re: Glide64 Bias Factor Test
Post by: littleguy on April 21, 2013, 07:53:37 AM
Yeah same thing on my xplay (GB) but works fine on my nexus 7 (JB).  Forgot to mention yesterday.
Code: [Select]
E/libEGL  ( 4897): call to OpenGL ES API with no current context (logged once per thread)
Title: Re: Glide64 Bias Factor Test
Post by: Paul on April 21, 2013, 08:26:58 AM
If Show GL Renderer crashes, just post the logcat after starting a game instead (it will show the GL Renderer value there).  Problem is lack of a context while in the menu vs in the game.
Title: Re: Glide64 Bias Factor Test
Post by: Gillou68310 on April 22, 2013, 07:30:45 AM
I just noticed gles2glide was out :o Great work kris, it's definitely the best video plugin for mupenAE!

Anyway here's my results:

Galaxy S3 (4.1.1):
Renderer:Mali-400 MP
biasFactor:170.000000
Title: Re: Glide64 Bias Factor Test
Post by: Gillou68310 on April 22, 2013, 07:55:06 AM
Tested with the Xperia Play. The 0.2 bias factor seems to work right off the bat. No problem in Mario 64, although it is a bit slow. Although I expect that will get better as the plugin is developed further. Also, Glide renders most correctly in OoT. No flickering Navi or missing heart like in Rice. And the model of Link in the menu displays correctly. Plus it renders the town and field in Majora's Mask prefectly.  :) Also the stretch screen option doesn't seem to work.

Edit: Oops, I made a tiny mistake. The shadows below Mario and the trees were a bit too high. Bias factor of 0.02 fixes that, and also improves speed quite a bit.

A temporary solution for streching screen is to change "aspect=0"  to "aspect=1" in  Glide64mk2.ini ;)
Title: Re: Glide64 Bias Factor Test
Post by: scorpio16v on April 22, 2013, 09:02:03 AM
Yes, the config file bring a solution for the flickering on PowerVR.

n64_z_scale = 1 reduced the flickering to a minimum.

But I'm still searching a good value. Carpet is nearly stable, shadows too. But the Carpet and the frame at the castle's entrance are still flickering. In the castle the stars at the doors disappear  sometimes.
Title: Re: Glide64 Bias Factor Test
Post by: littleguy on April 23, 2013, 04:35:45 PM
Paul and Kris - I just posted a second testing branch on github for comparison.  It just uses the polygon offset values that gles2rice and gles2n64 use.  I'm not sure if glide's architecture for the offsets is fundamentally different, but it seemed to work fine on my Nexus 7.  If glide's z-fighting is no better/worse than the other plugins, that's one less thing holding up its release.  We could keep working on the renderer-based approach without feeling rushed.

Edit: Also looks good on my xperia play.
Title: Re: Glide64 Bias Factor Test
Post by: Mikhail on May 15, 2013, 08:40:39 AM
0.4
for PowerVR SGX 531 that stops the castle sun/star circle and the carpet outside the castle door from flickering but the tree roots / base shadow area still flickers as well as Mario's shadow.

What are the default settings for gles2n64 in N64oid? I'm assusimg it uses gles2n64 because of the fog setting.

I don't get any flickering at all in N64oid but gles2n64 and gles2rice both have the same above flickering problem in Mupen64PlusAE as glide64mk2 below 0.4 bias.

Also whilst outside gles2rice constantly renders a extra block of sky in the left hand top corner when using First primitive draw.
Title: Re: Glide64 Bias Factor Test
Post by: littleguy on May 15, 2013, 09:05:00 AM
Paul and Kris - I'm not sure how relevant this thread is now.  The head of the glide branch just uses the same offsets that the other video plugins use, and the code for selecting the offset based on device is centralized here  (https://github.com/paulscode/mupen64plus-ae/blob/glide/jni/ae-bridge/ae_imports.cpp#L262)in the ae-bridge library.  Note that the centralized function modifies both the polygon offset factor and the units, whereas the build posted here only modifies the units.  Which may explain why devices require different values than used in the other video plugins.

We should definitely continue to explore "best" settings per device, and more general ways for detecting the device (e.g. using the GL renderer string).  But we should probably build a new test, either off the head of master or the glide branch.  Optimal offset values could then be tested using any of the video plugins.
Title: Re: Glide64 Bias Factor Test
Post by: Kris on May 15, 2013, 11:20:55 AM
Those were the first values I tried and they didn't work for me. When they work for you is that with any of the other changes ie 24bit zbuffer?

The vertex buffer improvements I've mentioned should be committed in a few hours so I think we can sort out a release, if people have flickering we know what values to use now anyway.
Title: Re: Glide64 Bias Factor Test
Post by: littleguy on May 15, 2013, 11:46:37 AM
No, sticking with the original 16-bit z-buffer that we've always used in master.

If you haven't done so already, would you mind pulling the head of the github glide branch and testing it again on your device?  The changes I made to the polygon offset stuff can be seen in this commit:
https://github.com/paulscode/mupen64plus-ae/commit/fff883b2d9c114ac266a01ee6a12cffe6d79c851

Take a look at the call to glPolygonOffset at the bottom of that page.  The test version posted here varies only the second input argument based on device (first arg is always 0), while the head of the branch varies both arguments based on device (like the other video plugins do).  On my two devices, the shadow flicker behavior is identical across all three video plugins in the latest build.
Title: Re: Glide64 Bias Factor Test
Post by: Kris on May 15, 2013, 03:42:00 PM
Doing it that way should work ok. I didn't do that as it pc version has code to find a single value and thought it might cause problems in other games.

The vertex buffer changes are working well in mario with a speedup but it looks like I need to do a bit more debugging with other titles.
Title: Re: Glide64 Bias Factor Test
Post by: Paul on May 17, 2013, 01:33:29 PM
Topic Closed  (Thanks to everyone who helped with the testing!)
Title: Re: Glide64 Bias Factor Test
Post by: Paul on May 24, 2013, 11:53:52 AM
What are the default settings for gles2n64 in N64oid? I'm assusimg it uses gles2n64 because of the fog setting.

I don't get any flickering at all in N64oid but gles2n64 and gles2rice both have the same above flickering problem in Mupen64PlusAE

Just noticed that I missed this earlier, so thought I would respond (even though the topic is closed) just for anyone else who stumbles onto the thread wondering the same thing.

N64oid uses a GLES2 port of Rice that Yongzh developed (not related Kris' gles2rice port).  He is using some other system for profiling devices, that seems to be more robust.  Our profiler has a granularity that is much finer (specific down to the device and even in some cases the Android version).  This means we have to get feedback from a tester for basically every device out there for them to have the correct polygon offset.  Since N64oid is closed-source, we can't copy what Yongzh is doing.