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

[Frank74]

Originally Posted by RPGMaster

This should most likely be able to get ported without issues, since it's code that runs on CPU . Maybe I will look into it at some point.

Cool, would be good.

Originally Posted by oddMLan

Glide64 doesn't even have LLE support (more time you have to spend making your own LLE backend for it), when GlideN64 has LLE support baked in already.

PJGlide (Project64-Video), does have LLE support. It's just not very good atm. Faster than Jabo's LLE though. z64gl sacrifices accuracy for speed, there are many problems with lots of games still.

Regarding speed of GLideN64 versus Glide64. Most games are faster on Glide here. Though fzurita's threaded GLideN64 is faster here than Glide with Perfect Dark. On my shitty Intel HD Graphics. It never drops below 60 VI/s even with night vision and cam spy etc. TWINE also runs great. The only game that struggles to get 60 VI/s is CBFD.

[zilmar]

Originally Posted by oddMLan

I like the tongue-in-cheek tone in the title

most of the title is a quote from a recent reddit thread

Originally Posted by oddMLan

It's fine really, we know this is your project and by there's nothing wrong with wanting tighter control over it by the reasons you explained, it's just that the decision not to go with the only actively worked on plugin WAS confusing without knowing your reasoning behind it.

I want to support it and have looked at it a few times to try to, since I seem to get criticized a lot for not using it I thought I should write why, tho I did start to write a version of this post like 3 months ago.

Originally Posted by oddMLan

I understand most of what you say but I still respectfully disagree in some points. Mainly, working with untangling Glide64, or daisy-chaining wrappers with ANGLE while at the same time still dealing with glide sounds really inefficient and unnecessarily time consuming.

