GlideN64 FX
- Thread starter NES_player4LIFE
- Start date
Category: <b>Nintendo 64 Plugin development </b><br><br>:: GlideN64
Gonetz has started another campaign for the adding of effects to GlideN64!
The goal is $2000.00 with $30 beta access!
Donate now.
https://www.indiegogo.com/projects/gliden64-fx
Are you kidding me, right ? I am not paying him for this plugin. He is doing it for a profit. A 30 dollars beta access ? Oh my goodness, he is nut! What a world coming to ? Greedy is everywhere for the money. Jeez.
LyonHrt
Dcemu.co.uk guy
i can actually see the point in charging for a beta access, i mean how many have pj64 1.7? it wasn't released publically, but quite a few have it because it was leaked. At least if everyone who wants access to beta have to pay for the privilege then hopefully it should minimise it.
Of course. I hope that many programmers do not followed like Pj64 1.7 team and now this one. Sighing.
Yeah.. blessing to those people who purchased willing to share. I did once when I purchased no$gba for 2 dollars donated to the developer and I never received it so a person knew me and trusted me and share it with me. That's why I don't trusted the donators at all!
Ambient_Malice
New member
I'm of the opinion that if Gonetz needs money he should set up a Patreon. Simply ask for money to support himself. This current model of "give me money and I'll add this feature" leaves a bad taste in the mouth.
For example, suppose Gonetz gets 2k, and then in a few days some random coder comes along and makes a pull request to add the feature?
For example, suppose Gonetz gets 2k, and then in a few days some random coder comes along and makes a pull request to add the feature?
chiburunga
New member
I do not have problems with the campaigns because the plugin is free... and he get his profit... HE IS WORKING... you only have to pay if you want early beta access...
OP
- Thread Starter
- #9
Programmers on site code as a hobby, however, they still have bill's to pay, if their code is beneficial to the community then we should help ease the financial burden.
Nobody is buying the plugin. If you wish to support the project then do so, if not, then hold your peace and wait for the release.
We at emutalk do not support leaking beta's attempts to do so have resulted in banishment.
Nobody is buying the plugin. If you wish to support the project then do so, if not, then hold your peace and wait for the release.
We at emutalk do not support leaking beta's attempts to do so have resulted in banishment.
Ambient_Malice
New member
GLideN64 is licensed under GPL, meaning that any binary releases must be accompanied by source code. As some have noted in the past, you can't actually "leak" a plugin like GLideN64 because the license grants redistribution rights.
Anyhow, I'm guessing Gonetz will work within the public repo, since he's expecting help from other devs going forward.
Last edited:
I think that emus should no longer include postprocessing effects. ReShade basically accomplished this for everything. Gonetz should focus on the more important things now since postprocessing is now automatically given to everything from ReShade. This is a breath of fresh air because everyone can focus on other things since this big part is already done for them.
Most importantly, the FSAA should be worked on because it is very slow when turned on. Especially on the Zelda menus when you have a high rez texture pack on. Texture Filter and Texture Enhancement are still broken as well as they cause micro stutters. I'm on a 980m i7-4960x.
Most importantly, the FSAA should be worked on because it is very slow when turned on. Especially on the Zelda menus when you have a high rez texture pack on. Texture Filter and Texture Enhancement are still broken as well as they cause micro stutters. I'm on a 980m i7-4960x.
Last edited:
Ambient_Malice
New member
Relying on an external tool such as Reshade is a bad idea. I do think porting Dolphin shaders is of questionable value, however. The only shader that is immediately necessary is SMAA, since certain games conflict badly with MSAA. I don't even think Dolphin supports SMAA - it has rubbish FXAA instead.
I can't help feeling that Gonetz has some poor priorities when it comes to features.
On another note, have you enabled Prefer Maximum Performance in drivers? GLideN64 performs poorly without it in some cases.
Nope I haven't enabled that in the drivers. I prefer my power saving features. It's not that though. It's the plugin's optimization. My machine is a beast 
Why is it a bad idea for external shader? It's practically done and for ALL backends. And it achieves not having to beg and plead with poor attituded devs (in general) that make you wait for something that you asked 3 years ago for and only starts doing it when someone else is doing it.
http://postimg.org/image/4jjxm323v/
http://postimg.org/image/8q4s1f1pn/
http://postimg.org/image/vg3wuekx7/
http://postimg.org/image/z9xd3k297/
http://postimg.org/image/gmp99nd63/
http://postimg.org/image/6fbbazgbv/
http://postimg.org/image/4datwqicr/
http://postimg.org/image/3z9hx4y97/
http://postimg.org/image/z8s0nvpt7/
Wa-Lah! Body. Is Ready.
Get the community texture pack and then set FSAA to max. Then push start and scroll through the windows. You'll see.
Or turn on the texture enhancement options with a texture pack. You'll see that it stutters every 5 secs like the old rice plugin use to.
Why is it a bad idea for external shader? It's practically done and for ALL backends. And it achieves not having to beg and plead with poor attituded devs (in general) that make you wait for something that you asked 3 years ago for and only starts doing it when someone else is doing it.
http://postimg.org/image/4jjxm323v/
http://postimg.org/image/8q4s1f1pn/
http://postimg.org/image/vg3wuekx7/
http://postimg.org/image/z9xd3k297/
http://postimg.org/image/gmp99nd63/
http://postimg.org/image/6fbbazgbv/
http://postimg.org/image/4datwqicr/
http://postimg.org/image/3z9hx4y97/
http://postimg.org/image/z8s0nvpt7/
Wa-Lah! Body. Is Ready.
Get the community texture pack and then set FSAA to max. Then push start and scroll through the windows. You'll see.
Or turn on the texture enhancement options with a texture pack. You'll see that it stutters every 5 secs like the old rice plugin use to.
Last edited:
Ambient_Malice
New member
Nope I haven't enabled that in the drivers. I prefer my power saving features. It's not that though. It's the plugin's optimization. My machine is a beast
Why is it a bad idea for external shader? It's practically done and for ALL backends. And it achieves not having to beg and plead with poor attituded devs (in general) that make you wait for something that you asked 3 years ago for and only starts doing it when someone else is doing it.
GLideN64 is incompatible with Nvidia's adaptive performance. Dolphin is similarly affected. Nvidia GPUs will underclock incorrectly and choke performance. This may not be the case here, but GLideN64/Nvidia runs horribly on a GTX 750Ti unless adaptive is turned off.
Reshade has three major problems. Firstly, it is closed source. Secondly, it is Windows only. Thirdly, GLideN64 needs an integrated SMAA method that can be, for example, set to only enable in games that break if MSAA is enabled.
Have no problems here in relation to adaptive performance. The same probs I stated here were problems with the original glide as well. Dolphin also has the AA too stronk problem Putting AA on the lowest setting still lags the emu in the same way. So it has to be the way it was coded. Doesn't seem optimized.
Reshade being closed source isn't a problem that relates to this. I don't even view that as a problem. Windows only, ok. But what emu that's better than PJ64 is there for any other OS? Can't say mupen because every game I tried always has a major issue or just flat out doesn't work. As for the last option, there are so many other options to choose from other than smaa. If gonetz enables downsampling in the plugin in the future, you won't even need much of smaa anyway or fxaa would do just fine since you will need less AA when you have downsampling on. You can use QfxPro to junction and you don't even need smaa at all because QfxPro seems to get rid of every single jaggy onscreen without a performance loss. As far as opengl and n64 emulation goes.
Putting AA on the lowest setting still lags the emu in the same way. So it has to be the way it was coded. Doesn't seem optimized.Reshade being closed source isn't a problem that relates to this. I don't even view that as a problem. Windows only, ok. But what emu that's better than PJ64 is there for any other OS? Can't say mupen because every game I tried always has a major issue or just flat out doesn't work. As for the last option, there are so many other options to choose from other than smaa. If gonetz enables downsampling in the plugin in the future, you won't even need much of smaa anyway or fxaa would do just fine since you will need less AA when you have downsampling on. You can use QfxPro to junction and you don't even need smaa at all because QfxPro seems to get rid of every single jaggy onscreen without a performance loss. As far as opengl and n64 emulation goes.
Ambient_Malice
New member
N64 emulation is moving away from closed source code as fast as possible because it has caused so many headaches in the past.
Mupen64plus needs work, but is a solid emulator. PJ64 may not always be Windows-exclusive. That's one of the benefits of being open source.
This doesn't change the fact GLideN64 lacks an integrated post-processing AA method. It needs one because several games are incompatible with MSAA. (Downsampling is a whole other kettle of fish.) It is not acceptable that users should have to use external, closed source software to get working AA.
Ambient_Malice
New member
Slightly different problem. MSAA conflicts with the more accurate (optional) N64 depth calculation mode used for certain games. Also, Factor 5 games act up with MSAA for some reason. MSAA is working with framebuffer effects, though.
wareya
New member
One thing I'd like is physically accurate bloom, not this threshhold stuff.
The idea behind threshhold bloom is that games are already "HDRed", where dark parts are overexposed and bright parts are underexposed. So you can't get physically accurate bloom out of it anyway. Or, the game clips its overbright parts, and you need to bloom those parts more than the rest anyway (I saw someone call a technique for this "overbright reconstruction"). But either way, bloom doesn't look good to me unless there's bloom in the dark spots, but one can't get enough bloom in the bright spots without making there be too much bloom in the dark spots, atm.
Off-topic: I do find the fundraisers a bit silly, but they're not wrong if he's doing open source work and manages to get funded. I definitely think it's going to be hard to hit the funding goal on this, though, especially with flexible funding.
The idea behind threshhold bloom is that games are already "HDRed", where dark parts are overexposed and bright parts are underexposed. So you can't get physically accurate bloom out of it anyway. Or, the game clips its overbright parts, and you need to bloom those parts more than the rest anyway (I saw someone call a technique for this "overbright reconstruction"). But either way, bloom doesn't look good to me unless there's bloom in the dark spots, but one can't get enough bloom in the bright spots without making there be too much bloom in the dark spots, atm.
Off-topic: I do find the fundraisers a bit silly, but they're not wrong if he's doing open source work and manages to get funded. I definitely think it's going to be hard to hit the funding goal on this, though, especially with flexible funding.
mrmudlord
New member
Whats that? Some shader method of AA?