Author Topic: GLideN64 Android port  (Read 141016 times)

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #135 on: May 16, 2015, 10:37:35 PM »
Yet you get pretty different and worse results than I do.
But why is it so freakishly different?

If I go in 1st person on Banjo-Kazooie,there's actually tiny bits of textures on walls,but things like eyes in
Banjo-Kazooie and DK64 are solid white.
I forgot to mention that DK64 sometimes went black on areas during the intro sequence.

Let's just hope Gonetz can sort this out soon so we can get into further testing for graphical effects.
Having something that runs is the best thing to ever happen for him so he can more easily debug the problems and test changes quickly.

After all of this,it should hopefully outperform glN64 and Rice while looking better than Glide64.
(mainly no missing polygons)
So far,I didn't see any missing polygons on the honey farms in Banjo-Kazooie,so that's a good sign.
Just wished Smash Bros. went in-game even though textures are completely disjointed and the intro is broken.

I guess even in its fractured state,GLideN64 ES2 already runs pretty darn fast,especially with FBEmulation disabled.

...Why has no one ever devised an ingenius method of automatic effects usage?
To explain,turning on an intense effect at a precise time for the game and disabling it when it is no longer needed.
Even if the visual effect appearances are delayed,it could still be useful for preventing real unfriendly game behaviour when effect rendering is always disabled.
An example such as looking at an object with cool visual effects,not looking at it turns the effect renderer off while looking at it again briefly shows it missing the effect until it automatically turns back on.
This would probably require too much processing though,way more than its worth.
Just an idea,please don't get mad at me for it.

Sorry about the wall of text,my biggest habit sometimes.

Edit: The Super Smash Bros. intro is actually not broken,I thought it was because of the black square.

Performance is low but the framerate smoothness is pure buttery smooth compared to other plugins.
Just look at the frame-by-frame perfection on the intro!
« Last Edit: May 17, 2015, 12:20:39 AM by retroben »

Offline gdark100

  • Green Team
  • byte
  • *
  • Posts: 48
    • View Profile
Re: GLideN64 Android port
« Reply #136 on: May 17, 2015, 12:38:52 PM »
I tried to record a video showing some games, but it didnt ended very well, cause I recorded with one hand and played with the other... but well, here it is: https://youtu.be/rGE_endTjcI
Motorola Xoom 2 ME:
OMAP CPU Dual Core @ 1.2 Ghz and PowerVR SGX 540 GPU
8.2'' 1280x800 Screen
1GB Ram Dual Channel
32 GB internal storage

Galaxy SII Lite:
NovaThor U8500 CPU Dual Core @ 1.0 Ghz and Mali-400MP GPU
4.0'' 800x480 Screen
768MB Ram
8GB internal storage

Huawei U8150:
Qualcomm CPU @ 532 Mhz, no GPU
3'' 240x320 Screen
256 MB Ram

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #137 on: May 18, 2015, 03:43:39 AM »
Tested it here, heavy graphical glitches and poor speed, but it is probably expected since youre rewriting lots of code...

Here are  some screenshots:
First this appeared:

then:

This is Super Mario 64. Only a few polygons actually appears on the screen, the rest is black.
I will test other games and let you know how they perform.

Also, good luck with your indiegogo campaign  ;D

I got that image on PowerVR SGX device. Fragment shaders won't compile. No diagnostics, just "Compile failed".

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #138 on: May 18, 2015, 07:50:30 AM »
@Gonetz
I have seen this sort of device-dependent variation before with shaders.  One solution that has worked on several occasions is to make sure that all shader code explicitly specifies lowp/mediump/highp on the appropriate variable declarations.

http://www.paulscode.com/forum/index.php?topic=188.msg5220#msg5220
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #139 on: May 18, 2015, 10:04:08 AM »
I know that all variable must have precision qualifier.

The problem is with device driver. This code works:
Code: [Select]

  fragColor = vec4(mix(fragColor.rgb, uFogColor.rgb, vFogFragCoord), fragColor.a);
  gl_FragColor = fragColor;
This code does not work:
Code: [Select]
 
  if (uFogUsage == 257)
    fragColor = vec4(mix(fragColor.rgb, uFogColor.rgb, vFogFragCoord), fragColor.a);
  gl_FragColor = fragColor;

