Gliden64: roadmap to catch Glide64

Created on 6 Feb 2016  路  37Comments  路  Source: gonetz/GLideN64

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)

764

#743
#710

#682
#681
#651
#648
#633
#628
#625
#603

600

585

#570 (hack)
#555
#547

#527
#510
#495
#472
#464
#444

#418
#394

#391
#375

#369
#368 (fixed by native)
#366 (fixed by native)

354

#342 (wontfix)
#328
#325
#316

315 (hack)

#305
#301

#283
#282
#280
#274

250

#224
#210

190

179 (hack)

#173
#171
#167
#163
#161 (hack)
#159

#141
#111
#99 (hack)
#71 (hack)
#6

Priority-High

Most helpful comment

to be closed?

All 37 comments

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.

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:

  • Current HW implementation of LLE triangle is buggy and it causes many annoying glitches. Who will take the task to fix it? LLE can't replace HLE without that task completed.
  • LLE speedup task will take more time than I currently have.

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.

651 still has an issue: garbage may appear in the bubble, as on the first screenshot.

This is a slight tangent, but I notice that Mario Tennis's swipe transitions seem to work without EnableCopyAuxiliaryToRDRAM now. Can anyone else confirm?

mariotennis-000

EDIT: Nevermind, it works with latest master.

173 should be as well included

@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:

71 #444 #464 #394

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.

190 most likely never will be fixed.

585 I don't have time on it. May be it is already fixed or will be fixed during works on other issues.

Doesn鈥檛 190 work in other plugins?

190 works in LLE. It may works in hle, if plugin implements software polygon's clipping and has support for N64 clipping box. It was done in Glide64, I don't know about other plugins.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

m4xw picture m4xw  路  15Comments

ImSpecial picture ImSpecial  路  10Comments

gonetz picture gonetz  路  10Comments

IceLancerSR picture IceLancerSR  路  15Comments

gonetz picture gonetz  路  14Comments