Яндекс

Thursday, June 4, 2015

Android port. Current results.

Android port was the last task planned to implement within the schedule of GLideN64 Iniegogo campaign. The planned task duration was one month. The work started in May. Today I can summarize achieved results.

1. GL ES support.

As you know, mobile platform use subset of OpenGL standard API: OpenGL ES. There are five GL ES versions, from 1.0 to 3.1. Most of current Android devices can use GL ES v2.0. Newer devices are GL ES v3.0 compatible. Newest devices with Android 5.01 may have GL ES 3.1 support.

All OpenGL ES version have very different capabilities. GL ES 2.0. is quite old and limited. Nevertheless, all current graphics plugins for N64 emulators for Android use GL ES 2.0. There are two reasons for it:

  1. The plugins developed years ago
  2. 2/3 of users have devices, which capable to run only GL ES 2.0

During development of desktop version I had to use various advanced features of OpenGL. My code was not ready to fit the Procrustean bed of  GL ES v2.0 standard. From the other side GL ES v3.0 was much closer to my existing code. GL ES v3.1 has almost everything, which I used for desktop version. Thus, it was natural to start porting to Android from GL ES v3. That work was finished within one week. I disabled some part of code for GL ES v3.0, and just replaced few functions for GL ES v3.1. My code was integrated with Mupen64Plus AE emulator, and I got all necessary support from emulator's developers. Special thanks to littleguy and Gillou68310. I've got a build, which successfully run on NVIDIA Shield tablet. The build missed texture library for technical reasons, but everything else seems worked fine.
Zelda MM on NVIDIA Shield
I started to test my work on other devices and very soon found that situation with mobile GL is much worse than I thought. NVIDIA Shield is a perfect gem in a world of ugly boulders named mobile GPU. My Galaxy Note 3 is powered by Adreno 330 and claims to be GL ES 3.0 compatible. However it has so poor v3.0 support so I just don't know how to change my code to make it compatible with that piece of hardware.
Super Mario 64 running in GL ES 3.0 mode on Adreno 330
Thus, I was forced to complete mission impossible and port my code to GL ES v2.0

As I said, GL ES 2 is very limited and outdated. I had to disable large part of functionality for it (bye-bye mip-maping emulation), and rewrote remaining part to make it compatible with GL ES 2. I tried to support as much of plugin functionality as possible. Thus, GL ES 2 port supports most of frame buffer emulation features, and has limited noise emulation.
Mario Tennis running on GL ES 2 device

Note, that GL ES v2.0 support allowed to port GLideN64 not only on Android but on other mobile platforms, e.g. Pandora 
Conker BFD on Open Pandora

2. Texture library

Next hard task was port of GLideNHQ texture library, to get texture enhancement and hi-res texture packs support. GLideNHQ uses Boost portable C++ libraries for OS-independent file-system access. Boost works well on desktop OS, but Boost for Android has experimental status. Gillou68310 managed to build Boost for Android, but any attempt to actually use it caused application crash. The only remaining solution was to remove Boost dependency. I rewrote GLideNHQ code, replacing Boost by small custom filesystem library. After that I got texture library working, including hi-res textures support. However, it worked only on Shield tablet.

Texture library code does not use OpenGL functions, and independent of GL version. Thus, it had to work on every Android device. Long debugging revealed the problem: most of Android devices have very limited support for wchar_t* strings. GLideNHQ uses wide strings for correct work with non-ASCII paths and file names on desktop OS. Android supports wide strings on its Java API level. Support on native code level is near zero. You may compile code with wchar_t* strings, but it will not work because most of wchar_t functions do nothing. Thus, I had to write special wrapper to work with wide strings on Android. That finally allowed GLideNHQ to load hires textures on every Android device.

Gillou68310 added port of FreeType library to the emulator, which allowed me to have the same text drawer, as on desktop version.
Hi-res texture pack load

Super Mario 64 with texture pack
Yoshi's Story with texture enhancement


3. Post filter


Final task was post-filter support. Again, GL ES 2 required special code, but it was solved.
Wave Race with Bloom

4. Problems

Currently the main problem is performance. GL ES 2.0 devices are too week to run GLideN64 full speed. Performance depends on GPU. Mali-400 devices work not bad, some games run full speed. PowerVR GPU has slide show performance. GL ES 3 devices usually run full speed.

