If Glide64 looks correct then the issue is collected here. Please comment more issues here because I likely missed something. If Glide64 uses a hack it get it correct i marked it with (hack)
#859
#795
#790
#777
#768 (wontfix)
#743
#710
#682
#681
#651
#648
#633
#628
#625
#603
#570 (hack)
#555
#547
#527
#510
#495
#472
#464
#444
#418
#394
#391
#375
#369
#368 (fixed by native)
#366 (fixed by native)
#342 (wontfix)
#328
#325
#316
#305
#301
#283
#282
#280
#274
#224
#210
#173
#171
#167
#163
#161 (hack)
#159
#141
#111
#99 (hack)
#71 (hack)
#6
These seem to be the most pressing. I would maybe add https://github.com/gonetz/GLideN64/issues/325 but Glide64 only works with the E version, and the U version has FB alignment problems.
The texture scaling issues are a big one. Heaps of games have splash screens with black lines that get worse as you raise resolution. I imagine fixing one would fix them all. GLideN64 is in a fairly impressive state. It's primarily a handful of crucial bugs affecting a wide variety of games. That issue about Wave Racer, for example, is a symptom of the plugin's almost global problems with PAL games.
6 is important as well. All plugin have issue with those games.
If Glide64 is broken, too, then it doesn't count. This is a list of issues that GLideN64 suffers but Glide64 doesn't.
it is not broken, it works but certainly with a kind of hack
I added them
One problem is that GLideN64's options are too slow. Glide64's hacks are faster
Like in Toy Story 2 GLideN64 needs the expensive N64 depth compare optin just to render the laser charge bar. The z mode comare less hack in Glide64 is much faster.
Also Glide64 has the increase texrect edge hack to fix upscaling related problems like gaps and borders. GLideN64's fixed 2D fixes some of these problems but causes slowdowns again.
Like in Toy Story 2 GLideN64 needs the expensive N64 depth compare option just to render the laser charge bar. The z mode comare less hack in Glide64 is much faster.
IMO, GLideN64 should add a version of this hack so that lower spec PCs can render these games correctly. Currently, if hardware doesn't support GL4.2, there are glitches.
@gonetz you asked me to make this list but I somehow dislike this idea. Does it make sense to fix up all discrepancies with Glide64? This will also involve adding hacks from Glide64. I think that's a bad idea. As you can see this list is so huge and it will be much work. Would be better to put this work into somethig else like optimized LLE and N64 depth compare.
Would be better to surpass Glide64 instead of trying to catch up everywhere.
Not sure where your priorities are. If you want to fix up everything in this list I will leave this open. But if you agree with me I will stop looking for discrepancies and close this.
Whether HLE is a priotity for some or not, it is a project goal and this list provides great direction for that goal. Might as well keep it open.
The vague purpose of this list is to isolate the serious issues that currently prohibit GLideN64 from replacing Glide64. If GLideN64 is going to replace Glide64, it doesn't need to match Glide64 exactly, but rather be in the same vicinity.
HLE bugs that don't affect Glide64.
PAL framebuffer issues.
Depth buffer.
The buggy, slow LLE is another matter. A very important one, but it's not strictly related.
I will not work specially on LLE direction anytime soon.
There are several reasons. Most serious are:
Most of issues in the buglist are common for HLE and LLE. Framebuffer emulation, texture handling etc. I need some criteria which issue to take. Glide64 is a good reference point. If a problem is solved with Glide64 than solution exists and known. It is better to start with already solved issues, because otherwise I may just spend my time with no visible effect.
Thus, the list is very useful for me, thanks! Of course, you may stop looking for discrepancies. The list is really large, plus I need to finish other tasks I'm working on.
Why #544 is in the list? As I remember, the problem is not fixed with Glide64 as well.
@purplemarshmallow Maybe you should cross off all the "native resolution fixed" options and add (fixed by native) to the line? (Also, technically a lot of games use a hack in Glide64 to fix their black lines, so GLideN64 arguably has no obligation to fix them with similar hacks currently. If it works at native resolution, everything is in order.)
Why #544 is in the list? As I remember, the problem is not fixed with Glide64 as well
Yes my mistake Glide64 is incorrect. Most other plugins are correct like Rice Video, Jabo's D3D, z64gl I think I mixed it up somehow
Maybe you should cross off all the "native resolution fixed" options and add (fixed by native) to the line?
Ok
https://github.com/gonetz/GLideN64/issues/633 seems to be fixed now, so cross it off. Also, you might wanna rearrange them in numerical order.
This list was created to help gonetz and he can edit it if he wants
But I can also look at it from time to time and cross off some fixed bugs. Not sure what can be rearranged, I think they are in order
please add #354
please add #625
Going through all the list it seems like #859 and #651 at least can be closed no?
Yes.
I've closed #859.
This is a slight tangent, but I notice that Mario Tennis's swipe transitions seem to work without EnableCopyAuxiliaryToRDRAM now. Can anyone else confirm?

EDIT: Nevermind, it works with latest master.
@AmbientMalice Yes, Mario Tennis's swipe transitions works without EnableCopyAuxiliaryToRDRAM now. Tested with mupen64plus.
Included #173
@oddMLan Mario Tennis's swipe transitions seems to be fixed by my latest commits. My build from #885 does not include them.
Interestingly, I bisected the commits and found out that https://github.com/gonetz/GLideN64/commit/87f307c3fffc3d5d196f37319b6023bfa8cf8320 was the commit that fixed the swipe transitions in Mario Tennis.
I made that commit without link to a particular problem; I just noticed that place can cause problems and corrected it. Good to know that it was for good :)
Can't #842 and #958 be closed?
Several can be closed: #777 #710 #464 #444 #375 #305 #6
Can features be added to the list? Force bilinear filtering to all textures would be one for example.
Almost catched glide64.
Following issues can be crossed out from the list, because there are solved:
Can features be added to the list? Force bilinear filtering to all textures would be one for example.
I'd say that no force filtering is a feature of GLideN64.
What else feature of Glide64 are missing in GLideN64?
I thought it is more. I will look at the features.
to be closed?
What about #585, #315, #250, and #190?
PPL issues seems to be fixed.
Doesn鈥檛 190 work in other plugins?
Most helpful comment
to be closed?