Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - littleguy

Pages: 1 2 [3] 4 5 ... 50
General Discussion / Re: GLideN64 Android port
« on: May 28, 2015, 07:08:45 AM »
I know nothing about libpng. I just know that compiler warns about this code as deprecated.
However, it works on desktop and on some Android devices. May be other devices use obsolete libpng, which can't read the file? Is it possible to use our own build of lib png based of fresh sources?

libpng is not part of the Android platform.  We are already compiling it directly into mupen64plus-ae, and it is part of the repository.  Though I'm sure it hasn't been updated in a very long time.  I don't even know what version we've been using.

I am totally swamped the rest of the week but hope to have time this weekend to sort out the png/freetype issues.  If you want to let me know which config options to disable for GLES2.0 and GLES 3.0, I can update the front-end as well to make it more user friendly (hide options and use drop-downs or sliders instead of text).

Support / Re: Last 2 builds not working on shield tablet
« on: May 27, 2015, 05:48:34 PM »
Which versions are you referring to.  Hard to diagnose a problem without that info.

General Discussion / Re: GLideN64 Android port
« on: May 27, 2015, 03:12:06 PM »
I tricked wchar_t support on Android. Here the screen from my Note2:

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?

General Discussion / Re: GLideN64 Android port
« 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:

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.

General Discussion / Re: GLideN64 Android port
« 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:

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.

General Discussion / Re: GLideN64 Android port
« 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).

General Discussion / Re: GLideN64 Android port
« 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.

General Discussion / Re: GLideN64 Android port
« on: May 25, 2015, 08:49:25 PM »
I've fixed texture problems with Mali400. Tested on Galaxy 2 and Galaxy Note 2. Changes pushed to master.
Link to apk with the fix and hack for PowerVR GPU:

I finally got around to testing on my Tegra3-based 2012 Nexus 7.  Unfortunately I only get random pixels when running GLES 2.0 variant (all that my device supports).  This occurs for both the head revision of GLideN64 on GitHub, and the APK you posted here.  Sorry I didn't test this sooner, been focused on other things.


General Discussion / Re: GLideN64 Android port
« on: May 25, 2015, 03:59:04 PM »
We are using the upstream modules as-is.  There is no porting or modification here.  Any performance gains made upstream will be immediately available in mupen64plus-ae.  At this point, mupen64plus-ae is simply a user-friendly front-end and a bit of glue code.  Once the emulator starts running, it's almost entirely upstream code that's running.  The only downstream code involved during emulation is the input handling, and that is not a performance bottleneck.

General Discussion / Re: GLideN64 Android port
« on: May 25, 2015, 02:10:27 PM »
I really think it is about time to dig deeper in Mupen64Plus AE to increase performance on the core and RSP level and also get features like overclocking and VI Refresh Rate.

This is not really the best place to make such a request.  We are using the standard upstream core.  Any performance gains are better addressed by upstream devs.  Gillou is the only person who frequents this forum who might be able to help, and he also reads the upstream discussions.  Keep in mind Gillou has been a part of this project almost as long as I have.  All the easy stuff has already been done.  It's not a simple matter of time or willpower.  Again, your hopes and dreams are most likely to be resolved if you become more active in the upstream discussions.

General Discussion / Re: GLideN64 Android port
« on: May 25, 2015, 02:06:05 PM »
I actually ran into another issue, again with the Android version stuff.  We can keep the manifest minSDK value at 7, allowing it to be installed on older devices.  The front-end runs fine on Gingerbread with the GLideN64 plugin.  The issue is that GLES 3.1 requires the entire native codebase to be compiled against the SDK 21 platform binaries.  This means that some (but not necessarily all) older devices will not be binary-compatible with the native code, and will crash as soon as the emulator is loaded.  It all depends on how the platform binaries differ between 7 and 21, and how many of those differences we are using in native code.  But I have at least one data point (Xperia Play, Gingerbread) that crashes when built with APP_PLATFORM=21.

I'm going to have to do some experimentation to see if a solution can be found.  This may postpone merging to the master branch.  Though at the very least I should still be able to get all three GLES variants working in a branch, with the GLES-specific config tweaks you requested a few posts back.

I'd like to provide apk with texture library support, but unfortunately the build from gliden64-glidenhq branch works only on my Shield device. On any other device it crashes on any rom even with default settings and default graphics plugin.
@littleguy, please check, does it work on your devices?

Yes, I have the same problem when setting APP_PLATFORM to android-21, which is necessary for GLES 3.1.  If you build against android-18 (giving you GLES 3.0), you won't have any crashing (binary incompatibilities) on really old devices.  Of course then you lose the GLES 3.1 variant.  If you look at my branches, you can see the changes in to permit the GLES 3.0 variant, and then the changes to permit the GLES 3.1 variant.

I have researched the problem and it is a known issue in various android communities (e.g.  Much of the standard library has been redefined in the android-21 binaries (substituting macros or inlines or some such thing).  I have no idea what google was thinking (as usual).  I know at least one way to solve it: GLideN64 GLES 3.1 variant can be built against android-21 and the remainder of the native code can be built against android-18.  This is not as simple as setting a flag, however, and actually requires restructuring a lot of directories in mupen64plus-ae.  I will try to get something working, hopefully tonight if I can get some free time.

Apparently CrystaX-NDK will also solve the problem and is a drop-in replacement for vanilla NDK.  Unfortunately I made a quick test and had some build errors in SDL2.  That's another avenue I'm pursuing.

General Discussion / Re: GLideN64 Android port
« on: May 25, 2015, 09:25:33 AM »
Those are good reasons to integrate FreeType.  Plus it would be nice to have the text from UI-console on the screen as well.  I'm bump it up my priority list.

@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.

That's an interesting comment actually.  This may sound like blasphemy, but if there were a set of build flags/config options that removed GLideN64's advanced features and made it equivalent to gles2n64, then we could drop the gles2n64 plugin from the mupen64plus-ae repository (one less thing for us to maintain).  I'm guessing GLideN64 is too far evolved to make that a realistic proposition, but I thought it was worth mentioning.

Support / Re: Amazon Fire Controller Support?
« on: May 24, 2015, 02:04:34 PM »
You're using a really old version.  The alpha releases are more up to date:

General Discussion / Re: GLideN64 Android port
« on: May 24, 2015, 02:03:40 PM »
I just finished GLideNHQ no-boost edition. Everything seems to work now:


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

Anything is possible :P  I can take a look.  How essential is it?  I believe the core or UI-console use it as well, but we never got around to integrating it since we already have a front-end with overlapping functionality.

General Discussion / Re: GLideN64 Android port
« 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.

Pages: 1 2 [3] 4 5 ... 50