Zilmar refuses to adopt GLideN64 and he's extremely obtuse about why (here is why!)

[SuperTurboTurkeyStuffer]

If Gonetz and Olivieryuyu continue to work on reverse engineering and HLE-ing N64 video ucodes, it is arguable that LLE graphics will become redundant for general users. The sticking point is that GoldenEye and Killer Instinct require low level triangle rendering for skies and water. Glide64 and GLideN64 have a dodgy implementation copied from z64gl. That's why they can run in "LLE" mode. Fixing LLE triangle drawing is extremely low priority, but should be dealt with eventually. This would both fix GE/KI skies and allow for acceptable LLE microcode graphics emulation. There's no benefit to using LLE over an accurate HLE microcode, but the option would be nice, especially as it will be a while before every microcode is fixed.

Also, you can't just backport these HLE implementations to Glide64 and expect great results. Like, what's the point of having working dynamic lighting in Turok 3 on Glide64 when shadows and a bunch of other stuff is broken? There's just so much wrong with Glide64, and while I kinda respect anyone wanting to salvage something abandoned by both lead devs a decade apart, it's effort better put elsewhere, IMO.

[RPGMaster]

There's no debate that GLideN64 is the most accurate HLE video plugin. It's unnecessary to try and explain all the ways in which GLideN64 is more accurate. If accuracy was the #1 criteria, I'm sure Angrylion's would be the default.

The problem with GLideN64 is that it requires relatively new hardware and has worse performance. Glide64 is more optimized overall. FB read performance will not be an issue if per-game FB notification is implemented.

What should be addressed are the flaws, not what it excels at. Being good at one thing doesn't necessarily make up for flaws. Which criteria is important, varies from person to person. I hardly see the suggestion "well go fix these problems yourself", as a real solution.

Originally Posted by theboy181

Posting about other emulators being superior with alternate accounts to mislead people is just cringy. Be the change, you want, and make an effort to help out.

It's a shame some folks resort to plain false advertising to get others to use a different emulator. I wish these people kept their invalid opinions to themselves, instead of spreading FUD. PJ64 isn't even my main N64 emulator, but I still acknowledge it as the objectively best overall N64 emulator.

Originally Posted by theboy181

however PJ's design is in the interest of just having an out of the box experience for any PJ's end user who doesn't meet the strict HW requirements for some plugins.

That's one of the reasons I support PJ64. I like what zilmar stands for. Much respect for that.

Originally Posted by theboy181

If I could have it my way the emulator would include Angrylion's RDP and LLE on by default. I'm sure that we all agree that if ALRDP performed on more than a handful of computers out there that this would be the best plugin to use as default.

Exactly. I would do the same.

Originally Posted by theboy181

Zilmar's plan to invest time on GFX should be embraced, not ridiculed.

This is so important! Graphics is the biggest issue with N64 emulation. No question. Either performance is lacking or accuracy and you have to pick your poison.

I can definitely relate to getting ridiculed / hate for trying to do something good. It sucks, but I just have to move on and go my own way. Gotta stay positive and keep movin forward!

[SuperTurboTurkeyStuffer]

Originally Posted by RPGMaster

There's no debate that GLideN64 is the most accurate HLE video plugin. It's unnecessary to try and explain all the ways in which GLideN64 is more accurate. If accuracy was the #1 criteria, I'm sure Angrylion's would be the default.

It's more about explaining why GLideN64 is both fast and accurate. GLideN64's obvious advantage is that it is both accurate and very fast. Moreso than Glide64, which has no meaningful performance advantages and woefully awful accuracy for every single N64 game right down to Mario 64.

Originally Posted by RPGMaster

The problem with GLideN64 is that it requires relatively new hardware and has worse performance.

It requires newer hardware than a Glide-based plugin? What a shock!

Let's be clear here. GLideN64 does not have performance issues, performs objectively better than Glide64, and performance on older devices that aren't ridiculously ancient is not an issue. (Since a fix is being worked on for exactly these "I don't want to buy an actual GPU" cases.)

