Author Topic: GLideN64 Android port  (Read 136683 times)

Offline gdark100

  • Green Team
  • byte
  • *
  • Posts: 48
    • View Profile
Re: GLideN64 Android port
« Reply #195 on: May 23, 2015, 03:13:03 PM »
I've pushed commit which fixes paths for texture library. It uses the same path for hires pack texture, as Rice video. It does not have much sense until problem with boost exists. But if boost problem will be fixed, texture library should be fully functional.
Texture pack library is kinda irrelevant when you have a plugin that doesnt even display the textures in the first place.
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 #196 on: May 23, 2015, 05:01:46 PM »
I've pushed commit which fixes paths for texture library. It uses the same path for hires pack texture, as Rice video. It does not have much sense until problem with boost exists. But if boost problem will be fixed, texture library should be fully functional.
Texture pack library is kinda irrelevant when you have a plugin that doesnt even display the textures in the first place.

Come on, don't be that a$$hole, the dev team are working hard fixing things, they have real jobs and lifes, i am a rookie developer and i know  that some things needs time to debug and fix them

Offline gdark100

  • Green Team
  • byte
  • *
  • Posts: 48
    • View Profile
Re: GLideN64 Android port
« Reply #197 on: May 23, 2015, 05:20:55 PM »
I've pushed commit which fixes paths for texture library. It uses the same path for hires pack texture, as Rice video. It does not have much sense until problem with boost exists. But if boost problem will be fixed, texture library should be fully functional.
Texture pack library is kinda irrelevant when you have a plugin that doesnt even display the textures in the first place.
Come on, don't be that a$$hole, the dev team are working hard fixing things, they have real jobs and lifes, i am a rookie developer and i know  that some things needs time to debug and fix them
Im not being an asshole. Sorry if I sound like that. Totally agree with what you said, but gonetz made the development of this plugin his full time job (with Indiegogo campaign money). Also he have a very tight time to work on the plugin, like he said a few posts ago, so it would be better to fix critical problems first (like the plugin barely working on kinda a lot of GLES2 devices). Of course, is up to him to decide what is priority...
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 retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #198 on: May 23, 2015, 07:47:00 PM »
Would it be possible to infuse parts of the Android glN64 plugin into it to fix a portion of the issues and then finetune it to look correct again?

Maybe just looking at the Android glN64 plugin's source code could help Gonetz figure out a fix.
Finding out what glN64 does that is possibly missing or incorrect for proper Android GLES2 rendering in GlideN64.

If he could Frankenstein with glN64 and GLideN64,hopefully it would finally fix things.

An example is Banjo-Tooie's paths are not seen through the Jinjo Houses on glN64. (proper polygon offset value)

@gdark100: Could you tell me if the textures are ALL black on glN64 with the same games you tested with GLideN64?

If textures are at least present on your Mali device with glN64,this could help greatly.

Edit2: A better example is DK64 with glN64 which displays textures properly on DK64 in DK Isles when GLideN64 even gives ME trouble with it having all black textures in some spots,black-burnt blending between beach and grass,and even broken water coloring.

Edit3: I sincerely apologize for my laziness,I found an issue with the Banjo games related to framebuffer that I neglected to test for.

Banjo-Kazooie's puzzle minigame looks perfect while Banjo-Tooie's Jiggywiggy Challenges lack video and are just solid black instead.

@gdark100: Please,do tell us the results with glN64,if you have textures where they are black in GLideN64,then it will help Gonetz to fix the Mali issue by utilizing the Android glN64 source code.
« Last Edit: May 23, 2015, 08:54:45 PM by retroben »

Offline gdark100

  • Green Team
  • byte
  • *
  • Posts: 48
    • View Profile
Re: GLideN64 Android port
« Reply #199 on: May 23, 2015, 09:22:50 PM »
@gdark100: Could you tell me if the textures are ALL black on glN64 with the same games you tested with GLideN64?

