Zilmar refuses to adopt GLideN64 and he's extremely obtuse about why (here is why!)

[retroben]

I have some performance examples with GLideN64 of scaling at an excessive multiple of resolution such as 8x (albeit in a smaller 1024x768 window) that shows a type of place where it needs to be optimized.

This example can be compared to my issue post for Android rendering fullscreen at even a mere 4x multiple of resolution from the following issue post from around a year ago...

https://github.com/gonetz/GLideN64/issues/1052

Here is both at an excessive 8x multiple (just to test) of Banjo-Tooie in front of a fire torch in the Treasure Chamber's top entrance within Mayahem Temple like I did on Android.
Take note these are in Sync mode since Async runs even better now but still kinda lags so I thought Sync would be a better example.
Tests are done on "GLideN64 rev cd8783b" which is at least newer than the public release.

The first image is at a distance showing the object tested and its running pretty decently from it being 8x scaled.

https://drive.google.com/open?id=0B1...jJQN3NlTEFBQ1k

This next image below is the performance (look at GFX) when zoomed into that single fire torch.

https://drive.google.com/open?id=0B1...XhSaHB3UHlrS3M

A whopping 79% usage on GFX due to how a multiple scale of resolution impacts the performance.
Granted,this is caused specifically by blending which is done via shading.

With even the fastest settings on enabled frame buffer like disabled video card buffer copies to N64 and even with color buffer swaps using Recompiler (although without either cache setting enabled) it gets pretty slow by going a few frames below 30fps in a simple spot when zoomed into that single fire torch.
When disabling framebuffer and torturously getting back to the area,it doesn't cause any lag at all when zoomed in. (neither does legacy blending)

It probably gets much slower with the 60fps code (8007913F 0001) active.

I will likely test again with a later build of PJ64 like I should've used to begin with to be more relevant,but I was requested to post these images in particular.
Also should've got results with Async in pictures,but it was decent at a distance and only around 40% GFX usage when zoomed in,so conveniently cutting usage in half though still slowing down a little just below 30fps.

Edit: Forgot to say that it reaches almost exactly that same amount around 81% usage on Async and 84% on Sync when viewing the large section of Hailfire Peaks (Icy Side) from in front of the oil rig ledge,the most natively laggy part of the game I could find.
Making it not copy video card buffers to N64 has it at 70-77% usage.

https://drive.google.com/open?id=0B1...TRKaFpXN1pwVjQ

So,that tiiiiny single fire torch object has the same excess usage as a massive area being viewed at a great distance.

[SuperTurboTurkeyStuffer]

Originally Posted by retroben

I have some performance examples with GLideN64 of scaling at an excessive multiple of resolution such as 8x (albeit in a smaller 1024x768 window) that shows a type of place where it needs to be optimized.

Raising the internal resolution slider has a severe performance impact past around 3x, which could be caused by a few factors. Using "same as output resolution" doesn't seem to have any real performance impact, so the issue appears to be with creating a huge buffer, and then resizing it.

Originally Posted by retroben

This example can be compared to my issue post for Android rendering fullscreen at even a mere 4x multiple of resolution from the following issue post from around a year ago...

That was a blending issue, wasn't it? Android devices aren't fast enough for shader blending, which is why the legacy mode was included.

Originally Posted by retroben

So,that tiiiiny single fire torch object has the same excess usage as a massive area being viewed at a great distance.

That's normal, in a sense. You see this in modern games. If you're familiar with Prey, there is an issue where looking at grass with glass behind/before it, causes the framerate to tank. Looking at grass is more performance intensive than anything else in the game. Or flames in Yooka-Laylee wrecking the framerate on XBO. The more of the screen the alpha effect uses, the worse the framerate.

I assume performance is okay with the legacy blender? If so, it's not really a flaw, so much as a limitation of mobile hardware that has to be worked around with a less accurate blender.

[RPGMaster]

Originally Posted by Frank74

Azimer's has surpassed Jabo's since the new audio code earlier this year. It's very low latency with default settings. And doesn't drift out of time anymore.
Once the new tabbed config is working, to select backends (dx/xa2/legacy), playback device, buffer settings, output frequency, thread yielding etc. it should replace Jabo I hope.

I suppose any game that struggles bad with VI/s are better with Jabo's audio. Jabo uses a big buffer with high latency by default. And it deals with gaps a bit better, so you don't hear any "static", just silence.

I guess Azimer's should be default in 2.4 then. Thanks for the info .

