Author Topic: Glide64 Bias Factor Test  (Read 17053 times)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #15 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
  • 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.
  • OR 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.
« Last Edit: April 20, 2013, 01:09:34 PM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline xperia64

  • Moderator
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: Glide64 Bias Factor Test
« Reply #16 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.

Offline Kris

  • Developer
  • int
  • *****
  • Posts: 91
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #17 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.

Offline scorpio16v

  • long
  • ***
  • Posts: 203
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #18 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

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #19 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.
« Last Edit: April 20, 2013, 01:09:52 PM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #20 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?

2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline scorpio16v

  • long
  • ***
  • Posts: 203
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #21 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.

Offline Tom.K

  • Green Team
  • long
  • *
  • Posts: 130
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #22 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
« Last Edit: April 21, 2013, 06:16:11 AM by Tom.K »

Offline Blizzard64

  • byte
  • *
  • Posts: 11
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #23 on: April 21, 2013, 07:22:39 AM »
However, "Show GL Renderer" option causes app to close.
I have got the same problem here.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #24 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)
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3496
  • Developer
    • View Profile
    • PaulsCode.Com
Re: Glide64 Bias Factor Test
« Reply #25 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.
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline Gillou68310

  • Developer
  • long
  • *****
  • Posts: 112
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #26 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

Offline Gillou68310

  • Developer
  • long
  • *****
  • Posts: 112
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #27 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 ;)

Offline scorpio16v

  • long
  • ***
  • Posts: 203
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #28 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.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Glide64 Bias Factor Test
« Reply #29 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.
« Last Edit: April 23, 2013, 07:27:59 PM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version