I can't find a workaround. I tried to calculate mix() before "if ()" an store the result in a local variable:
Code: [Select]
 
  lowp vec3 fogged = mix(fragColor.rgb, uFogColor.rgb, vFogFragCoord);
  if (uFogUsage == 257)
    fragColor.rgb = fogged;
  gl_FragColor = fragColor;
It works without "if ()". With  "if ()" alwais "Compile failed".

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #140 on: May 18, 2015, 12:12:23 PM »
Just tried to run GLideN64 on Samsung Galaxy 2. Not sure which GPU it uses. No errors in logs. Textures do not load at all.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #141 on: May 18, 2015, 01:26:40 PM »
There is an Android version of CPU-Z on Google Play that tells you what CPU and GPU you have along with some other information.

https://play.google.com/store/apps/details?id=com.cpuid.cpu_z

I hope it works on that device for showing you the information.

Edit: There is a slight chance you will see the wrong battery strength or other sensors reading off,but maybe you will see the right information you need.

If you don't want to use that one,there are others to try,but some have fullscreen ads.
« Last Edit: May 18, 2015, 01:32:44 PM by retroben »

Offline gdark100

  • Green Team
  • byte
  • *
  • Posts: 48
    • View Profile
Re: GLideN64 Android port
« Reply #142 on: May 18, 2015, 01:52:27 PM »
Just tried to run GLideN64 on Samsung Galaxy 2. Not sure which GPU it uses. No errors in logs. Textures do not load at all.
Cant you port the functions that deal with textures from gln64 for GLES2 to your plugin until you "fix" the problem? So Ill know what is wrong and will have a possible solution.
Motorola Xoom 2 ME:
OMAP CPU Dual Core @ 1.2 Ghz and PowerVR SGX 540 GPU
8.2'' 1280x800 Screen
1GB Ram Dual Channel
32 GB internal storage

Galaxy SII Lite:
NovaThor U8500 CPU Dual Core @ 1.0 Ghz and Mali-400MP GPU
4.0'' 800x480 Screen
768MB Ram
8GB internal storage

Huawei U8150:
Qualcomm CPU @ 532 Mhz, no GPU
3'' 240x320 Screen
256 MB Ram

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #143 on: May 18, 2015, 01:56:05 PM »
Cant you port the functions that deal with textures from gln64 for GLES2 to your plugin until you "fix" the problem? So Ill know what is wrong and will have a possible solution.

I don't know what to "port". Driver reports no errors.

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #144 on: May 18, 2015, 02:00:51 PM »
Here the PowerVR SGX 540 compatible build:
https://drive.google.com/file/d/0B0YqMPjGo3B2YUZ5dzk3RmdHWHc/view?usp=sharing

I had to disable fog blend modes to make shader program compiled for this GPU.
Works very slow with and without FB emulation.

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #145 on: May 18, 2015, 02:32:57 PM »
I've tested GLES2 build on my Note3. Works much better than GLES3 version.  No speed or graphics issues.

So, current result for GLES2:
Shield (Tegra) - OK
Note 2 (Mali400MP) - OK
Note 3 (Adreno 330)- OK
Nook HD+ (PowerVR SGX 544) - Graphics OK, slow
Galaxy 2 (Mali400MP) - no textures, speed ok.

Since Note 2 and Galaxy 2 use the same GPU (as reported by cpu-z), I think the problem is in drivers version.

Offline gdark100

  • Green Team
  • byte
  • *
  • Posts: 48
    • View Profile
Re: GLideN64 Android port
« Reply #146 on: May 18, 2015, 04:01:25 PM »
Here the PowerVR SGX 540 compatible build:
https://drive.google.com/file/d/0B0YqMPjGo3B2YUZ5dzk3RmdHWHc/view?usp=sharing

I had to disable fog blend modes to make shader program compiled for this GPU.
Works very slow with and without FB emulation.
No changes on Mali400 MP device, and it is now working on PVR SGX 540 at slideshow speed. Recorded a video because whynot: https://youtu.be/NSpWc1PzuMM (swtiched to gln64 at middle-to-end for speed comparasion)
Didnt see any major graphical issue on SGX 540 tho.
« Last Edit: May 18, 2015, 04:03:16 PM by gdark100 »
Motorola Xoom 2 ME:
OMAP CPU Dual Core @ 1.2 Ghz and PowerVR SGX 540 GPU
8.2'' 1280x800 Screen
1GB Ram Dual Channel
32 GB internal storage