The Angle branch will probably never be merged. I had hopes that running in d3d would be faster even through the wrapper would be faster (it wasn't, about the same). It was also meant to help remove the wrapper, but doing the work in the branch showed me how to get a lot of what I want with out having to use angle, so I am merging a lot of the fixes from that branch back in to the main line, some have been done like having the 3 different projects be one.

The angle branch is also useful for testing the OpengL ES code on windows, which is why it is likely to stay around, but unlikely to be merged.

Originally Posted by oddMLan

Then you say you want to mostly focus in LLE when Glide64 doesn't even have LLE support (more time you have to spend making your own LLE backend for it), when GlideN64 has LLE support baked in already. If you made a fork of GLideN64, any LLE improvemets you made on top can be easily merged upstream. Not saying you have to do this yourself, other members of the community will look at your changes and make a pull request for them, while you work on your own thing. If anything, you can benefit more from the improvements made in the official branch like HLE'd ucodes and multithreading, which you can merge to your fork with not too much effort. It's your fork, granted, you don't have to subject to their rules, you can focus on making your own thing entirely but at least you would be building upon something that's not dead and everyone can borrow a little of the other, so the benefit goes both ways.

For a while, maybe for ever, the LLE code will be in its own branch cause I am sure it will break HLE for a while. The plan was basically be writing a LLE version from scratch, referring to how other plugins have done LLE as a reference. Some of the learning from that may be merged back in to the main line to make the current version of project64-video more accurate, at some stage I might get the LLE and HLE working well together that it could be merged back in and both work together. The aim is to make the video more accurate with less hacks.

Originally Posted by oddMLan

Third, I get it, you don't like Qt, I don't either, I know how much of a pain in the arse it is to get it compiled and then properly setup. But GLideN64's code is not tied to Qt, and anyone can make a native GUI for their system if that's better suited for them (you already made a similar effort with your fork of Glide64). In the meantime, you can skip Qt and compile it without the pain by using the precompiled GLideNUI.lib I posted on the #gliden64 on the Discord group.

Yes I could, I already did that for the project64-video, it had a wx UI for configuration and I re-wrote all that in a simple WTL gui. Maybe I should just so I can include the plugin, but I guess it depends on what is more important to do.

Originally Posted by oddMLan

Fourth, I think the reasoning that has more weight to it it's the system requirement part, which is hard to deny I get that it is in your best interest to support low-end and older systems. I'm not going to tell you to stop caring about those cause I care for them as well. I think most of the compatibility problems stem from the shoddy OGL support some manufacturers have, namely, Intel chipsets. But for the systems that do comply the minimum requirements GLideN64 runs better, more accurately and even faster than Glide64 AND Jabo (I can attest to that). I think a great deal of those issues with older systems or with shoddy OGL support would be solved with a DirectX backend (which ANGLE uses for Windows), which is possible now thanks to Gonetz' refactor of GLideN64. Drivers do tend to have better DirectX than OGL support in most cases. Plus knowing GLideN64 has backend support in place and pure, untangled, non-wrapped OGL code, and Glide64 doesn't have any of that, I still don't see how Glide64 is the better option.

the way the code is being refactored the wrapper basically becomes a backend which means it is already separated with backends, having 2, ogl and ogl es. If I wanted to do I could then use Angle for that, or write a native D3D one.

Lots of complaints I see about N64 emulation being bad is often unsupported gfx card features, I fear taking up like Gliden64 as the default while it will make it better for some, maybe the majority, It will make it worse for others. There is already enough complaints that N64 emulation is really bad with out making it worse for a group of people, (a lot larger group then what is effected by using glide64 or jabo's plugin)

[zilmar]

Originally Posted by LuigiBlood

Glide64- Project64-video needs to have Glide out of the window first if you really want to use it.

All the glide code has been removed out of the angle branch, I am working to get those changes back in to the main line. So yes all reference to glide/vodoo will be removed from the source, soonish.

Originally Posted by LuigiBlood

I get the point of needing control but I think for LLE it might be even more worth it to do more on z64gl than Glide64 (Project64-video) and GLideN64, which I saw for a bit in a LLE branch, if you don't want to work on GLideN64, at least do z64gl. This has some potential to do great & fast LLE emulation. Optimize the shit out of it.

glide64 has LLE code in there already which is based on z64gl. I will not use it as a base, but I will look at how it works at try to use how it does things to help with my version.

the LLE branch was killed cause it was branched from the ANGLE branch, when I get all the key changes from the ANGLE branch in to the master, then I will recreate the LLE branch again.

Originally Posted by LuigiBlood

Make the RSP recompiler better too. Avoid HLE as soon as possible if you really want LLE to thrive, and z64gl is pretty easy to compile AFAIK

But I think my word shouldn't be taken as seriously as any other graphics programmer specialist. I don't know shit about GFX development. I don't know how to use DirectX or OpenGL, let alone Vulkan.

tl;dr: If you wanna really focus LLE, stop HLE right now, try out z64gl.

I am not sure if LLE video will ever be the default, but I would like it at least as reference, I want to have at least the option for software rending and have it as accurate as what the angry lions version is.

I will be looking at test programs, z64gl, angry lions code for directions with LLE.

[RPGMaster]

Originally Posted by LuigiBlood

Make the RSP recompiler better too.

In what way is it currently lacking? From what I've seen, most games are bottlenecked by the RDP. I only know a few games where RSP usage is heavy (such as Gauntlet, Vigilante 8, can Conker). Aside from those games, do you know any others?

Originally Posted by zilmar

The Angle branch will probably never be merged. I had hopes that running in d3d would be faster even through the wrapper would be faster (it wasn't, about the same). It was also meant to help remove the wrapper, but doing the work in the branch showed me how to get a lot of what I want with out having to use angle, so I am merging a lot of the fixes from that branch back in to the main line, some have been done like having the 3 different projects be one.

That's unfortunate to hear about the performance . Do you have any other plans/ideas for improving the performance?

Originally Posted by zilmar

The aim is to make the video more accurate with less hacks.

Great plan. I am excited for this .

Originally Posted by zilmar

Yes I could, I already did that for the project64-video, it had a wx UI for configuration and I re-wrote all that in a simple WTL gui. Maybe I should just so I can include the plugin, but I guess it depends on what is more important to do.

There are plenty of more important things to do that porting GLideN64's gui to WTL. Users can just download the WIP plugin from the GitHub repository, since it updates fairly often anyway. I would only include 1st party plugins in the installer package.

Originally Posted by zilmar

Lots of complaints I see about N64 emulation being bad is often unsupported gfx card features, I fear taking up like Gliden64 as the default while it will make it better for some, maybe the majority, It will make it worse for others.

Indeed. Ideally we should strive to make emulation better for everyone .

Originally Posted by Frank74

The only game that struggles to get 60 VI/s is CBFD.

I'm surprised. Is that game is more resource intensive than Vigilante 8, for HLE?

[Frank74]

Originally Posted by RPGMaster

I'm surprised. Is that game is more resource intensive than Vigilante 8, for HLE?

Yes, CBFD much more resource hungry. Vigilante 8 runs solid 60 VI/s here when using my Azimer build with disable audiothread sleep turned on. On GLideN64 master as well. I think Vigilante 8's speed problem is with the audio thread.
Try it with this plugin: AziAudioNEW

Disabling audiothread sleep makes the audio CPU usage higher than PJ64 and GLideN64. But even my low system specs handle it fine. Body Harvest needs it as well to stop VI's slowing, causing sync issues. Body Harvest needs Backend FPS at 95. Buffer settings don't take effect until loading a savestate or restarting ROM atm.

[SuperTurboTurkeyStuffer]

Firstly, I'm just going to repost what I posted on the reddit thread:

I appreciate Zilmar making this post. And here are my thoughts. Sorry if they seem scattered in places.

>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.

>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.

>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.

>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.

>But if I want to actually work on it and move in a completely different direction then this causes problems with doing it on someones else's project.

Zilmar, respectfully, I believe you should focus on CPU/RSP/Audio emulation and leave graphics to people like Gonetz. You've expressed a desire to improve CPU emulation. Even seek cycle accuracy. And this is fantastic. But at the same time, you're seeking to hack your way in circles instead of seeking accurate graphics emulation because... well, people with PCs predating Vista might complain. You think these people are going to be happy with you improving PJ64's CPU emulation at the cost of performance? Because fixing PJ64's CPU emulation is gonna hit performance HARD.

>My focus I want really to be on the ability for LLE, I would like to see perfect LLE video possible from the plugin, like what angrylions one does, but this I want for testing, not really for end users.

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.

>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.

>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.

Communication is key. Zilmar, I assume you're going to read this. You need to talk to Gonetz. You need to talk to people actually using GLideN64, who are in a position to comment on its performance across different hardware configurations, and potential for optimization. Because I feel you are being badly misled by people who have no interest in improving N64 emulation if that improvement means ancient hardware falls below the cutoff point.

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. 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.

--end repost.

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.

Now GLideN64 can certainly be improved, although some optimizations are off the table because they conflict with important accuracy improvements. z64gl's optimizations in particular.

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.

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

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.

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.

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.

[SuperTurboTurkeyStuffer]

Originally Posted by Frank74

The only thing that might be a problem is accurate N64 software depth buffer. Required for Body Harvest collision detection. RDB should probably say Use GLideN64 if it's not possible to fix.

GLideN64 has a more accuracy hardware depth buffer that has some serious problems, so it has essentially been mothballed. Gonetz fell back on the Glide64 software depth buffer. It's a lot faster because there's no RAM/VRAM syncing, and it's accurate enough for most purposes.

Body Harvest was fixed by a massive VI/framebuffer refactor where Gonetz completely rewrote how the plugin handles video interface emulation and calculates framebuffer sizes. This had a plethora of positive effects including fixing height calculation for PAL games, and fixing an endless list of games where buffers were written at the wrong size to RAM, resulting in graphical corruption, crashes, or odd behavior.

GLideN64 is doing a lot of things accurately/mostly accurately that Glide64 handles via broken heuristics and hacks. Resident Evil 2, for example, emulates near perfectly on GLideN64 because GLideN64 can correctly calculate buffer sizes. Glide64 can't. And I don't think it ever will, without resorting to a massive rewrite in which case the reality presents itself -- why completely rewrite this plugin? Self-education and improvement aside, why so much effort for something that will never be as good as GLideN64?

Gonetz abandoned Glide64 because it was a dead end. Even though using gln64 as a base was a dubious decision, it allowed GLideN64 to improve so many areas of accuracy. GLideN64 is more accurate than Nintendo's own VC in places.

Also, I see people talk about how Glide64 is ostensibly "faster" than GLideN64. As though we're all gonna ignore how we turned off framebuffer to RAM on pretty much every game because it was prohibitively expensive. (Perfect Dark is a mess on Glide64.) GLideN64 is the exact opposite. FB to RAM is enabled for everything, pretty much, because it's a huge accuracy improvement that doesn't destroy performance like it does on Glide64.

Originally Posted by zilmar

the way the code is being refactored the wrapper basically becomes a backend which means it is already separated with backends, having 2, ogl and ogl es. If I wanted to do I could then use Angle for that, or write a native D3D one.

Lots of complaints I see about N64 emulation being bad is often unsupported gfx card features, I fear taking up like Gliden64 as the default while it will make it better for some, maybe the majority, It will make it worse for others. There is already enough complaints that N64 emulation is really bad with out making it worse for a group of people, (a lot larger group then what is effected by using glide64 or jabo's plugin)

There will always be people complaining. You can't please everyone. Some people believe that N64 emulators shouldn't require hardware any more advanced than UltraHLE used. This is delusional, but what can you do? GLideN64 was refactored earlier this year to remove direct API use. There's nothing stopping the creation of a DX11 or Vulkan backend for the plugin.

I would argue that the negative reputation of N64 emulation stems more from pretty everything being broken on Jabo/Glide64, than from a small and vocal minority who don't see any need for N64 emulation to meaningfully improve. If you're going to really improve CPU/RSP emulation, for example -- perhaps removing the COUNT hack -- you are going to piss off these people who care more about extreme legacy hardware than basic accuracy. They'll accept any hack, no matter how dirty, before they'll accept accuracy improvements that carry a performance penalty.

[theboy181]

I want to get in on this too, but I am confused as to why anyone would have to create an alternate persona to place their views here. If you don't believe in something you should voice that opinion clearly, and with knowledge of the subjects you are trying to express towards. 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.

I agree that we live in a world where people who are into emulation will have the HW required to run GLideN64, 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.

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.

Anyway, I don't know how many times this discussion has been graced by Ambient_Malice in the past, but I don't see where the need for it to be included at this time warrants so much negative posts on /vg an reddit, ect..

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

Just so everyone is aware of my preference I use two plugins. reality, and GLideN64 when I actually play games with my friends.

The fun for me in Nintendo 64 emulation has always been seeing people poke around with what information we have, and to discover how things actually work on such a buggy system. I don't ever expect Project64 to be cycle accurate, and I am proud of that. I prefer the ability to enhance the frame-rates, and graphical limitations of the real HW anyway.

[SuperTurboTurkeyStuffer]

Originally Posted by theboy181

I want to get in on this too, but I am confused as to why anyone would have to create an alternate persona to place their views here.

Wait. Are you having a meltdown because I couldn't recover my old account? The one I haven't accessed in years and I can't even remember the exact username/email/password for? Dude, chill out.

Originally Posted by theboy181

Posting about other emulators being superior with alternate accounts to mislead people is just cringy.

What are you talking about? Mislead? What? Wait, you don't seriously believe Project 64 in its current state is superior to mupen64plus, do you? Because there is being a fan of something and then there is being a fanboy. PJ64 has been in an extremely ugly state since PJ64 2.0. To be frank, it's been completely fucked. It's in everyone's best interests for mupen64plus and Project 64 to be as good as they possibly can be. This isn't some war. This is about helping people enjoy N64 games. Emulation benefits from cooperation and information sharing. PJ64 isn't special or sacred. It's a decent N64 emulation with a great approach to usability that is currently floundering in a mire because the "out of the box" experience is so utterly horrifying. Splinter Cell: Double Agent PC port horrifying. There are forks of mupen64plus that include GLideN64, and they run basically everything out of the box. No user adjustments needed. That is the experience I want PJ64 to have. Unless PJ64 changes course or undergoes a severe retrospective overhaul, it's not an emulator that can be honestly recommended to people. Anyone who says that PJ64 2.3 is a good choice for emulating N64 games is a liar. It's a train wreck. A massive, flaming, stuttering, broken train wreck. Something has to change.

Originally Posted by theboy181

I agree that we live in a world where people who are into emulation will have the HW required to run GLideN64, 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.

It's in PJ64's interest to have an out of the box experience that isn't comprehensively broken. There has to be a hardware cutoff. There have to be minimum standards. Presenting the end user with a plugin like Jabo's or even Glide64 out of the box is an insult to N64 games and the user alike.

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.

Yes, it would. There's also something to be said for integrating Angrylion's into GLideN64.

Originally Posted by theboy181

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

Who is ridiculing him? Pointing out that superior LLE options exist already (such as parallel), and Zilmar's considerable talents are best spent elsewhere is not "ridiculing". Zilmar's is better off focusing on other areas of emulation that badly need improving.

Originally Posted by theboy181

The fun for me in Nintendo 64 emulation has always been seeing people poke around with what information we have, and to discover how things actually work on such a buggy system.

The N64 is not "buggy". N64 emulation is about playing N64 games. Documenting the hardware and software is of no concern to end users.

Originally Posted by theboy181

I don't ever expect Project64 to be cycle accurate, and I am proud of that.

You shouldn't, because the current timing situation is a nightmare. I set many of the current counter factor values, and they're just plain wrong. Something better than the current hack-based timing system is absolutely essential. It's just not good enough. There are too many hacks in place to counteract inaccuracy problems caused by sloppy timing.

Originally Posted by theboy181

I prefer the ability to enhance the frame-rates, and graphical limitations of the real HW anyway.

Emphasis on "enhance". There's nothing wrong with PJ64 supporting less precise timing modes as an option. But the current situation is completely unacceptable.

[theboy181]

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