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

[zilmar]

I am a supporter of GlideN64 and like the work they are doing but I do not seeing it getting added to project64 any time soon. I know they have been making leaps and bounds accuracy-wise and yet I still am not using it and instead going with a fork of glide64. Even tho according to some Glide64 is a crumbling pile of hacks that should have been shelved a decade ago.

I did look at the option to add GLideN64 as additional option that users could use, even if was not the default. Two major reason stop me adding it as an option.

1. It is extremely bloated, the plugin is like 10mb, which is like double the rest of the emulator.
2. 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. (https://github.com/gonetz/GLideN64/w...ource-(Windows))

Now talking about the default plugin. When I first added glide64 the plan was to replace Jabos video plugin. I do not want Jabo's plugin being used, most cause it is closed source and can not be fixed.

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

the other point, why use glide64 as a base and not gliden64 (the names are so close, brand confusion). Why even have my own video plugin.

If i just focus on the emulator and leave the gfx to some one else, what I did back in the early days, leaving all the gfx to Jabo, then I could just use GLideN64 build it as part of the build step and move on. 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.

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. Forking GLideN64 and doing the work there just causes more fragmentation and does not really help. 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 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.

[RPGMaster]

Keep up the good work my man . The scene needs a variety, not some monopoly where many users get left out..

Anyway, these negative people don't listen, so don't let them discourage you .

I will gladly devote my time into help making Project64-video better. I can help with both HLE and LLE . There needs to be a good plugin with low system requirements imo.

[magmarock64]

Is GlideN64 in it's current state compatible with PJ64 can we add it ourselves?

[Frank74]

The HLE ucodes being done in GLideN64 can eventually be ported to Project64-Video anyway. A couple have already been ported. Rogue Squadron HLE coming soon, it's just been backed.

A few fixes/hacks have already been ported over, example the Winback square fix. Which apparently is doing what the ucode should be doing anyway, so it doesn't break anything else in the game.

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.

[RPGMaster]

Originally Posted by Frank74

The only thing that might be a problem is accurate N64 software depth buffer. Required for Body Harvest collision detection.

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.

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

[Wally123]

Originally Posted by magmarock64

Is GlideN64 in it's current state compatible with PJ64 can we add it ourselves?

You can definitely install it yourselves. The GlideN64 devs have provided various builds. zilmar, the reason it is 10MB in size is because a Glide wrapper is hard coded into the plugin's dynamic link library file. It does not wrap 3DFx Glide API to Direct X, it wraps it to OpenGL. Though I personally use nGlide for that, it helps to have the redundancy.

https://github.com/gonetz/GLideN64/releases

[oddMLan]

GLideN64 doesn't use the Glide API at all, in any shape or form. The actual reason it is 10MB is because of Qt, which is a very bloated GUI library. Compile the plugin without GUI and it's just 1.5MB

[Wally123]

Originally Posted by oddMLan

GLideN64 doesn't use the Glide API at all, in any shape or form. The actual reason it is 10MB is because of Qt, which is a very bloated GUI library. Compile the plugin without GUI and it's just 1.5MB

GlideN64 wraps Voodoo3 functions (Glide3x) to OpenGL. It even says so in the mission statement on Indiegogo

https://www.indiegogo.com/projects/g...phics-plugin#/

As for the "Bloated" GUI, it is far better to have everything self contained than it is to make users install all the required components of the GUI themselves. That and it makes it more compatible with the MupenPlus core for RetroArch. I do agree with zilmar that it is a tad bloated as a plugin, but as far as being able to be used in RetroArch, IMHO it is a fair price to pay for being cross platform between Mupen and Zilmar spec plugins.

[loganmc10]

Originally Posted by Wally123

GlideN64 wraps Voodoo3 functions (Glide3x) to OpenGL. It even says so in the mission statement on Indiegogo

No, it says that Glide64 used Glide3x. Trust me, GLideN64 doesn't wrap any functions, it is written directly in OpenGL.