Public Release 5 ETA?

[oddMLan]

The current public release is too old (26 months old). Since @standard-two-simplex stated that the issues with tex-cord bounds will need a signifcant rewrite (which could take quite a while), why not make 1d90610 PR5? From what I recall the nightly builds before the texture coords refactor were pretty solid and for the most part, stable and free of regressions.

For Project64 3.0 we bundled the a build from the master branch after the refactor, and there are several issues that were reported to us. There are issues with Goldeneye, Conker's Bad Fur Day, and the most glaring issue being Mario Kart 64 which looks terribad at any resolution. For PJ64 3.1 we were thinking to bundle the build before the tex-coord-bounds refactor, but I thought of asking here first for opinions.

[IronYoshi64]

Yeah I think we are definably overdue for a new Public Release. I think that is a great idea to use that for PR5. Also yeah for PJ64 3.1, it would be best to use a version that doesn't have a ton of regressions and has been tested more.

[weinerschnitzel]

I thought i recall there were some tasks to complete with the WTL UI? Would be nice to have WTL UI current with Qt if it is for a PJ64 3.1 release. I guess since the screen coords branch is already in master, adding anything missing to WTL for a release would be trickier unless the screen coord changes were moved to a separate branch or if 1d90610 was forked to add the WTL stuff.

Or am I mistaken and WTL is current?

I am a big fan of the screen coord changes. Personally, I would like the remaining issues ironed out before a new PR.

[gonetz]

why not make 1d90610 PR5

The situation is not that simple.
From the one hand, screen_coords feature closed several issues. From the other hand, it causes several new regressions, which are stoppers for the new PR.
Can we make new release without screen_coords feature? 1d90610 is not suitable for PR5, since there were several important fixes after it.
I can create release-candidate branch from 1d90610 and add these fixes to that branch. However, these fixes include corrections in software vertex clipping code, which most likely will not work without screen_coords feature. Software clipping is enabled by default and it meant to be always enabled. So, either way we can have regressions :(

I'll check latest fixes from standard-two-simplex. I'll also try to prepare release-candidate branch without screen_coords. I'm not sure which way leads to less number of issues.

Regarding WTL UI: it needs at least hotkeys support. Kim, you planned to take that task several months ago. Do you have any progress with it?

[oddMLan]

Regarding WTL UI: it needs at least hotkeys support. Kim, you planned to take that task several months ago. Do you have any progress with it?

I'm very sorry. I did make an attempt to do that when I said that almost a year ago, but it proved to be harder than I thought so I postponed it, then got busy with other stuff. I've been going through a lot of stuff irl that has drained me from all energy to work on anything other than school. All my contributions to open source projects have slowed down to a halt due to these circumstances. I asked @project64 if he was able to take the task but he's busy with other projects atm. So unfortunately there is no one available to take care of the task. At the very least it is not causing issues to users who just want to play games. Texture artists in the meantime can use the Qt version. Hopefully I can make another effort sometime before PR5 is released.

[Rosalie241]

this may be an odd suggestion but can't we make a public release without the WTL GUI? We could just not provide WTL binaries for PR5 considering it's still not up-to-date with the Qt GUI but keep it in the codebase & development builds.

[weinerschnitzel]

I dont think that will help project64, where WTL GUI is a necessity for releases, and I think they want a stable build of GlideN64 for a 3.1 release. (Since 3.0 shipped with a snapshot of GLideN64 mid accuracy updates.)

I would like to wait a few more weeks. Maybe someone can fill oddMLan's shoes to do the WTL updates. Admittedly, my life is all C# and I have had little time with C/C++ for awhile. However, I would still like to take a stab at it.

[Rosalie241]

I dont think that will help project64, where WTL GUI is a necessity for releases

I don't want to seem rude but I don't think that should be our problem, Zilmar introduced the WTL GUI and if it isn't properly maintained, I don't feel like it should hold back releases considering it's been so long since a release.

I would like to wait a few more weeks. Maybe someone can fill oddMLan's shoes to do the WTL updates.

Personally I doubt someone else (besides Zilmar & oddMLan) will maintain the WTL version when there's a cross-platform Qt version available instead.

I think WTL is a hell to work with compared to Qt, I don't see the point of having 2 GUIs anyways, it duplicates work for no good reason besides saving a few MBs from the dll, which isn't even terribly big in the first place and the ability of having a cross-platform GUI makes that more than worth it.

Admittedly, my life is all C# and I have had little time with C/C++ for awhile. However, I would still like to take a stab at it.

Good luck.

[gonetz]

his may be an odd suggestion but can't we make a public release without the WTL GUI?

I think we can. It least for me WTL is not stopper. However, there are several open regressions.

[StenApp]

GlideN64 feels a bit abandoned. I‘m hoping for a Status update.
Maybe you can use milestones that it‘s more obvious what is to be done until next release

[Felipefpl]

I think we can. It least for me WTL is not stopper. However, there are several open regressions.

Were the regressions fixed? It would be nice to finally play the new version.

[overlordchaos]

not wanna be a party pooper here, but latest 4.0 release totally broke down custom textures with pokemon stadium 1 and 2.
many many textures are duplicated. the character called mewtwo has two bellys now. mew half of the textures are missing.
and this are not custom textures per se. are the same ones dumped by the plug in, passed trough an AI that restores them at x4 the original size. the plug in is set to render internal res to x4 so there should be no issue. on previous Glide64 was not that big of an issue (one or two pokemons a bit mess up) but now several are messed up and noticeable. any way to like get a debug build that drops any error/unhandled exception to leave a log of it? original creator back like 2015 give me the dev builds and he fixed alot of stuff ingame. like VS Mewtwo stage that is flotating over the clouds of the pokemon world where stuck and he managed to fix them. now they seem ok but a bit mess up (in some cases a bit stiff)

[Uzarkis]

@gonetz - i'm also curious about this: it's more than 5 years without an official release. Is there anything preventing this to happen?