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.

[Special]

Originally Posted by zilmar

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.

Zilmar, mind sharing your computer specs? It sounds like you run an ancient stone tablet, and who are these people you've "talked too?" it's 2017, I don't think it's a good idea to support ancient devices (within reason) anything XP and below should not even be a consideration at this point, Vista too honestly, Windows 7 should be the cut off point. The old builds aren't going away so they can use those if you so choose.

[RiotFire]

Speaking as a user who uses both PJ64 (development snapshots) and development versions of GlideN64, it is my favorite plugin in terms of graphics rendering. The only problem I've had which is not really plugin related was missing polygons outside the 4:3 area in Banjo-Tooie when using the 16:9 'hack' to force it to display the sides -- but I'm sure that's just the game doing that regardless. It does tend to be more resource heavy though, but not in a way that causes problems, at least for me.

Also, I use texture packs when available (using GlideN64 to load them, and not PJ64's options panel).

For verbosity in case anyone is wondering, the games I frequently play using GlideN64 and PJ64 are Banjo-Tooie, Blast Corps, Wave Race 64, and Conker's Bad Fur Day.

I have a pretty old PC compared to what's available now. I built it in 2011. CPU is like 3 generations behind and GPU even moreso.

Intel i7-2600k
AMD Radeon HD 6970 x 2 (Partial OpenGL 4.5 support, full OpenGL 4.4, no Vulkan, no DX12 -- and AMD stopped providing driver updates about a couple years ago for this and other pre-GCN cards sadly)
32 GB of DDR3 RAM (4 x 8GB)
Windows 8.1 x86-64

Just wanted to report my experience with it.

Also, I think it's awesome news that you are focusing on LLE. Thanks for your continued efforts.

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

[oddMLan]

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

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

Secondly, why working on making an ANGLE backend for Glide64, having to deal with the glide lib and it's wrapper (certainly not made with the mind of making backends for it), when GLideN64 has already the code in place for introducing new backends? (Semi-recent code refactor) I'd bet it'd be a lot easier to make the ANGLE backend for GLideN64 (or your own fork of it). If anything, that would create LESS fragmentation since GLideN64 can directly benefit, which is not the case if you make the ANGLE backend for a plugin that has been dead for well over a decade.

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.

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.

[RPGMaster]

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.

Project64's version does technically support LLE, although it does appear to be buggier than GLideN64's.

Originally Posted by oddMLan

(Semi-recent code refactor) I'd bet it'd be a lot easier to make the ANGLE backend for GLideN64 (or your own fork of it).

I'm not so sure. Especially since zilmar is more familiar with Glide64's code-base, so it's probably easier for him to work with that.

Originally Posted by oddMLan

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

What hardware do you have? I have an Intel HD 530 and saw that GLideN64 was slower than Glide64 in almost every game I've compared. A buddy of mine with an Nvidia card essentially had the same results. This was the nail in the coffin for me.

Originally Posted by oddMLan

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.

While I do believe using DirectX would help for a lot of hardware, I also think the plugin could use more optimizations.

[LuigiBlood]

I think it'll be better to work on GLideN64 (or perhaps z64gl) instead. Just ignore the Qt part (that said I find the dependency on GlideNUI for loading settings particularly annoying). Glide64- Project64-video needs to have Glide out of the window first if you really want to use it.

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