@gdark100: Please,do tell us the results with glN64,if you have textures where they are black in GLideN64,then it will help Gonetz to fix the Mali issue by utilizing the Android glN64 source code.
On Mali400MP, textures works perfect on all plugins, except glideN64, on the tested games (on glideN64 all textures are black like show in the screenshots a few posts back). On PVR 540, textures looks OK, but it runs at less than 1 fps I think, very slow. All other plugins have acceptable speeds (at least on SM64).
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 littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #200 on: May 23, 2015, 10:19:39 PM »
@Gonetz Sorry to hear that.  But it sounds like things are at least building properly, which is very good news to me.  Since we'd rather not include boost in the project as a long-term solution, this may all resolve itself later when someone rewrites the file handling code to eliminate the boost dependency.  That's already the plan for the glide64mk2 plugin.  https://github.com/mupen64plus/mupen64plus-video-glide64mk2/issues/46

In terms of impact, the Android community would benefit the most if GLideN64 had basic GLES 2.0 support.  Two-thirds of current Android users do not have GLES 3.x support.  https://developer.android.com/about/dashboards/index.html#OpenGL.  Even with rapid adoption of new Android devices, it will be a long time before GLES 3.x is the dominant majority.  With your unique skills and perspective, you are our best chance of having a well-implemented GLES 2.0 variant of GLideN64.  Keep in mind a GLES 2.0 variant of GLideN64 would not need to be perfect to be considered successful; it would only need to be comparable to the other three plugins currently used in mupen64plus-ae.  I dream of a day when one video plugin is uniformly superior for 90% of all titles on Android.  GLideN64 could be that plugin.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #201 on: May 23, 2015, 11:28:04 PM »
@gdark100: Goody! There just may be some hope left for fixing the black textures in other GPU/s if we can see some successful imports from gles2n64 into GLideN64.

@littleguy: One nice touch is that a lot of the buffer and render effects are functional like Banjo-Kazooie's puzzle with perfectly clean visuals,Tooie's CCL bubble (puzzle video image sadly solid black),proper lens of truth rendering,sorta Yoshi's Story Jungle Puddle water,and Paper Mario's star speech.
Could be quite a few more in other games that are not in other plugins.
Another one is faster performance on a few games like Gex 3 and some instances in Super Smash Bros. when FBEmulation is disabled though.

And if we can get at least the enhancement settings like 5xBR,it would be even nicer.

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #202 on: May 24, 2015, 12:50:43 AM »
@littleguy - I doubt that my plugin can be comparable to the other plugins in terms of speed. It's too complex and run slow even on top GLES2 devices. Remove complexity and you will get gln64. There is room for optimizations, but it should work ten times faster to be usable by most of GLES2 devices. Currently there are performance problems even with PC hardware. I consider GLES2 version as remedy for devices with poor GLES3 support, as my Note 3. Note 3 runs GLES 2 version without speed or texture issues. I'll try to fix compatibility with Mali400, but performance hardly will be acceptable.
GLideN64 is new generation graphics plugin and it requires new generation GL API and hardware which supports it. AFAIK, authors of Dolphin emulator does not even consider GLES2 as possible platform for porting. GLES2 version of GLideN64 misses essential part of functionality, which makes it "advanced".
Anyway, texture library does not depend on GL level, and it is very important part of the plugin. May be I'll spend remaining week to make it boost free. Since its code now differs from GlideHQ for glide64mk2, GlideHQ fix will not automatically help here.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #203 on: May 24, 2015, 01:11:00 AM »
What do you think about my suggestion to pull a frankenstein and infuse parts of gles2n64/gln64 into GLideN64 to fix the black texture issue?

My example was DK64 from how bad DK Isles looks on GLideN64 when gles2n64/gln64 has proper textures for DK64.
However,Majora's Mask has partial black texture issues on gles2n64/gln64 that GLideN64 no longer has on Qualcomm.

