Improved 2D and other fixes

Hello,

As you may see, the blog had no updates for several month. The reason is simple: works for Indiegogo campaign have been finished; attempts to get additional funding for project development failed. Now I have a job and as result have almost no free time for my hobbies. This does not mean that the project development is stopped. The project is open sources and in a good shape thanks to rapid development period. New features and fixes implemented not only by me, and in the last time mostly not by me.

2D improvment

Firstly I want to present you new feature, which I started to develop yet in summer but was unable to finish until now due to lack of time. It addresses 2D images quality. As you may notice, all N64 graphics plugins with hardware rendering have problems with large 2D images. 2D images look very misaligned, like this:

Software graphics plugin renders this picture with no issues:

Why this happens? N64 has only 4 kilobytes of texture memory. 320x240 background image takes 150 kilobytes. The hardware can't render large images as one piece. So, to draw the image it need to be split on hundred narrow stripes with height of 2 pixels. Here how it looks in wireframe mode:

Strips are not the problem. The problem is that each stripe of the image is filtered with bilinear filter to get more smooth result. Filtering has no negative effect when native resolution is used. You may run hardware graphics plugin in native 320x240 resolution and find that it works as good as software plugin; no texture misalignment. It is because texture strip and corresponding polygon have the same size and there is one-to-one pixel to texel correspondence. However, nobody uses native N64 resolution with hardware plugins (there is a request to support rendering in native resolution and then scale it to screen resolution, but it is different story). When resolution increased, polygon size increased accordingly, but texture remains the same. Each strip filtered separately and that causes misalignment on bounds between strips. Of course, it is possible to disable texture filtering and get aligned but pixilated image:

some people like sharp unfiltered images.

I implemented new method of drawing 2D images. We know that it is impossible to render stripped low-res 2D image in high-res and get aligned filtered result. Thus the idea is to render 2D in native resolution. The plugin detects that adjacent parts of a 2D image are drawn and renders all parts of the image in an auxiliary buffer using native resolution. When all parts of the image are drawn the whole image is rendered to the main buffer. Since filtering applied to the whole image, not to its parts, the image has no alignment problems:

It sounds simple, but as usual the devil hides in details. I spent many hours on debugging and even wrote my own bilinear filtering shader because standard one causes glitches. Also, the new method is not universal. It works well in most games. There are one-two games, which are incompatible with it. And there are several games where it makes some 2D images look better and other look worse. Mobile version also may suffer from performance issues.

I put the code into a feature branch fix_2D. The new method should be optional, but currently it always enabled. I'll add config settings when it will be ready to merge to master branch. Right now I want it to be tested. Please download the binaries and leave feedback in that ticket.

Other fixes

Here the incomplete list of fixes made since the latest Public Release:

• xBRZ texture filter updated to version 1.4 Up to 6X texture scaling is now supported.
• Implemented Shaders Storage feature. Compiled shaders can now be saved and loaded on next start of the game. Performance increased.
• Fixed camera in Zelda MM
• purplemarshmallow made lots of fixes in Frame Buffer Emulation code.
• matto fixed and optimized texture cache work.
• Francisco Zurita fixed plugin work on Adreno GLES 3 devices.
• gizmo98 added Raspberry Pi support.

Project news

Hello,

There are not so many important news since the latest Public Release:

• My attempt to collect more funding for the projects failed. GLideN64 FX collected 66% of the goal. Since project did not reach the goal, GLideN64 FX will not be implemented and collected funds will cover my work on project development during June. My Patreon project got circa 12% of necessary sum, so I closed it before patrons got charged. Thus, project development returns to passive state. Further progress will depend of my load in real life. Other developers activity also may push the project forward.
• Several issues have been fixed since the last release, both on desktop and mobile platforms. There are several bugs and features in progress, where I did preliminary research and now just need to find time to make proper fix.
• I go on vacation and I will be mostly offline next two weeks. Thus, I decided to fix current project state as new Public Release:
  https://github.com/gonetz/GLideN64/releases/tag/Public_Release_1.2
  Android port is not officially released yet, but you always can get current test build here:
  http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/

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.

GLideN64 FX

Hello,

Users asked me what I'm planing to do when I finish with Android port.
Usually I answer as: I will continue to work on the project as on my favorite hobby. However, since I usually have no time for hobbies, active development will be impossible.

Android port goes well. However, it still needs circa two weeks for completion. Thus, I decided to make another attempt to collect funds for further development and today I started new campaign on Indiegogo - GLideN64-FX. The campaign is dedicated to porting of DolphinFX post-processing suite to GLideN64. It is primary task, which I estimated as one month works. I'm not sure that campaign will reach the goal. However, the project has plenty of tasks to do beside it. If campaign goal will not be reached, collected funds will be spend to fixing most serious problems open in bug tracker. If the campaign will be super-successful and rise more funds than necessary to implement the campaign task, the rest of funds also will be spend to project development.

