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+%.
Is there any way to expose the depth buffer to shaders? That way effects like SSAO and DOF would be possible.
ReplyDeleteIshiiruka (a fork of the Dolphin Emu) just implemented those effects.
https://forums.dolphin-emu.org/Thread-unofficial-ishiiruka-dolphin-custom-version?page=216
The fork is open-source (as expected given the nature of the GPL license of the Dolphin project) so you can check their implementation in the repo.
Here is the commit that implemented SSAO:
https://github.com/Tinob/Ishiiruka/commit/6c1603447a630fe5f724d4812008490e627d7c92
I'm pretty confident that if you can implement SSAO and DOF it will surely attract more users to the campaign. Just imagine... Zelda Ocarina of Time + SSAO + DOF + DolphinFX shaders... *drools*
Also, would an implementation of Geometry Shaders be possible later down the road? Dolphin just recently added support for Geometry Shaders for proper Stereo 3D support, and even enabling the possibility of Virtual Reality support in the future (!)
They made a really interesting article talking about the challenges they faced while implementing stereo 3D here. I recommend you to check it out.
https://dolphin-emu.org/blog/2015/05/13/a-second-perspective/
Not to mention that with geometry shaders, it would be possible to implement N64 model tessellation. The interesting thing here is that I just found a thread where Orkin implemented polygon tessellation on his GLN64 plugin as a test, using some technology made by ATI at the time called TruForm.
He faced some challenges, as he relates here:
http://www.emutalk.net/threads/27112-An-idea-to-N64-games-enhacement-TruForm?p=269311&viewfull=1#post269311
But two post after that, he posted these screens:
http://www.emutalk.net/threads/27112-An-idea-to-N64-games-enhacement-TruForm?p=269929&viewfull=1#post269929
Ah, so that's where those screens I sent you time ago came from! Who would have said Orkin was the man behind these the whole time? :P
Too bad he never released the source of his implementation though. Or a useable prototype for the record.
And lastly, I wish you the best luck with your newest campaign, and hope that is as successful as the first one. A $2000 USD goal sounds completely reasonable although the odds for success can be greatly increased if you are able to implement some of the things I mentioned here :P
PS: Now that you submitted all the commit history to your GitHub repo, I hope that improvements and bugfixes start coming soon from people all around the Open Source community! Especially from the people that were whining about the so-called license violation :P
Regarding SSAO: GLideN64 FBOs use depth buffer texture, which can be used for SSAO and DOF. I just not sure that it can be done within one month.
ReplyDeleteGeometry shaders is far perspective. I hardly will have time for it.
I also hope that improvements and bugfixes start coming soon from people all around the Open Source community. I just have no time for bugfixes right now. Currently my task is to build a strong foundation for further development on all supported platforms . This campaign's success will allow me to build basis for all post-processing techniques.
What ? No thanks. Are you nuts?! Its a shame how people will still praise them despite their greedy! Jeez! No no and no!
ReplyDeletek.
DeleteThis project is not for profit, so there is no greed at all. It's great that there are so many people out there who can work for the community for free, but those people are not contributing to emulating N64 graphics in this way. It's good that a project like this exists, because there would be no progress at all otherwise.
DeleteYou mean "Thank you" perk? My bad, forgot about it, sorry.
DeleteThis comment has been removed by the author.
ReplyDeleteGreat news! Glad to contribute! I wish you all the best with the development of GlideN64, you already did great work.
ReplyDeleteBtw, are you going to fix the windowed mode bug and the font bug for Intel HD devices?
I hope you're going to submit the project history to github soon, so people can help out fixing leftover bugs in GlideN64.
Full history had been pushed on GitHub few days ago.
DeleteNot sure about Intel HD devices, I have nothing like this on hands.
I have Intel hardware which I can test with. Hopefully that could help lead to a solution.
DeleteHowever, it should be clear that fixing bugs is a secondary priority of this campaign only achievable if the goal is exceeded.
This comment has been removed by the author.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteIshiiruka has modified DolphinFX and multi-pass shaders, perhaps you can copy something from there https://github.com/Tinob/Ishiiruka/commits/master
ReplyDeleteMany good shaders that can be potentially ported too:
https://forums.dolphin-emu.org/attachment.php?aid=13526
Libretro Mupen64Plus seems to have some fixes and improvements not present in your plugin.
https://github.com/libretro/mupen64plus-libretro/commits/master
Read this thread, it has a list of post-processing features.
ReplyDeletehttps://forums.dolphin-emu.org/Thread-pack-of-ported-shaders
Another good shader pack which you could port is psxfx but it requires even more advanced post-processing features than DolphinFX.
https://forums.dolphin-emu.org/attachment.php?aid=13147
It's too early to dig so deep: the campaign gained only 10% so far.
DeleteI think you should save time and not include this since it is already done for you and for everyone with ReShade. That was the purpose of ReShade being made.
ReplyDeleteHowever, I would rather FSAA, Texture Filter, and Texture Enhancement be fixed. FSAA causes slowdown. Especially with games with texture packs (zelda's item menu). The last 2 cause micro studders with texture packs.
Well, ReShade is an argument. However, N64 emulation has its own specific and universal post-processor may not work properly with it.
DeleteRegarding the priority of tasks to fix: amount of work will depend on campaign success. IMO, emulation issues have higher priority.
Will there ever be a 64-bit version to use in the new 64-bit project64?
ReplyDeleteNevermind, I saw your answer on github to this question that someone else asked.
DeleteHello, i just want to put out there that when I attempt to use something like reshade for example, it can inject these effects.... however, for some unknown reason, the depth buffer isn't aligned with this plugin?
ReplyDeletelike it can insert SSAO into just about any program that it can access depth buffer in.
however when i attempt this with gliden64, it works however its not aligned.
when i try this in glide64 final, it works only on ocarina of time and various rare games, but its perfectly aligned.
if it were aligned, it would allow for access to an utterly massive library of effects to be used.
pretty much every variation on ambient occlusion, bloom, color correction, i think motion blur, lens flares, depth of field, vignettes ETC.
its probably a bit better than dolphinfx, and I think its worth looking into.
heres a shot of glide64 final with it running.
http://i57.tinypic.com/qqz706.jpg
GLideN64 uses FBO depth texture in frame buffer emulation mode. reshade does not know about it and can't use it. Disable frame buffer emulation to make depth buffer effects working.
ReplyDeletewow thanks gonetz.
Deletethats actually really handy.
Your latest GLideN64 plugin has fixed the graphical glitch(es) in the Conker game when I tested it a bit. But so far both Star Wars: Rogue Squadron and SW: Battle for Naboo are unable to boot in - they just either freeze or not boot at all! Are these the problems with the N64 emulators currently and not the fault of your plugins? I thought that these games would work, because you've demonstrated several screenshots of each game when promoting your new plugin before release. This seemed misleading. If you knew that these games wouldn't be working then why did you bother showing these in-game pictures?
ReplyDeleteI show you these in-game pictures because I had no problems to go in-game. Star Wars: Rogue Squadron and SW: Battle for Naboo work only in LLE mode. You need to use proper RDP plugin to get in-game. Emulator's version also important. Some emulators can't boot these games even with proper RDP plugin, but I don't remember which ones.
DeleteYes, I can confirm that you're completely correct. I've been trying to add in plugins to either of my Project64 2.2.0.3 (The latest official release from the PJ64 team) or the latest M64Py frontend with the Mupen64Plus core (Note to users, just download the latest M64Py build from emucr.com as it'll contain the latest Mupen64Plus core anyway - in this case version 2.5.). And I've been tweaking things here and there yesterday and today!
DeleteI had to google search 'PJ64 rogue squadron' and found this useful guide: http://emulation-general.wikia.com/wiki/Recommended_N64_Plugins.
The page above also led me to a forum at http://www.emutalk.net/forums/showforum.php?f=31 where I researched several plugins such as the accurate but old z64 RSP plugin, Shunyuan's HLE audio plugin and angrylion's RDP (For Video) plugin with OpenGL maintained by Iconoclast/HatCat. But I couldn't find the CXD4 plugin also from HatCat.
So I was using the z64 RSP plugin along with GLideN64 (Yours truly!) in PJ64 and Rogue Squadron was working and displaying everything correctly but it was way slow - depending on settings being used it was 12 VI/s or 20-22 VI/s.I also attempted to boot into Battle for Naboo but it was showing a lot of perspective or geometry rendering errors, so it was unplayable, though I could move around just by looking at the minimap!
Then after a while I tried the M64Py frontend emulator and used cxd4-sse3 plus your GLideN64. Apparently both hard to solve Star Wars games booted up nicely and all graphics rendered correctly. Also the framerate seemed to be a bit smoother - like it might be twice as fast as in PJ64, though I wish it'd show a framerate counter. The hit zones in RS were much more responsive, flying was a bit slicker. Of course the small random flickering errors, too, but not much to distract me; it mostly happened in the mission room. The background scene in the start menu and sometimes in the first level of Battle for Naboo there were geometry rendering errors; but most of it and the whole 2nd level were stable. Framerate was similar, but it was easier to play here.
So I was slightly disappointed by the choppy framerates then I thought to tweak the RSP plugins and after some steps chose the lower-end cxd4-sse2 plugin. And much to my amazement both Star Wars games as well as Star Wars Racer (which I tested with the other plugins above) all ran at smooth framerates! Yes!
My PC is a cheap i5-2500 CPU I think and Nvidia GeForce 750Ti and 8GB of RAM. So you don't need an expensive rig to be able to run N64 games well!
I gasp in amazement as the video plugin you've made has blown the N64 emulation scene out of the water and moves it a few dials after 15 years of waiting for the 'perfect N64 emulator'! I am also surprised by Mupen64Plus 2.5 + M64Py frontend - I think it is set up well for the future while Project64, even now, ends up looking more of a dead-end!
I forgot to add in the above post that I also found HatCat's cxd4 RSP plugin files from this thread: http://forum.pj64-emu.com/showthread.php?t=3618. I was also testing it in PJ64, but the framerates in Rogue Squadron wasn't much better.
DeleteThis comment has been removed by the author.
DeleteI've also tested to check the title shine rendering of the game Extreme-G in both Mupen64Plus (M64Py frontend) and PJ64. And it looks like PJ64 is showing it correctly while I couldn't find a way to get it looking right in Mupen - it has that old squares-shifting problem. Looks like I'll still have to use both emulators for the forseeable future...
Delete>I also attempted to boot into Battle for Naboo but it was showing a lot of perspective or geometry rendering errors, so it was unplayable, though I could move around just by looking at the minimap!
DeleteThis is a known problem with PJ64. There's a fix, but you have to compile a custom build yourself.
>So I was slightly disappointed by the choppy framerates then I thought to tweak the RSP plugins and after some steps chose the lower-end cxd4-sse2 plugin. And much to my amazement both Star Wars games as well as Star Wars Racer (which I tested with the other plugins above) all ran at smooth framerates! Yes!
There's something wrong with the ssse3 RSP interpreter plugin for mupen64plus. Performance is awful. I've mentioned this to the mupen64plus team, but nothing has been done yet.
>Project64, even now, ends up looking more of a dead-end!
In PJ64's defense, it emulates Battle for Naboo\Indiana Jones with far less freezing and geometry tearing than mupen64plus. (Needs a custom build, though.) It also runs LLE games like World Driver Championship, which mupen64plus can't boot. (yet)
You need to set "N64 depth compare emulation" option for Extreme-G. Project64 version loads necessary settings from custom ini file. Mupen64Plus build does not have support for custom game settings yet.
DeleteNice! Thanks for your comments and help. I've turned that option on and it works as intended! I'd remembered about the depth compare emulation before but wasn't quite sure what it would be used for so probably my memory was a bit foggy.
DeleteRegarding PJ64 I've seen forum threads and webpages which say you'd have to have these or those older versions of the plugins in order to get something to work in it. But I'd rather not spend the time tracking them down and testing their performances. It's just a hobby after all.
you guys I am getting a black screen on this plugin I have Ati mobility radeon hd 4200 series I checked and I have a OpenGL version 6.4 and some other numbers anyways its higher than 3.3 And I am trying to play OoT djipi 2014 texture pack so why the black screen can any of you guys help me thanks ;) And before you guys say if my drivers is up to date yes it is ;)
ReplyDelete