



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. I like the tongue-in-cheek tone in the titleIt'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.