View Single Post
  #12  
Old 7th July 2017, 08:55 PM
zilmar zilmar is offline
Core Team
Alpha Tester
Project Supporter
Administrator
 
Join Date: Jun 2005
Posts: 987
Default

Quote:
Originally Posted by oddMLan View Post
I like the tongue-in-cheek tone in the title
most of the title is a quote from a recent reddit thread

Quote:
Originally Posted by oddMLan View Post
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.

Quote:
Originally Posted by oddMLan View Post
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.

Quote:
Originally Posted by oddMLan View Post
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.


Quote:
Originally Posted by oddMLan View Post
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.

Quote:
Originally Posted by oddMLan View Post
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)
Reply With Quote