Galaxy SII Lite:
NovaThor U8500 CPU Dual Core @ 1.0 Ghz and Mali-400MP GPU
4.0'' 800x480 Screen
768MB Ram
8GB internal storage

Huawei U8150:
Qualcomm CPU @ 532 Mhz, no GPU
3'' 240x320 Screen
256 MB Ram

Offline IDSG

  • byte
  • *
  • Posts: 11
    • View Profile
Re: GLideN64 Android port
« Reply #147 on: May 18, 2015, 07:43:32 PM »
Tested the GlideN64 plugin on my Ainol Aurora 2 (Mali400MP2 GPU) and doesnt show anything and is really slow, can be a driver Issue like you said (Mali drivers are a pain in the a$$ as far i know), PPSSPP team worked very hard to make it work correctly, i can help you test the plugin on this kind of gpu, keep up the good work

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #148 on: May 18, 2015, 11:32:57 PM »
Here the PowerVR SGX 540 compatible build:
https://drive.google.com/file/d/0B0YqMPjGo3B2YUZ5dzk3RmdHWHc/view?usp=sharing

I had to disable fog blend modes to make shader program compiled for this GPU.
Works very slow with and without FB emulation.

I just grabbed this and tested it on my FireTV just cuz,and the textures are fully intact!!!
The framebuffer is a hit and a miss with see-through spots and square shadow on Banjo-Tooie
The speed is a little slow instead of slideshow speeds since I get 15-20fps out of 20 on Tooie.

Edit: I had it switched back to the pre-made experimental profile,so FBEmulation is enabled and no crashing!
Another thing,it boots with some tiedye stripes instead of a blank screen before the game starts.
The CloudCuckooLand bubble actually works already with Banjo appearing within when using a Clockwork egg to walk in the right spot.
I'm going to keep testing things. ;D

Strange how my issue is mostly fixed when that was for PowerVR.

Edit2: DK64 has toasted edges between beach and grass,and the textures go black when in some spots.

Yoshi's Story still grey screen exits :(,but the Nintendo logo looks perfect.
Conker,Zelda Ocarina,and Super Smash Bros. grey screen exit in the same spots.
Conker has a regression for me with a black screen instead of the text appearing.
Zelda has textures but a bad spot in the skybox while Super Smash Bros. has a few stretchy textures with most of them looking okay.

Some frame buffer effects are missing or glitched and some others seem fully intact.

Super Mario 64 looks nearly perfect so far aside from shadows and some objects being visible through walls.
Has an issue with the top left corner screen skybox looking wrong and the Mario head fade-out was squished before fixing itself.

Paper Mario looks great aside from black spots when making a save file.
It does exit during the title intro when Bowser is about to steal the Star Rod,but it can be skipped,and again when the battle is supposed to start after everyone become the wrong size. Mario and Peach shrink into high spots during the dark scene.
Bowser is stretched creepily at nightmare fuel proportions when arriving.
The white speech bubble is missing a chink on the left.

I think this is a general issue of things on the top left of the screen not rendering properly in several games.
« Last Edit: May 19, 2015, 12:45:49 AM by retroben »

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #149 on: May 19, 2015, 07:10:11 AM »
@littleguy - since GLideN64 capabilities greatly depend on GLES level, I suggest to include three version of the plugin:
GLES2, GLES3 and GLES3.1

GLES3.1 version is almost fully corresponds to PC version. MSAA does not work yet, but GLES3.1 supports it, so I think it can be fixed.

GLES3 version lacks of image texture support, so it does not support N64 depth compare and depth based fog in Beetle Adventure Racing. Everything else is supported.

GLES2 version lacks of everything. Frame buffer emulation is limited, mip-mapping is not supported.

Because of it, each version should have different set of options. for example, N64 depth compare is useless for all versions but GLES31

All GLES versions have different set of API finctions defined in headers. Thus, it is impossible to build one plugin and switch between GLES versions in runtime.

Currently my shaders related code is all perforated by <#ifdef #endif> Frame buffer emulation code also suffered from GL API incompatibility. I want to split common GL code into set of files by API level. I did such trick for Mupen64Plus/Zilmar code. Project file defines which source files to include.

In your project you will have three folders for GLideN64 instead of the current one:
mupen64plus-video-gliden64-gles20
mupen64plus-video-gliden64-gles30
mupen64plus-video-gliden64-gles31

Each version will have different project settings in Android.mk

What do you think?