GLideN64 is a project that is dramatically improving on a pretty much week by week basis. Meanwhile, Glide64 has actually gotten worse since 2008 in a few areas. Texture rendering in particular. There's a serious texture corruption issue in Glide64.

Originally Posted by RPGMaster

Glide64 is more optimized overall.

I feel this is a misuse of the word "optimized". Glide64 has terrible performance and even worse accuracy. (Like, what's the point of running Conker slightly faster on Glide64 when the plugin can't render any of the ground textures properly?)

Originally Posted by RPGMaster

FB read performance will not be an issue if per-game FB notification is implemented.

Wait, you mean the absolutely terrible idea of using per-game hacks? The one that doesn't hold up to 30 seconds of thinking about potential edge cases? Proper FB notification is a feature that should be pursued, and GLideN64 supports it, but it has issues with too many games. Would be extremely useful for Pokemon Snap and Jet Force Gemini, though.

Originally Posted by RPGMaster

What should be addressed are the flaws, not what it excels at.

What flaws?

Originally Posted by RPGMaster

Being good at one thing doesn't necessarily make up for flaws.

What flaws? You're the one arguing that a plugin with serious issues that very likely can't be fixed is better because it is "faster". (How do you suggest Zilmar fix Glide64's mipmapping, noise emulation, and generally completely incorrect framebuffer emulation, for example? Gonetz was right to ditch it.)

Originally Posted by RPGMaster

PJ64 isn't even my main N64 emulator, but I still acknowledge it as the objectively best overall N64 emulator.

You can acknowledge whatever you like. PJ64 is not the "best overall" emulator out of the box. It has too many serious problems that require addressing. Anyone who recommends PJ64 in its current state should be ashamed of themselves.

[RPGMaster]

Originally Posted by SuperTurboTurkeyStuffer

It's more about explaining why GLideN64 is both fast and accurate. GLideN64's obvious advantage is that it is both accurate and very fast. Moreso than Glide64, which has no meaningful performance advantages and woefully awful accuracy for every single N64 game right down to Mario 64.

That's objectively false. Glide64 still runs S2DEX games better. If you call the performance gap between Glide64 and GLideN64 "not a meaningful performance advantage", then HLE is a complete waste of time.

Originally Posted by SuperTurboTurkeyStuffer

It requires newer hardware than a Glide-based plugin? What a shock!

It shouldn't be a shocker that someone who cares about hardware compatibility would not make GLideN64 the default plugin..

Originally Posted by SuperTurboTurkeyStuffer

Also, why is it a problem that it is slower? Especially considering its performance is quite obviously fine?

Fine for you maybe. Not necessarily "fine" for everyone. Having slow HLE is pointless. Might as well use LLE and not have to deal with as many accuracy issues.

Originally Posted by SuperTurboTurkeyStuffer

Let's be clear here. GLideN64 does not have performance issues, performs objectively better than Glide64, and performance on older devices that aren't ridiculously ancient is not an issue.

It certainly does not perform "objectively" better. The only edge it has is FB read and maybe texture loading. GLideN64's sync mode performance is slower than z64gl on my desktop IGP, so that could definitely use some improvement.. Yes Glide64's FB read performance isn't great (a little slower than GLideN64's sync mode), but optimizing FB read performance shouldn't be a difficult task.

Originally Posted by SuperTurboTurkeyStuffer

I feel this is a misuse of the word "optimized". Glide64 has terrible performance and even worse accuracy.

As terrible as Glide64's performance is, it's still better than GLideN64's performance overall.

Originally Posted by SuperTurboTurkeyStuffer

Wait, you mean the absolutely terrible idea of using per-game hacks? The one that doesn't hold up to 30 seconds of thinking about potential edge cases? Proper FB notification is a feature that should be pursued, and GLideN64 supports it, but it has issues with too many games. Would be extremely useful for Pokemon Snap and Jet Force Gemini, though.

Implementing per-game FB notification is like working on HLE. It requires a lot of work, but the performance is much better when done right.

Originally Posted by SuperTurboTurkeyStuffer