Result of the first two weeks of the campaign will show me what to do next: prepare to the next challenging task or update my resume.

Update: It seems that the campaign does not attract much interest. 20% collected for 10 days. My thanks to 11 people who already backed the project. However, it's not enough. 50% until June would be a signal for me to start works on that task. 20% is the signal to use plan B.

Update 2: 30 % at the moment. Not bad, but still not enough.

Update 3: 41 % at the moment. Almost there. I need few days to fix remaining issues with Android port. Hopefully, that time will be enough to reach 50+%.

Public Release 1 Update 1.

Hello,

Active testing of the first Public Release revealed many new issues in plugin's work. Since I'm busy with Android porting, I can't spend my time on issues with emulation. However, several found issues related to general work of the plugin. Few scenarios of plugin's crash during emulation reported too. So, I took a break in Android development and corrected most nasty bugs:

• Fixed Texture pack path not saved correctly #456
• Enabled translations for About dialog, #494
• Fixed anisotropic filtering, #505
• Fixed Anti-aliasing compatibility with frame buffer emulation, #244
• Fixed crash in Glover, #474
• Fixed crash in Snowboard Kids, #477
• Fixed texture issue in Banjo Tooie, #499
• Fixed text corruption in Mupen64Plus

New sources included into distributive along with binaries for Windows and Ubuntu. Download from GitHub. The current version of sources are compatible with GL ES 3 and GL ES 3.1. Porting to GL ES 2.0 will start soon. GL ES 3.1 version has almost all features of PC build, except for texture library support. Below is screen shot from development alpha of Mepen64Plus AE integrated with GLideN64 running on NVidia Shield tablet with frame buffer emulation of.

Public Release 1

Hello again,

Two weeks passed since the “Early Release” and time for the first Public Release is come. Since the “Early Release” leaked week ago “in accordance with GPL rules”, eager people already know what to expect from this release. Nevertheless, development works continued all these two weeks, and Public Release got some new features.

The main new GUI feature is internalization support. It implemented just few days ago, and currently the project has only three translations: Italian, French and German. Thanks to our forum members baptiste, ratop46, Predator82 and Mark L.R. for these translations. If you want to translate the project on your language, check this wiki page:
https://github.com/gonetz/GLideN64/wiki/Internalization

Other changes are internal. Several bad regression bugs were found and fixed. We have done large work for improving stability of frame buffer emulation. Probability of game crash during emulation is greatly reduced. Project ini file with custom game settings cleaned and updated. Fixed problems with bloom post-filter.

Time to sum up the results. This project started as my little private hobby, but thanks to very successful crowd-funding campaign on Indiegogo we pushed it on very high new level. It is stable, compatible, fairly fast graphics plugin with unique features which you cannot find in any other N64 graphics plugin with hardware rendering. It supports all popular N64 emulators for Windows and it works well on Linux. All campaign goals successfully achieved. Moreover, the project got features, which initially considered as “may be somewhere in a far future”. Low Level Emulation and Widescreen support are among them.

There is the price for that. The project planned release date was January. Due to huge amount of works, the release delayed for four month. I expected that the project might take more time than planned when I prepared the Indiegogo campaign, but I did not expect that it would be twice as much. The planned Android port works will be finished, but I have no funds left for anything else.

I want to express my sincere gratitude to all people who helped me with that project. First of all, our main beta tester Olivieryuyu, who made that campaign possible and helped the project in variety of ways. All people, who donated to the project and make it real. Special thanks to most active forum members, who supported me and greatly helped me with testing: nesplayer4life , theboy181, Predator82, ratop46, aquatakat, baptiste, Mush Man, v1del.

Now I am switching to Android port. I already started that work. I am working with Mupen64Plus AE team.I am ready to contact with other projects dedicated to N64 emulation on mobile devices.

GLideN64 First Public Release Download Link on GitHub

Enjoy!

Update:
Source code in the release file contain a typo, which prevent sources from building on Linix.
Please download the distributive again, or load sources only.

Warning: bad bug with texture packs path found. Please don't change default value of this settings or use the workaround.

Translations update:
New translations pack is ready to download. It contains:

French translation by baptiste0602

German translation by WC-Predator and ratop46

Italian translation by Mark L.R.

Brazilian Portuguese translation by DaEckster

Spanish translation by IlDucci & PacoChan

Early release.

Hello,

Time for PC version release is come. All project supporters with perk "Early Release" will get link to archive with the plugin.

