Author Topic: GLideN64 Android port  (Read 121950 times)

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #225 on: May 25, 2015, 11:21:03 PM »
I always got farther spread rainbow stripes with GLES2 on boot with games running fine afterward.
The pixels,I got with DetectCFB enabled,and that was the option that makes DK64's initial Nintendo logo appear where he says "OKAY" on boot.

I have yet to run the ES3.0 version as my x86 tablet immediately destroys GL Context after creating it. :(

@gdark100: Are they size changing textures like mine does?

Offline Mikhail

  • long
  • ***
  • Posts: 127
    • View Profile
Re: GLideN64 Android port
« Reply #226 on: May 26, 2015, 12:40:40 AM »
Only fcube and Mupen64Plus Demo homebrew are working for me on gles3.0
all games i've tried with it just show wireframes and no textures, the above mentioned demo also
shows the game window in a panel on the right hand side of screen instead of spread accross the whole screen,
like the height and width got inverted.

Gles2.0 is working faster and much better though than the regular glide64,
F1 World Grand Prix I & II both show the in-game osd properly now like RetroArch and it no
longer shows junk outside the game window :-) it does however have a  broken texture on the steering / cockpit
view though which doesn't happen with any of the over plugins.

Nexus 7 2013 - Kitkat  v4.4.4, v66 Adreno320 development driver.
« Last Edit: May 26, 2015, 12:44:00 AM by Mikhail »

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #227 on: May 26, 2015, 03:54:26 AM »
@littleguy - I see my mistake, thanks.
Basically, I may use current gliden64-integration branch. Just use updated makefile and updated plugin sources. I've got GLES2 build linked with texture library. Texture enhancement works, but hires textures work only on Shield. Debugging...

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #228 on: May 26, 2015, 04:50:21 AM »
Thanks Mikhail!
Now I know that there's hope if FireTV gets that CM12 mod with updated drivers to at least v66 baked in. ;D

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #229 on: May 26, 2015, 07:13:58 AM »
I found why hires textures do not work on my phone.
The plugin and the texture library use wchar_t strings for paths.
That is all kind of wcs function used: wcscat wcslen wcsncpy and so on.
On my Note 2 the code
Code: [Select]
wcscat(textureFilter.txPath, L"/hires_texture");
results
Code: [Select]
/storage/sdcard0/mupen64plusae-v3-alpha/CoreConfig/UserData/mupen64plus//that is only first character copied. I know that wchar_t was unsupported until Android 2.3, but I run it on 4.1

Is there any way to fix it? May be some compiler flag is missing?

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #230 on: May 26, 2015, 10:11:16 AM »
I tried to build the project with CrystaX NDK.
I had to remove mupen64plus-video-glide64mk2 from makefile since it won't compile with CrystaX.
I removed -fsingle-precision-constant from makefile because any file which #include <algorithm> won't compile with it.

After that project compiled. When I run it on Note 2 it hangs on rom start with any graphics plugin.
It runs on Note 3, but promised wide string support does not work properly. mbstowcs copies only first character to destination string, thus all paths work incorrect. I've run out of ideas.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #231 on: May 26, 2015, 11:11:55 AM »
I have a lot on my plate today but I promise to help as soon as I can.

Gilles' suggestion about copying the GLES 3.1 headers into the project may be the least intrusive way to deal with the APP_PLATFORM issue.  That would eliminate the need to use CrystaX-NDK for GLES 3.1 support.  It sounds like CrystaX-NDK may be a dead end for the wchar as well.  Which is fine since I'd rather not have to resort to third-party build tools.

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

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 558
    • View Profile
Re: GLideN64 Android port
« Reply #232 on: May 26, 2015, 12:20:37 PM »
I have been following this discussion. What about using Multiple APK support so that there are different APKs built with different OpenGLES/SDK versions? With multiple APK support, the user will download a different APK depending on the platform they are running in, yet there will still be only one play store listing. See here:

https://developer.android.com/google/play/publishing/multiple-apks.html
« Last Edit: May 26, 2015, 12:23:30 PM by fzurita »

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #233 on: May 26, 2015, 12:53:17 PM »
I've pushed no-boost GLideNHQ to master.
You may pull update to gliden64-integration branch, use attached makefile and get plugin with texture enhancement support. It's better than nothing. BTW, texture filters and texture enhancements settings are very inconvenient atm. They are just numbers. There should be kind of combobox with list of available options, as on desktop version.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #234 on: May 26, 2015, 01:26:42 PM »
Thanks!  I hope to get all this into master in the next day or two.