There are problems with frame buffer emulation. Color/Depth buffer copy works slow even on NVIDIA Shield. Some effects, which work on desktop do not work on mobile version.

Also there are many cases when code is compatible with some GPU, but does not work on other one.
I have only few devices on hands and can not test and fix all cases.

Conclusion:

All tasks planned in Indiegogo campaign are fulfilled. Huge amount of works have been done within several months. Master branch in Git repository contains more than thousand commits. New open-source graphics plugin with unique set of features successfully works on desktop and mobile platforms. Of course, not everything is fine. Not all planned features implemented, not all games run flawlessly. However, I hope that open-source nature of the project will help the project's further development.

Sergey Lipskiy.


9 comments:

  1. IshiirukaFX is a good new suite.
    https://github.com/Tinob/Ishiiruka/commit/919f3f7d175588d4714bd0408013668d22432107

    Super xBR
    https://github.com/libretro/common-shaders/commit/a8f201961e21a26ac0e4ed7c4f92c11b9ee9bd55

    NNEDI
    https://github.com/libretro/common-shaders/commit/a5251d785c0849a402b79c4f8b824e7b82719081

    ReplyDelete
    Replies
    1. thanks. how does a non developer get the plugin onto mupen?

      Delete
    2. Desktop version of the plugin for mupen64plus is here:
      https://github.com/gonetz/GLideN64/releases/download/Public_Release_1.1/GLideN64_Public_Release_1.1.7z

      Android port is not officially released, because the emulator has alpha status. You may build it yourself from sources or find links to dev apk on Mupen64Plus AE site.

      Delete
    3. Congrats on the results! Sounds like a challenging undertaking

      Delete
  2. Nice! Hope someone can port your plugin (and Mupen64Plus AE) to the new Pyra handheld device once it's out. But it probably won't support GL ES 3.0/3.1 unfortunately as I realised by looking this up after checking the Pyra's specs page: http://www.notebookcheck.net/PowerVR-SGX544MP2.125344.0.html.
    It says that it only supports DX 9.3 and GL ES 2.0. Oh no. So does that mean that your full plugin package won't be supported, but instead be truncated for that platform?

    However this one: http://blog.imgtec.com/powervr/the-powervr-sgx544mp-a-modern-gpu-for-todays-leading-platforms
    says: "Thanks to the PowerVR architecture, SGX544 is capable of exceeding both OpenGL ES 2.0 and DirectX9_3 requirements, making it ideal for tablets, computing devices and smartphones."
    "Not only that, but we have recently pushed the boundary for all existing PowerVR Series5XT GPUs with a new series of API extensions which include OpenGL ES 3.0 features like MRTs, occlusion queries, seamless cube maps, sampler access from vertex shaders, floating point textures, GLSL full-precision floating point, R and RG textures, min/max blends, and multisample render buffers."
    Is it possible for the Pandora/Pyra team to add in graphics drivers for Pyra to support GL ES 3 and 3.1?

    However they could have instead upgraded to the next step up as the PowerVR series 6-- and above do support GL ES 3.1! Perhaps you could offer advice to the Pandora team about this?
    http://en.wikipedia.org/wiki/PowerVR

    ReplyDelete
  3. http://boards.openpandora.org/topic/18022-gamecube-emulation-on-pyra/
    Here someone replied with this: "Dolphin REQUIRES OpenGL3.0. The OMAP5 does not have that. It will not happen, not without a LOT of rejiggering." regarding a different emulator.

    ReplyDelete
  4. It's all been cleared up. http://boards.openpandora.org/topic/18165-will-you-consider-an-upgrade-to-the-graphics-chip-on-the-pyra-board/
    I suppose we'd just have to wait and see if the maker will make future upgrades using all-new SoC boards inside the Pyra handheld.

    ReplyDelete
  5. I got a new laptop (Latitude E7440) using the latest intel hd drivers on my hd 4400. I tried Majora's Mask and it shows a red nintendo 64 logo and the zelda logo is all black. I've also noticed retroach shaders don't work, so there must be something wrong with my setup.

    ReplyDelete
    Replies
    1. Actually, it was fixed by downloading Dell's drivers instead of generic Intel drivers. Seems Windows 8.1 came with the default drivers.

      Delete