What flaws? You're the one arguing that a plugin with serious issues that very likely can't be fixed is better because it is "faster". (How do you suggest Zilmar fix Glide64's mipmapping, noise emulation, and generally completely incorrect framebuffer emulation, for example? Gonetz was right to ditch it.)

Obviously the ones zilmar mentioned like the bloat. I hardly see "just port the gui to WTL" as a solution. I mean first of all, that's a no brainer and should go without saying. Second of all, GUI work might not be something he wants to do, after already doing so for Glide64. glN64 has all of those problems you mentioned . Glide64 is just a starting point.

Originally Posted by SuperTurboTurkeyStuffer

You can acknowledge whatever you like. PJ64 is not the "best overall" emulator out of the box. It has too many serious problems that require addressing. Anyone who recommends PJ64 in its current state should be ashamed of themselves.

You put far too much weight onto which plugins to pick as default. Users can choose whatever plugins they want. The exe is the most important factor. The out of the box experience for m64p is far worse. It doesn't even have a GUI for pete's sake. If you put more importance on what plugins are packaged with the emulator rather than the quality of the actual emulator, please have the decency to make that clear when advertising that "M64p > PJ64". I'm sure most people do not think what plugins are packaged with the emulator are the most important thing.

There are legitimate reasons to use M64p over PJ64, but to tell users (especially Windows users), that m64p is objectively better is just plain false. There's no good reason to spread such biased statements.

I still can't be bothered to touch that emulator. The only way to make it bearable is to use libretro.

[theboy181]

I appreciate your concerns about default plugins, but I'm worried that you just came here and post your inner hate for PJ64. I get the feeling that you have some wish list for PJ64, but you are unwilling to help contribute to to the project. I hope that you will take the time to understand the direction zilmar has chosen with his project.

My intent was to let people know who you were, and I am not upset or having a melt down. As a junior PJ64 member with such strong misconceptions of PJ's goals I think people should be aware of your turf war attitude.

I don't want to have to reflect to the sites rules, but harassment is probably on that "not tolerated here" list.

I ask that you respect the project, and that you stop trying to pass your opinions as facts.

Please continue to have passion for N64 emulation. I know that the people who care have strong opinions.

[SuperTurboTurkeyStuffer]

Originally Posted by RPGMaster

That's objectively false. Glide64 still runs S2DEX games better.

A number of S2DEX games feature custom microcodes, and the fact Glide64 doesn't exhibit worse symptoms is a good demonstration of how inaccurate it is. Then there's Nintama Rantarou Gallery 64, which is poorly coded and conflicts with a GLideN64 optimization. There's a hack that could fix it, but Gonetz doesn't fill GLideN64 with bad hacks to please people. Which is how emulators should be designed.

Originally Posted by RPGMaster

It shouldn't be a shocker that someone who cares about hardware compatibility would not make GLideN64 the default plugin.

Hardware compatibility baselines needs to be sensible. You don't pander to people with outdated hardware who refuse to upgrade at the expense of basic functionality. Let them use the old version.

Originally Posted by RPGMaster

GLideN64's sync mode performance is slower than z64gl on my desktop IGP, so that could definitely use some improvement.

GLideN64 is never going to be as fast as z64gl. z64gl is a bad plugin with bad optimizations. Accuracy has performance impacts. End of story. You're never going to create an accurate plugin that runs as fast as a bad one.

Originally Posted by RPGMaster

Yes Glide64's FB read performance isn't great (a little slower than GLideN64's sync mode), but optimizing FB read performance shouldn't be a difficult task.
As terrible as Glide64's performance is, it's still better than GLideN64's performance overall.

No, it is not. I get the feeling you have some ancient integrated GPU. As has been mentioned, the threading optimizations boost notebook iGPU performance in some titles by up to 3x in some titles.

Originally Posted by RPGMaster

Implementing per-game FB notification is like working on HLE. It requires a lot of work, but the performance is much better when done right.

There is no way to do it "right". It's a stupid idea.

Originally Posted by RPGMaster

You put far too much weight onto which plugins to pick as default. Users can choose whatever plugins they want.

This is an obnoxious attitude towards usability, and it makes the RDB a complete joke. Users have the freedom to choose whatever plugins they want. PJ64 shouldn't be defaulting intentionally to terrible plugins.

Originally Posted by RPGMaster

The out of the box experience for m64p is far worse. It doesn't even have a GUI for pete's sake.

This is incorrect. Mupen64plus doesn't have proper public releases, and their PR is complete shambles, but mupen64plus does actually include a GUI. (mupen64plus-ui-python, better known as M64Py. httpx://github.com/mupen64plus/mupen64plus-ui-python)

There are also forks like this, that include mupen64plus, a GUI, and GLideN64. Out of the box, it offers a vastly superior experience to Project 64.

httpX://m64p.github.io/

Originally Posted by RPGMaster

If you put more importance on what plugins are packaged with the emulator rather than the quality of the actual emulator, please have the decency to make that clear when advertising that "M64p > PJ64".

There's also the fact PJ64's audio is completely unacceptable "out of the box", while mupen64plus has no such issues.

Originally Posted by RPGMaster

There are legitimate reasons to use M64p over PJ64, but to tell users (especially Windows users), that m64p is objectively better is just plain false.

See above.

[RPGMaster]

Originally Posted by SuperTurboTurkeyStuffer

A number of S2DEX games feature custom microcodes, and the fact Glide64 doesn't exhibit worse symptoms is a good demonstration of how inaccurate it is. Then there's Nintama Rantarou Gallery 64, which is poorly coded and conflicts with a GLideN64 optimization.

These are strong assumptions. I have reason to believe that the difference likely stems from the fact that GLideN64 was based on glN64 (which is worse than Glide64 in both performance and accuracy). You should at least understand why I might see things differently.

I mean come on man, do you really think it's not possible that maybe Glide64 still does certain things better? It's not easy to make software that's 100% superior to another.

Originally Posted by SuperTurboTurkeyStuffer

Hardware compatibility baselines needs to be sensible. You don't pander to people with outdated hardware who refuse to upgrade at the expense of basic functionality. Let them use the old version.

Sensible is subjective. Don't expect others to agree with your idea of "sensible". I probably have higher standards than typical people (for supporting more hardware), but much of that has to do with my experience as a programmer. Seeing things get achieved that people didn't think was possible. I'm also empathetic . I don't just want my hardware to run full speed, I want people with worse hardware to also be able to enjoy N64 emulation.

Originally Posted by SuperTurboTurkeyStuffer

GLideN64 is never going to be as fast as z64gl. z64gl is a bad plugin with bad optimizations. Accuracy has performance impacts. End of story.

The FB read performance increase is not due to a hack. GLideN64's performance improvement significantly reduced the performance gap after the refactoring, yet performance gap in sync mode was still significant. I believe that z64gl's method just happens to be faster, at least on my hardware.

Another fair counter argument imo is that GLideN64 is both faster and more accurate than previous versions. Automatically defaulting to the belief that "it's only faster because it's less accurate" isn't completely valid.

I have also seen cases where fixing bugs actually led to a performance increase. It happened with WDC after I fixed a bug in the RSP recompiler.

Originally Posted by SuperTurboTurkeyStuffer

You're never going to create an accurate plugin that runs as fast as a bad one.

Yet ironically software renderers perform well for me in some games where even Glide64 struggles with, on my laptop.

Originally Posted by SuperTurboTurkeyStuffer

No, it is not. I get the feeling you have some ancient integrated GPU. As has been mentioned, the threading optimizations boost notebook iGPU performance in some titles by up to 3x in some titles.

I'm not interested in workarounds such as multi-threading. I'd strongly prefer writing efficient code, than rely on just using more jiuce. I refuse to use async, so this option wouldn't help me anyway. I don't even need threading to get full speed on my desktop. I care about people with worse hardware than me. I don't like the fact that my 6 year old laptop cannot run the plugin at all (because it doesn't support 3.x). If i waited a year, I probably would have been fine. I don't think 6 years is a sensible cutoff for an HLE plugin that is far from perfect accuracy. Had there been a D3D backend, my hardware would have been capable of doing the effects properly anyway.

Originally Posted by SuperTurboTurkeyStuffer

There is no way to do it "right". It's a stupid idea.

Ok whatever man. I'll continue enjoying better performance and accuracy than with async.

Originally Posted by SuperTurboTurkeyStuffer

This is an obnoxious attitude towards usability, and it makes the RDB a complete joke. Users have the freedom to choose whatever plugins they want. PJ64 shouldn't be defaulting intentionally to terrible plugins.

Have you done the testing to prove that Azimer's surpassed Jabo's? Tbh it's a little unfair how judgmental some people are about Project64. We really need more people giving constructive feedback. I'm sure if we can confirm Azimer's has currently surpassed Jabo's, then we would switch right away.

Originally Posted by SuperTurboTurkeyStuffer

This is incorrect. Mupen64plus doesn't have proper public releases, and their PR is complete shambles, but mupen64plus does actually include a GUI. (mupen64plus-ui-python, better known as M64Py. httpx://github.com/mupen64plus/mupen64plus-ui-python)

There are also forks like this, that include mupen64plus, a GUI, and GLideN64. Out of the box, it offers a vastly superior experience to Project 64.

httpX://m64p.github.io/

I'm aware of the forks and saw that link. it even admits there are 5 games m64p can't run, that Pj64 can. So why say m64p >= Pj64 in compatibility? The thing is, it's still not convenient since it's a fork and not the official public release. I only recently discovered that link and since I can't use GLideN64 at the moment, i can't really even test it.. I know I'm not missing out on much anyway though . I've done my research and testing to figure out how to get good results on my laptop that some folks like to refer to as a "toaster" .

Originally Posted by SuperTurboTurkeyStuffer

There's also the fact PJ64's audio is completely unacceptable "out of the box", while mupen64plus has no such issues.

Last time I tried it, the audio wasn't impressive either. I appreciate the fact that I can at least have the opportunity to enjoy more games after tweaking stuff.

All I'm saying is at least be more clear why you prefer M64p when suggesting to others.

At the end of the day, zilmar prefers to use Glide64's code as a base and I think people should respect that, just as they respected Gonetz decision to use glN64 as a base.

[LuigiBlood]

Can we talk about how mupen64plus barely has any updates to its emulation core? bsmiles32 is like the only person who knows N64 tech.

And honestly no, I still think it's worse than Project64, even 2.3. And I'm not a liar, how about you say something more meaningful than saying those people are liars?

While I can admit my lack of knowledge with 3D graphics emulation, something pains me more: why can't you take a powerful plugin like GLideN64 or even angrylion and try to add some kind of accuracy VS performance kind of thing like PCSX2? Like deliberately add hacks upon the user's choice. Via presets, for old PCs and alike.

Why isn't this talked about? Is this not viable or is this something no one has even thought about?

Originally Posted by theboy181

https://www.youtube.com/watch?v=GcjSVYAGbmk

How about releasing that optimized angrylion plugin that only like 2 people has?
And no shitty code is a extremely shit reason to not release something anymore.

[zilmar]

Originally Posted by SuperTurboTurkeyStuffer

>It is extremely bloated, the plugin is like 10mb, which is like double the rest of the emulator.

The mupen64plus version is 1.6MB. The bloat in the Zilmar spec is entirely derived from the QT-based GUI. If you wanted to streamline it, you could write your own GUI.

as you say it should be like 1.6mb, a lot of bloat there. It is a matter of priorities, yes I could fork and write my own UI for settings, I have done that already for glide64. But then I have to also mange my own fork and keep in sync which is more work, I am better off using that energy on project64-video.

Originally Posted by SuperTurboTurkeyStuffer

>The build process is horrible, after spending a couple hours trying to build I gave up. I did not want to add all the crap needed to build it to my build machine.

Considering you release public builds once in a blue moon, just get Gonetz or someone else to build it for you if it's that much trouble. Also, again, this is exclusive to the Zilmar spec version. The mupen64plus version needs freetype, Visual Studio, and nothing else.

maybe when I am close to a 2.4 release maybe I can consider that, but it does mean then I am not adopting it any time soon.

Originally Posted by SuperTurboTurkeyStuffer

>But glide64 just never worked as well for me on my computer and from other people I talked to that was the same, so I did not want to make the default usage worse.

I can't help wondering how old your PC is. Also, you are surrounded by people running hardware so ancient it can't run a plugin like z64gl. A GL2 plugin. There is a serious echo chamber problem, I'm sorry to say. You trust these people too much, and you'd been badly led astray by their "looks fine to me" attitude. Moving to Glide64 was a no-brainer... 7-10 years ago. But boo hoo, this laptop with an ancient integrated GPU and crappy Intel drivers can't run a plugin that was originally designed for Voodoo cards.

it might run full speed, i am not checking full speed, I am looking at the speed when not limited and comparison.

Originally Posted by SuperTurboTurkeyStuffer

>For the 2.4 release I do plan to have glide64 as the default (forked as Project64-video, to stop any brand confusion).

Better than nothing, but riddled with problems all the same.

I do not plan to release 2.4 until it is a lot better, what problem in particular you want solved.

Originally Posted by SuperTurboTurkeyStuffer

Because fixing PJ64's CPU emulation is gonna hit performance HARD.

I have no idea what your talking about, what do see needs fixing that would hit performance?

Originally Posted by SuperTurboTurkeyStuffer

But at the same time, you're seeking to hack your way in circles instead of seeking accurate graphics emulation because...

I again have no idea what your talking about, I tried to avoid hacks were ever possible. One of the major things I want to do with gfx is do lle so I can make it as accurate as possible with out hacks.

Originally Posted by SuperTurboTurkeyStuffer

I'd encourage you to look at ParaLLeL. The vulkan LLE graphics emulator. I honestly think it's as good as we're going to get in the near future although it's very WIP, and there's no need to reinvent the wheel here.

Not sure I will, I agree to not reinvent the wheel. Unless it is more accurate then angry lions, then I prefer to look at that.

Originally Posted by SuperTurboTurkeyStuffer

>Things like Higher system requirements as well I do not like, I can live with if I have to but I prefer to try it getting working on lower end machines (which may not be possible).

The GLideN64 team are actively working to improve performance. There is a PR currently being worked on that dramatically improves performance on older hardware, especially laptops.

Examples include Perfect Dark jumping from 58 to 163VIs on an old laptop.

Never even got to performance as reason to exclude it, the min requirements to just have it functional, the build process, the size exclude it not the performance.

Originally Posted by SuperTurboTurkeyStuffer

>The other thing with having my own fork/gfx plugin in is that I can have better integration with project64. The plugin will be designed to just work with Project64 I do not have to worry about breaking compatibility with other emulators.

You are the author of the Zilmar specs. You can change whatever you want. But you need to communicate with people. You need to formalize changes. For example, at one point you changed PJ64's cfg file location to the "Config" subfolder. Which is an okay idea, but then you never really formalized this. So all the other plugins, including GLideN64, are still using the "Plugin/GFX" folder, which you didn't think to grant write access to with the installer version of PJ64, meaning the plugin doesn't work without administrative permissions.

Nothing in the spec ever specified anything about config files. Actually the plugins are using Proect64 to handle settings. Which does store in the config folder because of windows file permissions, I make the config dir writeable by all users. I can offer suggestions how plugins could do settings, but I am not controlling how they do settings and it is not my job to tell them they have to do it a certain way.

Originally Posted by SuperTurboTurkeyStuffer

I've spoken somewhat cynically of your efforts to port PJ64 to Android. I definitely don't approve of you charging money for functionality instead of asking for donations.

That was only in for a short time on the first release, it is just asking for donations now.

Originally Posted by SuperTurboTurkeyStuffer

However, there is no reason why GLideN64 cannot become the best plugin for Android devices. The GLideN64 team have gone out of their way to support Android. When Gonetz implemented the new, accurate combiner, he left the legacy version in place for very low power devices.

There is always room for improvement, but GLideN64's performance is a lot better than naysayers who can't run plugins from over a decade ago want to paint it. As I said, you need to talk to people working on GLideN64 while also investigating it for yourself.

that could be true, It is why I did look and try to use it (tho I did give up). It does not have to have good performance tho it would be good to have. But it has to run on the general users computer. People will download it on crappy PC and expect it to work. I do the best to make that happen and people will still complain that N64 emulation sucks cause it does not work on there PC. Raising requirements does not help that.

Originally Posted by SuperTurboTurkeyStuffer

There needs to be a serious reality check here. One of the strangest beliefs among casual emulation fans is that emulators get faster over time. I see people who expect Cemu's performance to improve at a steady rate, and they see more accuracy = lower performance as a terrible problem.

This has been a problem with N64 emulation for a while now. You can't have your cake and eat it, too. Why on earth are people surprised that GLideN64 is more demanding than Glide64? It's only natural that a significantly more accurate renderer would have higher hardware requirements.

this might be true, but people do not want to generally be educated they just want it to work, they do not want to be told there computer is not good enough. The better solution is try to get it work on a better range of PC then having to educate the users.

Originally Posted by SuperTurboTurkeyStuffer

I believe it is time for a clean slate. A new Project 64 with a new hardware baseline. I don't like sounding bossy, okay? But think hard about this, please.

1: Make GLideN64 the new default plugin.

Never likely to happen unless requirements are less

Originally Posted by SuperTurboTurkeyStuffer

2: Provide Project64-Video as a convenient fallback. Remove Jabo video. Great legacy support while GLideN64 improves. Aim high. Don't aim low.

Yes all closed source plugins should be removed

Originally Posted by SuperTurboTurkeyStuffer

3: Rewrite the RDB with GLideN64 in mind. The improvement will be monumental. GLideN64 has a few issues that need addressing, but for a vast majority of games, the accuracy improvements are astounding.

I will see how much of the RDB gets re-written, but it should match the default plugins

Originally Posted by SuperTurboTurkeyStuffer

4: Replace Jabo audio with Azimer's, and get the regressions solved as soon as possible. Talk with the Azimer contributors about possibly stopgap measures.

there has been some talks about having azimers plugin there, The other one is building my own basic audio plugin. But yes all closed source plugins should be removed.

Originally Posted by SuperTurboTurkeyStuffer

5: Consider designing the desktop version of PJ64 with an automated update system where every week or so, you push out an incremental update. A prompt would show and say "Would you like to download the latest version." Why do this? Well, it'll allow for stuff like improvements to be rolled out as soon as possible, but while still allowing for testing and such. However, this design would require more bandwidth, so it's more of a general suggestion. N64 emulation is moving very rapidly. Particularly graphics emulation. Gonetz and the others have been making amazing progress. GLideN64 from two weeks ago is badly outdated already.

not against the idea, tho there would have to be two levels, one is bleeding edge as you described, stable for the more bigger releases.

I have been redoing the build bot for the new site, so I would be using that if I built that. The feature needs the new site for this to work. So getting the new site was a major step needed for this.

[Bighead]

Once upon a time I was active in the N64 emulation community. I played my first emulated N64 game (which of course happened to be SM64) on UltraHLE. I remember when it was all so new and exciting because progress was rapidly being made. Stuff was happening, PJ64 and 1964 popped up. We could finally move on from Corn and SupraHLE that played 12 games combined. The world was an amazing place to live in. Then something happened. Things slowed down. It's hard to pinpoint exactly what, but hell I'll give it a shot because I have nothing better to do right now.

Backtrack a (random #) of years ago. Try to picture a room full of geniuses, all working towards a common goal, all tucked away into their own little cubicles hard at work. You had zilmar and Jabo making an emulator with help from smiff (PJ64), schibo and Rice making an emulator (1964), Azimer making an emulator (apollo64), hacktarux making an emulator (mupen64), LaC and Lemmy making an emulator (Nemu64), MasterPhW making an emulator (True Reality), MarathonMan eventually making an emulator (cen64), among others who haven't been forgotton. You have Jabo working independently on graphics, Rice working independently on graphics, ziggy working independently on graphics, Gonetz working independently on graphics, Orkin working independently on graphics, mudlord working independently on graphics, MasterPhW working independently on graphics, angrylion working independently on graphics. And as for audio... well, hats off to Azimer for always offering the superior audio solution, and it the few cases it was not, schibo also had a good audio implementation. And major props to Iconoclast for his astounding RSP work, and LuigiBlood for his dedication to N64DD. This list leaves out a lot of people, who have all also went off and done their own things (who can ever forget shunyaun, or pokefan with ACE64 and its many incarnations). As an observer, what can possible be perceived from this? It's almost like there seems to be a sort of trend, almost like... everyone is competing with one another! Or... something?

And this trend has extended for over a decade. It's almost like anyone who knows anything about emulating a Nintendo64, wanted to do what they excel at all by themselves, or in very small teams. Things have somewhat changed since then, but a lot still seems to be the same. And for what purpose is there to do it alone other than self glorification? The notion of complete control? Being the project BOSS? It can't honestly be self improvement, because that actually entails accepting we aren't the best at everything and there is much to be learned from others. This mentality of separation still seems to stagnate. You can't help but wonder what could have been if these wizards combined their efforts from the start. We'd probably be playing Rogue Squadron and Indiana Jones in HLE at 4k resolution by now, with absolutely no fear that the N64 is being properly preserved for future generations. Impossible, maybe? Maybe not. It's now one of those "we'll never know" situations.

There has also always seemed to be this hive mind notion to support legacy hardware in the N64 scene, and put all this worry and emphasis on "speed". But, by the time any reasonable amount of progress is made, that hardware that everyone seems so hell bent on not leaving behind, is most likely dead at the point the goal will be achieved. What's considered "fast" today is tomorrows "slow". Heck my current PC isn't even considered "mid-range" anymore by today's standards, and yet I have no trouble emulating almost anything that can be emulated at full speed + graphical enhancements, including Wii-U games. How does the desire for "LLE" and "cycle accuracy" and all those fancy buzz words even exist along side these needless concerns about performance? It's almost like not only wanting the cake and eating it too, but throw in ice cream, pie, and tasty sugary fruit!

And some of the arguments here just blow my mind, it feels like I'm reading a forum from 2001. Concerns over 10MB of bloat? A 250GB+ hard drive is basically a minimum standard in even the cheapest of laptops these days. You can pick up an 8GB USB stick for under 10 bucks. It makes me wonder what audience PJ64, and this proposed PJ64-Graphics plugin is even targeted at? I imagine the majority of most people who actually care about playing games, are just going to drop the GlideN64 plugin into the plugin folder and never give anything else a second thought. I don't even understand the notion of multiple plugins anymore. Because one does something better than the other? Why not combine efforts, then one plugin does both things better. I leave it to the N64 scene to latch onto such an antiquated philosophy. I get that there is always going to be diversion, multiple projects will always exist. higan vs SNES9x, PCSX2 vs Play!, CEMU vs Decaf, Dolphin vs Ishiiruka, rpcs3 vs rpcs3, NES²°³, Retroarch vs The World. But no other collective effort towards emulating a console has been more divided than the n64 scene. You need not look further than the comments in this thread for evidence.

This whole worrying about performance thing. Let's look at it from another angle. Look at how accuracy focused Dolphin is. Look at the new Wii-U emulator CEMU. Accuracy aside, both require a beefy system to even run decent. Yet... there seems to be an audience for them. Arguably one that far exceeds the N64 emulation player base. Tons of active users with an enormous following. Heck these days I usually end up playing the more popular N64 games that were ported to virtual console on Dolphin rather than fiddle with the nightmare that n64 emulators have become (and truthfully, always have been). Because what's being demonstrated here is what has held back this scene for over 10 years: a lack of cooperation.

At the end of it all, everything will remain as it always has been. But for some reason, I felt compelled to waste over an hour typing this up for no reason at all other than I'm tired, bitchy, insomnia drunk, and shrugged when I happened upon this thread. I'm not going to join in on the debate, but I'll eagerly watch how N64 emulation plays out over the next decade (assuming, I'm still alive).