Originally Posted by SuperTurboTurkeyStuffer

They need this fixed.

How should it be solved?

Originally Posted by SuperTurboTurkeyStuffer

Cen64 has a software renderer. (Angrylion's.) It should be very obvious why Cen64 quote unquote "runs" on a CPU from 2001 while GLideN64 does not run on a GPU from 2001. You do understand the limitations of PC GPU hardware, their drivers, and graphics APIs, right? You can't get the same results as a software renderer, period. It's not GLideN64's fault some people are running integrated intel GPUs with broken drivers and refuse to use Linux, where the drivers are less crappy.

Yes, it's easier to maintain backwards compatibility with software renderers, but my point is that he put in extra work to support more users and it paid off. He could have easily just done AVX2 only, and just told people to upgrade hardware. Even on Linux, my laptop doesn't support 3.x. I just missed the cutoff by about a year unfortunaetly. Meanwhile it supports D3D11, so the hardware is certainly capable. It's just not supported well by current plugins.

Originally Posted by SuperTurboTurkeyStuffer

Bear in mind DirectX won't and by nature can't be the lead API. DirectX APIs in emulators exist as a fallback, if they exist at all. DirectX has no advantages over GL and Vulkan, and has obvious disadvantages because it's Windows only. It is fortunate that GLideN64 is open to new backends, and a DX renderer would be a useful fallback, but DX is a dead end.

I've had good experiences with D3D. I would definitely give it a shot, if I decide to focus on HW rendering. I do not mind writing Windows-only code. If that somehow doesn't work out well, I guess I'd try and learn Vulkan just to see what it can do. It's nice that it's now easier for someone else to write backends for GLideN64, but I doubt anyone will. Especially not Direct3D.

[retroben]

Vulkan can achieve better performance with lower overhead which would really help GLideN64 perform better if implemented well enough.

[SuperTurboTurkeyStuffer]

Originally Posted by retroben

Vulkan can achieve better performance with lower overhead which would really help GLideN64 perform better if implemented well enough.

Agreed 100%, and furthermore it would likely lead to significant accuracy improvements because OpenGL limitations have been a problem for Gonetz.

Originally Posted by RPGMaster

How should it be solved?

Replace Jabo's audio with Azimer's plugin as soon as possible. I am inclined to think that in the case of the MORT/MusyX games, your PR was not at fault, and Jabo's audio plugin is at fault. People deserve good quality audio. N64 games deserve good quality audio. Azimer's seems like the best path, and although N64 audio is not computationally expensive, Azimer's HLE mode could be useful for low-end systems.

Originally Posted by RPGMaster

Yes, it's easier to maintain backwards compatibility with software renderers, but my point is that he put in extra work to support more users and it paid off.

As much as I love Cen64, I'm not convinced that kind of backwards compatibility was of any real benefit to the project as a whole. If anything, there's been a bit of false hope regarding how viable Cen64 will be on anything but very high end hardware. But that's a very debatable subject because there real significance of Cen64 IMO is its CPU/RSP accuracy, not its graphics emulation.

[RPGMaster]

Originally Posted by SuperTurboTurkeyStuffer

Replace Jabo's audio with Azimer's plugin as soon as possible. I am inclined to think that in the case of the MORT/MusyX games, your PR was not at fault, and Jabo's audio plugin is at fault. People deserve good quality audio. N64 games deserve good quality audio. Azimer's seems like the best path, and although N64 audio is not computationally expensive, Azimer's HLE mode could be useful for low-end systems.

I stopped using Jabo's audio for personal use, years ago. I did test Jabo's plugin sometimes and was aware of the Musyx issue. It's just that no matter how much I tried debugging, the fault pointed to Jabo's audio. I'm still puzzled as to how that happened, but I figured if anything it would encourage us to change the default audio sooner.

I do feel that higher priority should go towards ensuring good audio. I've tried to push my view in the past, but it seemed like a lot of people disagreed with me about the crackling and they seemed to feel like the audio was good where it was at. So I just kept to myself after that and would just offer advice to people who actually wanted better audio.

Part of the problem was that development on Azimer's plugin seems to be relatively slow and then there's the fact that popular opinion among PJ64's fanbase, seems to be that Jabo's is fine/good enough.

I agree with your standpoint regarding HLE audio. Not much of a performance boost, but I personally do find HLE coding to be fun . It has been a good learning experience for me. I would definitely rather polish LLE audio before starting HLE though.

Originally Posted by SuperTurboTurkeyStuffer

As much as I love Cen64, I'm not convinced that kind of backwards compatibility was of any real benefit to the project as a whole. If anything, there's been a bit of false hope regarding how viable Cen64 will be on anything but very high end hardware. But that's a very debatable subject because there real significance of Cen64 IMO is its CPU/RSP accuracy, not its graphics emulation.

If I remember correctly, Luigiblood didn't have SSE4, so he needed to run the SSE2 build in order to test CEN64 and help with 64-DD. I would have also used myself as an example, but I actually never ran CEN64 on my machine while helping him out .

Anyway, I get that low end hardware users will have more limited options. It's not like I expect pixel perfect emulation with OpenGL 1.5 or anything. I just think that there's still plenty of room for improvement for low-end hardware users. Rather than saying "forget them, they have no chance anyway", I'd rather at least attempt to make their experience better. Especially considering not everyone is playing one of those difficult games like Body Harvest or even Mario Tennis. Honestly I find it fun to challenge myself sometimes.

[the_randomizer]

Originally Posted by RPGMaster

Thanks Frank, I guess my issue with Gauntlet wasn't as bad as I remember, although the build you sent works great for it. It just worked, without me having to tweak any settings. TWINE needed the disable audiothread sleep, for the voices to work properly. I never thought doing so would make that much of a difference. That's a shame since it hogs performance.

Btw is that plugin XA2 or DS8? And I should have asked what settings work best in Top Gear.. Would like to see if it's even better than ever now.

I don't use really Jabo's anymore (haven't in a long time), so I'm wondering if Azimer's has surpassed it yet. WHat games does Jabo's work better with than Azimers? What known issues are there with Azimer's Audio?

Nah, i wasn't referring to you. You're honestly better than most of these posters I see on other sites. Your post just happened to highlight a misconception I've been seeing across the web. Some geniuses came to the brilliant conclusion that zilmar is catering to "ancient" hardware. If he really did cater to 15 year old hardware or w/e nonsense number these people pulled out of a hat, he would have made Rice Video the default plugin..

Although if zilmar really did make Rice Video the default and planned to greatly improve it, I would strongly consider donating to him .

I'd be all over Rice Video getting an update, because right now, it's jacked up with Konami games, when I tried it like five years ago, the HUD was inverted, the wall textures were messed up, Hybrid Heaven had issues. For texture mods, sure, it's good, but for general use, Glide 64 slaughters it. Glide 64 is still a good choice, I just like the GlideN64 plugin more. Just saying XD

As for sound, it's a mixed bag, I like Azimer's way better for Konami games, Jabo's sound causes micro stuttering on my end, maybe because I use Realtek Audio with XAudio2, I don't know. Azimer however, works perfectly on all my Konami games. Clay Fighter, Killer Instinct, etc.

[Wally123]

Originally Posted by magmarock64

Is GlideN64 in it's current state compatible with PJ64 can we add it ourselves?

You can definitely install it yourselves. The GlideN64 devs have provided various builds. zilmar, the reason it is 10MB in size is because a Glide wrapper is hard coded into the plugin's dynamic link library file. It does not wrap 3DFx Glide API to Direct X, it wraps it to OpenGL. Though I personally use nGlide for that, it helps to have the redundancy.

https://github.com/gonetz/GLideN64/releases

[oddMLan]

GLideN64 doesn't use the Glide API at all, in any shape or form. The actual reason it is 10MB is because of Qt, which is a very bloated GUI library. Compile the plugin without GUI and it's just 1.5MB

[Wally123]

Originally Posted by RPGMaster

Project64's version does technically support LLE, although it does appear to be buggier than GLideN64's.
I'm not so sure. Especially since zilmar is more familiar with Glide64's code-base, so it's probably easier for him to work with that.
What hardware do you have? I have an Intel HD 530 and saw that GLideN64 was slower than Glide64 in almost every game I've compared. A buddy of mine with an Nvidia card essentially had the same results. This was the nail in the coffin for me.
While I do believe using DirectX would help for a lot of hardware, I also think the plugin could use more optimizations.

IMHO, if you're using an Intel Graphics or NVIDIA Graphics chipset, OpenGL has better performance than DirectX in PJ64...If you are using an AMD graphics card or are using an AMD APU (integrated Graphics Chipset), i would highly recommend using a DirectX plugin because most of the up to date Glide wrappers primarily rely on OpenGL as the host API.