The archive contains the following builds:

• Win32 build for Mupen64Plus emulator. Put the dll file to emulator's folder and setup the emulator to use GLideN64 as graphics plugin. Run any rom. On the first run plugin creates settings section in emulator's configuration file. You may either edit it in text editor, or use one of Mupen64Plus frontends.
• Win32 build for Zilmar specs emulators: 1964, Mupen64, Project64 and others. Copy dll and ini files to emulator's plugin folder and setup the plugin to use GLideN64 as graphics plugin. Open video settigs configuration dialog and setup it for your taste. Read tooltips for options explanations.
• Ubuntu64 build for Mupen64Plus emulator. Making working binary distributive for Linux is tricky, so there is no warranty that it will work. Public release of the plugin will be open-source, and then you will be able to build the plugin from sources.

During development I solved literally hundreds of issues. More than hundred is still not fixed. If you want to open new bug report, please check already open issues first.

Public release will be two weeks after the "Early Release", stay tuned. I'm planing to spend these two weeks on code cleanup and preparations to Android port works.

Update: last minute optimization causes problem with saving hires-textures cache files. Hotfix will be uploaded soon. Sorry for inconvenience.

Project news. Late Backer Access. WIP screen shots.

Hello,

Some news about the project:

• Creative part of the development is finished. New GUI works well. FSAA works well.
• Circa 25 emulation related issues closed since the New Year beta release.
• Currently I'm working on frame buffer emulation issues. Proper frame/depth buffer emulation is hardest part for graphics plugin with hardware rendering. The work is very tiresome, the progress is slow. I have to reproduce the result of Glide64 which I reached for years of development in much shorter time. Of course, I'm not limited by target hardware as before, but crazy creative ways of working with FB which N64 games use still can drive me mad.

Again I have to state that I very underestimate the complexity of the task I set for that project. Funds run out and I'm afraid that I'll have to release an incomplete product. However, there is a good news: the Late Backer Access is open again. It will not be open for long, as the project can't last forever. If you want to help me to prolong active development for some time and fix remaining issues, you may do it now.

Here few comparison screen shots "before - now". It's from my current frame buffer emulation work in progress.

Full-screen antialiasing

No FSAA:

Set FSAA:

The result:

As expected.

Bloom post filter

Hello,

People ask me questions about support for various post-processing effects. In general, post processing of resulting image is simple thing: take the image and render it again as texture with post filter shader enabled. The first post filter was CRT shader, but here I had unsolved problem with shader itself. Recently I requested to make bloom filter. I found a simple open source bloom shader, which implements some custom algorithm. It works like this:

The shader has no controls, blurs almost everything and produces very strong bloom effect. Demo video:

The shader is good for demonstration, but practically unusable due to highly overexposed result. I started to dig deeply. I found that theoretical article explaining how bloom should work. Proper bloom post-filter is multi-pass; cite: "Take the input image and create a thresholded version of it, setting pixels below a specific threshold to black. Then blur the result and add it to the original image". Practical implementation for blur and blend is taken from devmaster.net. The result is much softer and the colors are much more natural than with the previous variant:

It also has lots of settings to adjust the result for your taste. Demo video will be available later.

GUI draft

Hello,

According to the “Plan for Project Completion” I started to design plugin's user interface.
I am not a great designer and I don't want to redo GUI layout over and over. Thus, I've made a playable prototype using QT quick. If you have QT installed, you may download prototype sources from my google drive. Unpack, open Test.pro in QT Creator, run. If you don't like my layout, feel free to change it. Any corrections and  suggestions are welcome. I want the GUI to be nice, clean and easy to use.

I still need to learn how to make standalone QT application, so if you don't use QT, let's check screen shots. The GUI consist of three panels: Video settings, Emulation settings and Texture Enhancement (screen shots are clickable):

Texture enhancement panel has three mouse areas which user can click to open system dialog to select particular parameter:

I could add buttons to open the dialogs. It would be more obvious but less elegant.

Screen shots with dialogs opened:

Update:

• It seems that currently static build of QT does not support QML. I tried hard to make static build of my demo, but failed. Static build of standard QWidget based dialog works fine. So, good bye QML.
• One of our users, aquatakat, took the sources of my demo and rearranged the layout. The result is very nice: http://imgur.com/a/y9Ol1 I decided to took it as the model for my new QWidget config dialog.
• I just finished with new GUI layout. I've added all options to the dialog, even the ones which are not implemented yet, like "Anisotropic filtering". Most of tooltips added too. GUI sources are here. Statically linked demo application is here. You can play with controls and see tooltips for them. 

Any corrections and  suggestions are welcome!