Regarding the combo-boxes, absolutely.  I provided a minimally functional front-end but my plan has always been to replace with combo-boxes and the like once the integration stabilized (didn't want to waste precious time on something that might change).
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: GLideN64 Android port
« Reply #235 on: May 26, 2015, 01:29:50 PM »
I have been following this discussion. What about using Multiple APK support so that there are different APKs built with different OpenGLES/SDK versions? With multiple APK support, the user will download a different APK depending on the platform they are running in, yet there will still be only one play store listing. See here:

https://developer.android.com/google/play/publishing/multiple-apks.html

Yes I know.  That works fine for publishing, though it requires more complicated build scripts.  We want something that's easy for devs to build and debug straight out-of-the-box.  Having multiple build trees would add a lot of nuisance to new contributors.
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: GLideN64 Android port
« Reply #236 on: May 26, 2015, 10:57:18 PM »
Slow progress tonight.  Good news is that Gilles' method of copying the GLES 3.1 headers into the project works to maintain binary compatibility with older devices.  But restructuring the makefiles (commit 498a1) was giving me some strange build issues so I temporarily reverted it.  I should have more progress to report tomorrow.  For now a work in progress branch with a cleaner history:
https://github.com/littleguy77/mupen64plus-ae/commits/gliden64-integration

All GLES variants working, GLideNHQ working (I assume), no boost dependency, installs on older devices, runs GLES 2.0 variant on older devices, all in one APK.
« Last Edit: May 26, 2015, 11:08:38 PM by littleguy »
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 #237 on: May 27, 2015, 12:56:51 PM »
I tricked wchar_t support on Android. Here the screen from my Note2:
https://drive.google.com/file/d/0B0YqMPjGo3B2c2RLMjh3QTdzcUU/view?usp=sharing

It was a hard battle. The only 2 widestring functions which works on my devices (except Shield of course) are
mbstowcs and wcstombs, that is convert from char* to whar_t* and vice versa.
Also std::wstring(const whar_t*) works and std::wstring::c_str() works too.
Any manipulations (concatenation, search etc) with wide strings do not work. I wrote wrappers for all used functionality, which converts whar_t* string to char* with wcstombs, and then uses std::string and other functions for char*. Result copied back to  whar_t* with mbstowcs. I tested it on desktop, but on Android my code still crashed.

I found that if you have function foo(const wchar_t * wstr) and call it as foo(L"Hello!"), wstr will get only the first character of your "Hello!" string, that is wstr==L"H". You just can't use wide string constants on Android. You must allocate wchar_t buffer and copy you string to it:
Code: [Select]
wchar_t buffer[128];
mbstowcs(buffer, "Hello", 128);
Needless to say that GLideNHQ uses lots of wide string constants. I had to replace all L"" occurrences with special macro, which does necessary work. Lots of tedious work. The same is for L"" in GLideN64.

After that the paths started to work and textures started to load. I tested it on all GLES2 devices I have on hands. Result is 50/50:
Galaxy 2 (Mali400) - crash
Galaxy Note 2 (Mali400) - ok
Galaxy Note3 (Adreno) - crash
Nook HD+ (PowerVR) - ok
My corrected code works ok on all devices, plugin finds texture pack and starts to load textures. However, on some devices some textures won't load with "error load png file".

Here the test apk:
https://drive.google.com/file/d/0B0YqMPjGo3B2WnpKVUJoc3hHV1U/view?usp=sharing

Path for hires packs:
mupen64plusae-v3-alpha/CoreConfig/UserData/mupen64plus/hires_texture/
That is for SUPER MARIO 64 it will be
mupen64plusae-v3-alpha/CoreConfig/UserData/mupen64plus/hires_texture/SUPER MARIO 64

 

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #238 on: May 27, 2015, 02:02:21 PM »
I tried the enhancement instead,and it works beautifully. ;D
Which enhancement number is 5xBRZ?
I used Super Mario 64 with filter 1 and enhancement 12 with seemingly no impact on performance with FBEmulation disabled.

Then I tried Banjo-Tooie with FBEmulation on with the same enhancement and textures were super crisp and sharp.
Still seemingly no additional performance impact.

No more black screen on Tooie at least,but square dynamic shadows normally and another issue when enhancements are on.
All of the text is oversized from the multiplied enhancement strength.
The text "Isle O' Hags" and "Jinjo Village" are garbled in a weird size as a result.
Another oddity,I am getting an app crash exit every time I end the game after the auto save notification.

Edit: Conker still completely black screen with FBEmulation enabled.

Edit2: Super Smash Bros. also has the same text issue with enhancement,even affecting damage percent.
No performance impact on four DKs in Hyrule!

Banjo-Tooie actually runs quite decently aside from the broken dynamic shadow.
Edit3: JiggyWiggy's Challenge puzzle is still solid black. :(

Do you happen to have FB Read Always enabled within FBEmulation?
I believe you have it implemented and it is the reason behind the stronger slowdown when FBEmulation is enabled.
Why else would it be so liquid smooth?
« Last Edit: May 27, 2015, 02:49:59 PM by retroben »

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #239 on: May 27, 2015, 03:12:06 PM »
I tricked wchar_t support on Android. Here the screen from my Note2:
https://drive.google.com/file/d/0B0YqMPjGo3B2c2RLMjh3QTdzcUU/view?usp=sharing

It was a hard battle. The only 2 widestring functions which works on my devices (except Shield of course) are
mbstowcs and wcstombs, that is convert from char* to whar_t* and vice versa.
Also std::wstring(const whar_t*) works and std::wstring::c_str() works too.
Any manipulations (concatenation, search etc) with wide strings do not work. I wrote wrappers for all used functionality, which converts whar_t* string to char* with wcstombs, and then uses std::string and other functions for char*. Result copied back to  whar_t* with mbstowcs. I tested it on desktop, but on Android my code still crashed.

I found that if you have function foo(const wchar_t * wstr) and call it as foo(L"Hello!"), wstr will get only the first character of your "Hello!" string, that is wstr==L"H". You just can't use wide string constants on Android. You must allocate wchar_t buffer and copy you string to it:
Code: [Select]
wchar_t buffer[128];
mbstowcs(buffer, "Hello", 128);
Needless to say that GLideNHQ uses lots of wide string constants. I had to replace all L"" occurrences with special macro, which does necessary work. Lots of tedious work. The same is for L"" in GLideN64.

After that the paths started to work and textures started to load. I tested it on all GLES2 devices I have on hands.

Thanks for the hard-earned knowledge!  That is really useful and may allow us to remove the boost dependency from glide64mk2.

I am curious though, why is all the wide character support necessary?  It is not used anywhere else in the mupen64plus code, I don't think even in Rice HQ.  Are there a lot of texture packs with non-ascii characters in the filenames?
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version