Makes me wish Android's Glide64mk2 was a suitable choice for infusing parts of into GLideN64.

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #204 on: May 24, 2015, 01:58:44 AM »
GLideN64 is now too far from gles2n64/gln64 to take anything from its predecessor.
Black texture issue can be fixed without it, I just need some time for that.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #205 on: May 24, 2015, 09:33:41 AM »
@littleguy - I doubt that my plugin can be comparable to the other plugins in terms of speed. It's too complex and run slow even on top GLES2 devices. Remove complexity and you will get gln64. There is room for optimizations, but it should work ten times faster to be usable by most of GLES2 devices. Currently there are performance problems even with PC hardware. I consider GLES2 version as remedy for devices with poor GLES3 support, as my Note 3. Note 3 runs GLES 2 version without speed or texture issues. I'll try to fix compatibility with Mali400, but performance hardly will be acceptable.
GLideN64 is new generation graphics plugin and it requires new generation GL API and hardware which supports it. AFAIK, authors of Dolphin emulator does not even consider GLES2 as possible platform for porting. GLES2 version of GLideN64 misses essential part of functionality, which makes it "advanced".
Anyway, texture library does not depend on GL level, and it is very important part of the plugin. May be I'll spend remaining week to make it boost free. Since its code now differs from GlideHQ for glide64mk2, GlideHQ fix will not automatically help here.

@Gonetz I see.  Sounds like I have overestimated the innate capabilities of GLES 2.0.  In that case, maybe a more realistic hope for the GLES 2.0 variant is that players can switch to it temporarily to get past certain parts of certain games, where the other plugins fail.

I know you've mentioned some of this already, but could you summarize the fundamental differences between the three variants?  In particular I'd like to know how much is lost going from GLES 3.1 to GLES 3.0.  Unless I can resolve the binary backward-incompatibility of APP_PLATFORM 21, we will not be able to get the GLES 3.1 variant into the master branch and on Google Play.

Also, if you could list which subset of settings should be displayed for each variant, I can go ahead and update that as well.
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: GLideN64 Android port
« Reply #206 on: May 24, 2015, 10:17:44 AM »
I know you've mentioned some of this already, but could you summarize the fundamental differences between the three variants?  In particular I'd like to know how much is lost going from GLES 3.1 to GLES 3.0.  Unless I can resolve the binary backward-incompatibility of APP_PLATFORM 21, we will not be able to get the GLES 3.1 variant into the master branch and on Google Play.

Also, if you could list which subset of settings should be displayed for each variant, I can go ahead and update that as well.
It'd be a nuisance, but if it comes down to that, it's possible to post multiple APK versions on Google Play under the same listing. Alternatively, it'd probably make the APK huge, but 2 sets of libraries could be included for armeabi-v7a and x86 (I don't see armeabi getting platform 21 or having GLES 3.X :P)

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #207 on: May 24, 2015, 12:23:54 PM »
I just finished GLideNHQ no-boost edition. Everything seems to work now:
https://drive.google.com/file/d/0B0YqMPjGo3B2SExtSkFnQmgycms/view?usp=sharing

Now I need to implement text drawer. PC version uses FreeType library. I found this tutorial:
http://en.wikibooks.org/wiki/OpenGL_Programming/Installation/Android_NDK#FreeType

Is it possible to add FreeType library to mupen64plus-ae?

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #208 on: May 24, 2015, 12:40:02 PM »
@littleguy "could you summarize the fundamental differences between the three variants?"
Sure, but I need to check the code for accurate answer. It's midnight of Sunday for me now. I'll check it tomorrow.

As I remember,
GLES3.1 supports almost everything I use on desktop. There is difference in MSAA, and AA currently does not work on my Shield.
GLES3 does not support MSAA and image textures. image textures are used for N64 depth compare shader and for depth based fog in Beetle Adventure racing. Depth based fog can be rewritten with standard textures though.
GLES2 does not support : mip-mapping (very bad), noise dithering (can live without it) , Video Interface emulation (just not implemented for GLES2, possible to do). Not sure that emulation of non-rgba frame buffers works.

I'll check for valid config options set for each version.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #209 on: May 24, 2015, 01:12:20 PM »
Does the star people telepathy scene in Paper Mario use noise dithering?
I see a TV static effect preiodically when he is talking to Mario inside the toad's house at night.

I'll run a test to see if that is what it is.