GLideN64 funding

Hello everybody,

As you know, GLideN64 development was funded by crowd funding Campaign on Indiegogo. I'm working on the project full time since September of 2014. The project's tasks scheduled on fourth months. The actual development took twice as much time. You may check the amount of work done in Git repository to make certain that it was necessary. We open Late Backer Access to rise more funds and we got noticeable income. However, all collected funds ended before I finished last planned task - Android port.

Cite from my previous post: "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."

Now I stand before the question: what next? The project definitely needs further development. I may work on the project as on my hobby, as many other developers do. The project indeed started as my little private hobby, without any ambitious goals. I knew that with that amount of free time which I had, I would never bring it to public release state. There are many people, who understand that. These people supported the crowd funding Campaign to get the result in reasonable time. Only after several month of hard full time work the project reached the state of public release. Now the project is released with all sources and all my commits are pushed to Git. Any developer may continue my work. I also would like to continue to work on the project to fix remaining bugs and implement user-demanded features. However, the work needs time. Serious modification or discovering of deeply nested bugs requires lots of time. It is hard to find few hours to work on my hobby after full day spent at office working on serious tasks. It's life.

I've made another attempt to collect funds for further development and open new crowd funding Campaign on Indiegogo: GLideN64 FX. The idea is to port to GLideN64 post-processing effects from DolphinFX and probably other similar projects. This campaign met a lot of skepticism and currently reached only 50% of the goal. Many users said that they don't mind to help the project, but they don't like that post-processing idea and will not support it. These users prefer that I concentrate on bugs fixing and common usability issues. I understand and support this point of view. However, bugs fixing also needs time. In my case time is money.

GLideN64 FX already collected circa $1000. Now I have alternatives:

1. I may start to work on it in hope that the project will reach the goal withing remaining three weeks.
2. I may switch to plan B: if campaign failed, all collected money will be spend on bug fixing. Currently it is two weeks of full time work. Than I find new job and stop active work on the project.

Zilmar suggested me to try the third alternative. Cite: "I wonder if you would do better with something like patreon (https://www.patreon.com/) instead of indiegogo where in indiegogo you have a target and an end goal, with patreon it is constant and not directly tied with an outcome. You might be able to give patreons the same access you have given to contributes of the current project, like access to beta version/forum, people who donate more maybe get a bigger say in what you do ".  I checked terms of use on www.patreon.com. It allows international projects and I may use it. So this is really sounds like a good idea. It would be kind of freelance job, with me as freelancer and emulation community as collective customer. This implies customer-implementer relationships. That is customer/patreon decides which tasks have higher priority. Become a patreon and decide what is more important for you: post-filters, particular bug fixed, particular game supported etc. Being a patreon means that you agree to spend some amount of money on the project monthly. It can be any sum. What is important, the total monthly income must cover my monthly expenses. It is circa $2000. Thus I need 100 patreons as $20 each or 200 patreons as $10, or 400 at $5 and so on.

To implement that idea I need:

1. Register in payment system, which will transfer funds from www.patreon.com to me.
2. Register my project on www.patreon.com
3. Find necessary number of patreons.

Steps 1. and 2. will be useless if step 3. failed.  Zilmar posted this idea on GLideN64 forum and few forum members already supported the idea and agreed to be patreons. Of course, it is not enough. I don't know is it possible to attract necessary number of patreons. I want to inquire for it first. If you like the idea and agree to be project's patreon, please write me email to "gliden64 at gmail dot com" or to my regular email with the information: "I'm ready to pay X USD during Y months". If total sum will reach the goal within this month, I'll open the project on www.patreon.com and GLideN64 development will continue. If not, well, plan B.

Update: According to comments here and on the forum, everybody agreed that patreon is a good idea, However, only few people wrote me that they are ready to participate. Currently I can count on circa $100 per month.

Update 2: Two important thing happened today almost concurrently:

• My application to payment system has been approved. Now I can open my project on Patreon.com
• I've got invitation from a large software company. I sent them my resume and I'll have an interview tomorrow.

I did not plan to search for job until situation with Patreon will be clear. However, the job found me first. I don't know details of the proposition, it will be discussed tomorrow. If we will come to agreement, further GLideN64 development will switch to plan B.

However, I'm still trying to save the project. I created GLideN64 project on Patreon:
https://www.patreon.com/Gliden64?ty=h
It does not look good yet. It need better text, proper motivation video, patron rewards system and other stuff to attract potential patrons. However, it already works and can be used to collect funds. Now project destiny is in your hands. You probably have just few days to decide. Success of that project will allow me to prolong my current freelancer status. I've created short video with instruction what to do:

PS: The project already has one patron. Just need another 100-200.

PPS: I'm still working on the project. Besides updates on GitHub, I almost finished with important fixes in texture code. These fixes will be finished and uploaded. Hopefully soon.

Update 3: My Patreon project got 5 patrons since the start with total monthly income as $146, or 7% of the goal. My deep gratitude to these people.
The sum is obviously not enough to continue the work. If situation will not changed within days I'll close my Patreon project before end of this month to not charge patrons for nothing.

GLideN64-FX collected just 50% of the goal and hardly will reach the goal for remaining time.
Thus, current situation with project funding leave me no options but Plan B: full time work on bug fixing for two weeks to fulfill my obligations before people who supported GLideN64-FX campaign. Then I switch to "work on the project when I can" mode.

I already started to work on bug fixing. Some results:

Issue #158

Issue #158

issue #571

Issue #426

These fixes are result of several days full time work: digging manuals, experiments, debugging, testing. I hardly will have enough time for such fixes in future, so I'm trying to fix hardest problems while I can do it.

Update 4: The Patreon project now has 8 patrons and reached 10% of necessary sum. One week left to get another 90%.

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.