PDA

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


zilmar
7th July 2017, 05:59 AM
I am a supporter of GlideN64 and like the work they are doing but I do not seeing it getting added to project64 any time soon. I know they have been making leaps and bounds accuracy-wise and yet I still am not using it and instead going with a fork of glide64. Even tho according to some Glide64 is a crumbling pile of hacks that should have been shelved a decade ago.

I did look at the option to add GLideN64 as additional option that users could use, even if was not the default. Two major reason stop me adding it as an option.


It is extremely bloated, the plugin is like 10mb, which is like double the rest of the emulator.
The build process is horrible, after spending a couple hours trying to build I gave up. I did not want to add all the crap needed to build it to my build machine. (https://github.com/gonetz/GLideN64/wiki/Build-From-Source-(Windows))

Now talking about the default plugin. When I first added glide64 the plan was to replace Jabos video plugin. I do not want Jabo's plugin being used, most cause it is closed source and can not be fixed.

But glide64 just never worked as well for me on my computer and from other people I talked to that was the same, so I did not want to make the default usage worse. For the 2.4 release I do plan to have glide64 as the default (forked as Project64-video, to stop any brand confusion).

the other point, why use glide64 as a base and not gliden64 (the names are so close, brand confusion). Why even have my own video plugin.

If i just focus on the emulator and leave the gfx to some one else, what I did back in the early days, leaving all the gfx to Jabo, then I could just use GLideN64 build it as part of the build step and move on. But if I want to actually work on it and move in a completely different direction then this causes problems with doing it on someones else's project.

My focus I want really to be on the ability for LLE, I would like to see perfect LLE video possible from the plugin, like what angrylions one does, but this I want for testing, not really for end users. Forking GLideN64 and doing the work there just causes more fragmentation and does not really help. Things like Higher system requirements as well I do not like, I can live with if I have to but I prefer to try it getting working on lower end machines (which may not be possible). The other thing with having my own fork/gfx plugin in is that I can have better integration with project64. The plugin will be designed to just work with Project64 I do not have to worry about breaking compatibility with other emulators.

RPGMaster
7th July 2017, 07:02 AM
Keep up the good work my man :D . The scene needs a variety, not some monopoly where many users get left out..

Anyway, these negative people don't listen, so don't let them discourage you :D.

I will gladly devote my time into help making Project64-video better. I can help with both HLE and LLE :D . There needs to be a good plugin with low system requirements imo.

magmarock64
7th July 2017, 10:15 AM
Is GlideN64 in it's current state compatible with PJ64 can we add it ourselves?

Frank74
7th July 2017, 01:17 PM
The HLE ucodes being done in GLideN64 can eventually be ported to Project64-Video anyway. A couple have already been ported. Rogue Squadron HLE coming soon, it's just been backed (https://www.indiegogo.com/projects/star-wars-rogue-squadron-high-level-emulation#/).

A few fixes/hacks have already been ported over, example the Winback square fix. Which apparently is doing what the ucode should be doing anyway, so it doesn't break anything else in the game.

The only thing that might be a problem is accurate N64 software depth buffer. Required for Body Harvest collision detection. RDB should probably say Use GLideN64 if it's not possible to fix.

Special
7th July 2017, 03:01 PM
But glide64 just never worked as well for me on my computer and from other people I talked to that was the same, so I did not want to make the default usage worse.

Zilmar, mind sharing your computer specs? It sounds like you run an ancient stone tablet, and who are these people you've "talked too?" it's 2017, I don't think it's a good idea to support ancient devices (within reason) anything XP and below should not even be a consideration at this point, Vista too honestly, Windows 7 should be the cut off point. The old builds aren't going away so they can use those if you so choose.

RiotFire
7th July 2017, 05:16 PM
Speaking as a user who uses both PJ64 (development snapshots) and development versions of GlideN64, it is my favorite plugin in terms of graphics rendering. The only problem I've had which is not really plugin related was missing polygons outside the 4:3 area in Banjo-Tooie when using the 16:9 'hack' to force it to display the sides -- but I'm sure that's just the game doing that regardless. It does tend to be more resource heavy though, but not in a way that causes problems, at least for me.

Also, I use texture packs when available (using GlideN64 to load them, and not PJ64's options panel).

For verbosity in case anyone is wondering, the games I frequently play using GlideN64 and PJ64 are Banjo-Tooie, Blast Corps, Wave Race 64, and Conker's Bad Fur Day.

I have a pretty old PC compared to what's available now. I built it in 2011. CPU is like 3 generations behind and GPU even moreso.

Intel i7-2600k
AMD Radeon HD 6970 x 2 (Partial OpenGL 4.5 support, full OpenGL 4.4, no Vulkan, no DX12 -- and AMD stopped providing driver updates about a couple years ago for this and other pre-GCN cards sadly)
32 GB of DDR3 RAM (4 x 8GB)
Windows 8.1 x86-64

Just wanted to report my experience with it.

Also, I think it's awesome news that you are focusing on LLE. Thanks for your continued efforts.

RPGMaster
7th July 2017, 07:24 PM
The only thing that might be a problem is accurate N64 software depth buffer. Required for Body Harvest collision detection.This should most likely be able to get ported without issues, since it's code that runs on CPU :D . Maybe I will look into it at some point.

oddMLan
7th July 2017, 07:24 PM
I like the tongue-in-cheek tone in the title :D

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 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. 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.

Secondly, why working on making an ANGLE backend for Glide64, having to deal with the glide lib and it's wrapper (certainly not made with the mind of making backends for it), when GLideN64 has already the code in place for introducing new backends? (Semi-recent code refactor) I'd bet it'd be a lot easier to make the ANGLE backend for GLideN64 (or your own fork of it). If anything, that would create LESS fragmentation since GLideN64 can directly benefit, which is not the case if you make the ANGLE backend for a plugin that has been dead for well over a decade.

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.

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.

RPGMaster
7th July 2017, 08:01 PM
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.Project64's version does technically support LLE, although it does appear to be buggier than GLideN64's.

(Semi-recent code refactor) I'd bet it'd be a lot easier to make the ANGLE backend for GLideN64 (or your own fork of it).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.

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).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.

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.While I do believe using DirectX would help for a lot of hardware, I also think the plugin could use more optimizations.

LuigiBlood
7th July 2017, 08:10 PM
I think it'll be better to work on GLideN64 (or perhaps z64gl) instead. Just ignore the Qt part (that said I find the dependency on GlideNUI for loading settings particularly annoying). Glide64- Project64-video needs to have Glide out of the window first if you really want to use it.

I get the point of needing control but I think for LLE it might be even more worth it to do more on z64gl than Glide64 (Project64-video) and GLideN64, which I saw for a bit in a LLE branch, if you don't want to work on GLideN64, at least do z64gl. This has some potential to do great & fast LLE emulation. Optimize the shit out of it.
Make the RSP recompiler better too. Avoid HLE as soon as possible if you really want LLE to thrive, and z64gl is pretty easy to compile AFAIK

But I think my word shouldn't be taken as seriously as any other graphics programmer specialist. I don't know shit about GFX development. I don't know how to use DirectX or OpenGL, let alone Vulkan.

tl;dr: If you wanna really focus LLE, stop HLE right now, try out z64gl.

Frank74
7th July 2017, 08:24 PM
This should most likely be able to get ported without issues, since it's code that runs on CPU :D . Maybe I will look into it at some point.

Cool, would be good.

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.

PJGlide (Project64-Video), does have LLE support. It's just not very good atm. Faster than Jabo's LLE though. z64gl sacrifices accuracy for speed, there are many problems with lots of games still.

Regarding speed of GLideN64 versus Glide64. Most games are faster on Glide here. Though fzurita's threaded GLideN64 is faster here than Glide with Perfect Dark. On my shitty Intel HD Graphics. It never drops below 60 VI/s even with night vision and cam spy etc. TWINE also runs great. The only game that struggles to get 60 VI/s is CBFD.

zilmar
7th July 2017, 08:55 PM
I like the tongue-in-cheek tone in the title :D

most of the title is a quote from a recent reddit thread

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.

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.

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.


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.

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)

zilmar
7th July 2017, 09:06 PM
Glide64- Project64-video needs to have Glide out of the window first if you really want to use it.

All the glide code has been removed out of the angle branch, I am working to get those changes back in to the main line. So yes all reference to glide/vodoo will be removed from the source, soonish.

I get the point of needing control but I think for LLE it might be even more worth it to do more on z64gl than Glide64 (Project64-video) and GLideN64, which I saw for a bit in a LLE branch, if you don't want to work on GLideN64, at least do z64gl. This has some potential to do great & fast LLE emulation. Optimize the shit out of it.

glide64 has LLE code in there already which is based on z64gl. I will not use it as a base, but I will look at how it works at try to use how it does things to help with my version.

the LLE branch was killed cause it was branched from the ANGLE branch, when I get all the key changes from the ANGLE branch in to the master, then I will recreate the LLE branch again.

Make the RSP recompiler better too. Avoid HLE as soon as possible if you really want LLE to thrive, and z64gl is pretty easy to compile AFAIK

But I think my word shouldn't be taken as seriously as any other graphics programmer specialist. I don't know shit about GFX development. I don't know how to use DirectX or OpenGL, let alone Vulkan.

tl;dr: If you wanna really focus LLE, stop HLE right now, try out z64gl.

I am not sure if LLE video will ever be the default, but I would like it at least as reference, I want to have at least the option for software rending and have it as accurate as what the angry lions version is.

I will be looking at test programs, z64gl, angry lions code for directions with LLE.

RPGMaster
7th July 2017, 09:17 PM
Make the RSP recompiler better too.In what way is it currently lacking? From what I've seen, most games are bottlenecked by the RDP. I only know a few games where RSP usage is heavy (such as Gauntlet, Vigilante 8, can Conker). Aside from those games, do you know any others?

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.That's unfortunate to hear about the performance :( . Do you have any other plans/ideas for improving the performance?

The aim is to make the video more accurate with less hacks.Great plan. I am excited for this :D .

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.There are plenty of more important things to do that porting GLideN64's gui to WTL. Users can just download the WIP plugin from the GitHub repository, since it updates fairly often anyway. I would only include 1st party plugins in the installer package.

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.Indeed. Ideally we should strive to make emulation better for everyone :D .
The only game that struggles to get 60 VI/s is CBFD.I'm surprised. Is that game is more resource intensive than Vigilante 8, for HLE?

Frank74
7th July 2017, 09:48 PM
I'm surprised. Is that game is more resource intensive than Vigilante 8, for HLE?

Yes, CBFD much more resource hungry. Vigilante 8 runs solid 60 VI/s here when using my Azimer build with disable audiothread sleep turned on. On GLideN64 master as well. I think Vigilante 8's speed problem is with the audio thread.
Try it with this plugin: AziAudioNEW (https://www.dropbox.com/s/hu3iuiezz5fyujt/AziAudioNEW2.zip?dl=1)

Disabling audiothread sleep makes the audio CPU usage higher than PJ64 and GLideN64. But even my low system specs handle it fine. Body Harvest needs it as well to stop VI's slowing, causing sync issues. Body Harvest needs Backend FPS at 95. Buffer settings don't take effect until loading a savestate or restarting ROM atm.

SuperTurboTurkeyStuffer
8th July 2017, 01:28 AM
Firstly, I'm just going to repost what I posted on the reddit thread:

I appreciate Zilmar making this post. And here are my thoughts. Sorry if they seem scattered in places.

>It is extremely bloated, the plugin is like 10mb, which is like double the rest of the emulator.

The mupen64plus version is 1.6MB. The bloat in the Zilmar spec is entirely derived from the QT-based GUI. If you wanted to streamline it, you could write your own GUI.

>The build process is horrible, after spending a couple hours trying to build I gave up. I did not want to add all the crap needed to build it to my build machine.

Considering you release public builds once in a blue moon, just get Gonetz or someone else to build it for you if it's that much trouble. Also, again, this is exclusive to the Zilmar spec version. The mupen64plus version needs freetype, Visual Studio, and nothing else.

>But glide64 just never worked as well for me on my computer and from other people I talked to that was the same, so I did not want to make the default usage worse.

I can't help wondering how old your PC is. Also, you are surrounded by people running hardware so ancient it can't run a plugin like z64gl. A GL2 plugin. There is a serious echo chamber problem, I'm sorry to say. You trust these people too much, and you'd been badly led astray by their "looks fine to me" attitude. Moving to Glide64 was a no-brainer... 7-10 years ago. But boo hoo, this laptop with an ancient integrated GPU and crappy Intel drivers can't run a plugin that was originally designed for Voodoo cards.

>For the 2.4 release I do plan to have glide64 as the default (forked as Project64-video, to stop any brand confusion).

Better than nothing, but riddled with problems all the same.

>But if I want to actually work on it and move in a completely different direction then this causes problems with doing it on someones else's project.

Zilmar, respectfully, I believe you should focus on CPU/RSP/Audio emulation and leave graphics to people like Gonetz. You've expressed a desire to improve CPU emulation. Even seek cycle accuracy. And this is fantastic. But at the same time, you're seeking to hack your way in circles instead of seeking accurate graphics emulation because... well, people with PCs predating Vista might complain. You think these people are going to be happy with you improving PJ64's CPU emulation at the cost of performance? Because fixing PJ64's CPU emulation is gonna hit performance HARD.

>My focus I want really to be on the ability for LLE, I would like to see perfect LLE video possible from the plugin, like what angrylions one does, but this I want for testing, not really for end users.

I'd encourage you to look at ParaLLeL. The vulkan LLE graphics emulator. I honestly think it's as good as we're going to get in the near future although it's very WIP, and there's no need to reinvent the wheel here.

>Things like Higher system requirements as well I do not like, I can live with if I have to but I prefer to try it getting working on lower end machines (which may not be possible).

The GLideN64 team are actively working to improve performance. There is a PR currently being worked on that dramatically improves performance on older hardware, especially laptops.

Examples include Perfect Dark jumping from 58 to 163VIs on an old laptop.

>The other thing with having my own fork/gfx plugin in is that I can have better integration with project64. The plugin will be designed to just work with Project64 I do not have to worry about breaking compatibility with other emulators.

You are the author of the Zilmar specs. You can change whatever you want. But you need to communicate with people. You need to formalize changes. For example, at one point you changed PJ64's cfg file location to the "Config" subfolder. Which is an okay idea, but then you never really formalized this. So all the other plugins, including GLideN64, are still using the "Plugin/GFX" folder, which you didn't think to grant write access to with the installer version of PJ64, meaning the plugin doesn't work without administrative permissions.

Communication is key. Zilmar, I assume you're going to read this. You need to talk to Gonetz. You need to talk to people actually using GLideN64, who are in a position to comment on its performance across different hardware configurations, and potential for optimization. Because I feel you are being badly misled by people who have no interest in improving N64 emulation if that improvement means ancient hardware falls below the cutoff point.

I've spoken somewhat cynically of your efforts to port PJ64 to Android. I definitely don't approve of you charging money for functionality instead of asking for donations. However, there is no reason why GLideN64 cannot become the best plugin for Android devices. The GLideN64 team have gone out of their way to support Android. When Gonetz implemented the new, accurate combiner, he left the legacy version in place for very low power devices.

There is always room for improvement, but GLideN64's performance is a lot better than naysayers who can't run plugins from over a decade ago want to paint it. As I said, you need to talk to people working on GLideN64 while also investigating it for yourself.

--end repost.

There needs to be a serious reality check here. One of the strangest beliefs among casual emulation fans is that emulators get faster over time. I see people who expect Cemu's performance to improve at a steady rate, and they see more accuracy = lower performance as a terrible problem.

This has been a problem with N64 emulation for a while now. You can't have your cake and eat it, too. Why on earth are people surprised that GLideN64 is more demanding than Glide64? It's only natural that a significantly more accurate renderer would have higher hardware requirements.

Now GLideN64 can certainly be improved, although some optimizations are off the table because they conflict with important accuracy improvements. z64gl's optimizations in particular.

I believe it is time for a clean slate. A new Project 64 with a new hardware baseline. I don't like sounding bossy, okay? But think hard about this, please.

1: Make GLideN64 the new default plugin.

2: Provide Project64-Video as a convenient fallback. Remove Jabo video. Great legacy support while GLideN64 improves. Aim high. Don't aim low.

3: Rewrite the RDB with GLideN64 in mind. The improvement will be monumental. GLideN64 has a few issues that need addressing, but for a vast majority of games, the accuracy improvements are astounding.

4: Replace Jabo audio with Azimer's, and get the regressions solved as soon as possible. Talk with the Azimer contributors about possibly stopgap measures.

5: Consider designing the desktop version of PJ64 with an automated update system where every week or so, you push out an incremental update. A prompt would show and say "Would you like to download the latest version." Why do this? Well, it'll allow for stuff like improvements to be rolled out as soon as possible, but while still allowing for testing and such. However, this design would require more bandwidth, so it's more of a general suggestion. N64 emulation is moving very rapidly. Particularly graphics emulation. Gonetz and the others have been making amazing progress. GLideN64 from two weeks ago is badly outdated already.

SuperTurboTurkeyStuffer
8th July 2017, 01:41 AM
The only thing that might be a problem is accurate N64 software depth buffer. Required for Body Harvest collision detection. RDB should probably say Use GLideN64 if it's not possible to fix.
GLideN64 has a more accuracy hardware depth buffer that has some serious problems, so it has essentially been mothballed. Gonetz fell back on the Glide64 software depth buffer. It's a lot faster because there's no RAM/VRAM syncing, and it's accurate enough for most purposes.

Body Harvest was fixed by a massive VI/framebuffer refactor where Gonetz completely rewrote how the plugin handles video interface emulation and calculates framebuffer sizes. This had a plethora of positive effects including fixing height calculation for PAL games, and fixing an endless list of games where buffers were written at the wrong size to RAM, resulting in graphical corruption, crashes, or odd behavior.

GLideN64 is doing a lot of things accurately/mostly accurately that Glide64 handles via broken heuristics and hacks. Resident Evil 2, for example, emulates near perfectly on GLideN64 because GLideN64 can correctly calculate buffer sizes. Glide64 can't. And I don't think it ever will, without resorting to a massive rewrite in which case the reality presents itself -- why completely rewrite this plugin? Self-education and improvement aside, why so much effort for something that will never be as good as GLideN64?

Gonetz abandoned Glide64 because it was a dead end. Even though using gln64 as a base was a dubious decision, it allowed GLideN64 to improve so many areas of accuracy. GLideN64 is more accurate than Nintendo's own VC in places.

Also, I see people talk about how Glide64 is ostensibly "faster" than GLideN64. As though we're all gonna ignore how we turned off framebuffer to RAM on pretty much every game because it was prohibitively expensive. (Perfect Dark is a mess on Glide64.) GLideN64 is the exact opposite. FB to RAM is enabled for everything, pretty much, because it's a huge accuracy improvement that doesn't destroy performance like it does on Glide64.

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)
There will always be people complaining. You can't please everyone. Some people believe that N64 emulators shouldn't require hardware any more advanced than UltraHLE used. This is delusional, but what can you do? GLideN64 was refactored earlier this year to remove direct API use. There's nothing stopping the creation of a DX11 or Vulkan backend for the plugin.

I would argue that the negative reputation of N64 emulation stems more from pretty everything being broken on Jabo/Glide64, than from a small and vocal minority who don't see any need for N64 emulation to meaningfully improve. If you're going to really improve CPU/RSP emulation, for example -- perhaps removing the COUNT hack -- you are going to piss off these people who care more about extreme legacy hardware than basic accuracy. They'll accept any hack, no matter how dirty, before they'll accept accuracy improvements that carry a performance penalty.

theboy181
8th July 2017, 02:20 AM
I want to get in on this too, but I am confused as to why anyone would have to create an alternate persona to place their views here. If you don't believe in something you should voice that opinion clearly, and with knowledge of the subjects you are trying to express towards. Posting about other emulators being superior with alternate accounts to mislead people is just cringy. Be the change, you want, and make an effort to help out.

I agree that we live in a world where people who are into emulation will have the HW required to run GLideN64, however PJ's design is in the interest of just having an out of the box experience for any PJ's end user who doesn't meet the strict HW requirements for some plugins.

If I could have it my way the emulator would include Angrylion's RDP and LLE on by default. I'm sure that we all agree that if ALRDP performed on more than a handful of computers out there that this would be the best plugin to use as default.

Anyway, I don't know how many times this discussion has been graced by Ambient_Malice in the past, but I don't see where the need for it to be included at this time warrants so much negative posts on /vg an reddit, ect..

Zilmar's plan to invest time on GFX should be embraced, not ridiculed.

Just so everyone is aware of my preference I use two plugins. reality, and GLideN64 when I actually play games with my friends.

The fun for me in Nintendo 64 emulation has always been seeing people poke around with what information we have, and to discover how things actually work on such a buggy system. I don't ever expect Project64 to be cycle accurate, and I am proud of that. I prefer the ability to enhance the frame-rates, and graphical limitations of the real HW anyway.

SuperTurboTurkeyStuffer
8th July 2017, 02:46 AM
I want to get in on this too, but I am confused as to why anyone would have to create an alternate persona to place their views here.
Wait. Are you having a meltdown because I couldn't recover my old account? The one I haven't accessed in years and I can't even remember the exact username/email/password for? Dude, chill out.

Posting about other emulators being superior with alternate accounts to mislead people is just cringy.
What are you talking about? Mislead? What? Wait, you don't seriously believe Project 64 in its current state is superior to mupen64plus, do you? Because there is being a fan of something and then there is being a fanboy. PJ64 has been in an extremely ugly state since PJ64 2.0. To be frank, it's been completely fucked. It's in everyone's best interests for mupen64plus and Project 64 to be as good as they possibly can be. This isn't some war. This is about helping people enjoy N64 games. Emulation benefits from cooperation and information sharing. PJ64 isn't special or sacred. It's a decent N64 emulation with a great approach to usability that is currently floundering in a mire because the "out of the box" experience is so utterly horrifying. Splinter Cell: Double Agent PC port horrifying. There are forks of mupen64plus that include GLideN64, and they run basically everything out of the box. No user adjustments needed. That is the experience I want PJ64 to have. Unless PJ64 changes course or undergoes a severe retrospective overhaul, it's not an emulator that can be honestly recommended to people. Anyone who says that PJ64 2.3 is a good choice for emulating N64 games is a liar. It's a train wreck. A massive, flaming, stuttering, broken train wreck. Something has to change.

I agree that we live in a world where people who are into emulation will have the HW required to run GLideN64, however PJ's design is in the interest of just having an out of the box experience for any PJ's end user who doesn't meet the strict HW requirements for some plugins.
It's in PJ64's interest to have an out of the box experience that isn't comprehensively broken. There has to be a hardware cutoff. There have to be minimum standards. Presenting the end user with a plugin like Jabo's or even Glide64 out of the box is an insult to N64 games and the user alike.

If I could have it my way the emulator would include Angrylion's RDP and LLE on by default. I'm sure that we all agree that if ALRDP performed on more than a handful of computers out there that this would be the best plugin to use as default.
Yes, it would. There's also something to be said for integrating Angrylion's into GLideN64.

Zilmar's plan to invest time on GFX should be embraced, not ridiculed.
Who is ridiculing him? Pointing out that superior LLE options exist already (such as parallel), and Zilmar's considerable talents are best spent elsewhere is not "ridiculing". Zilmar's is better off focusing on other areas of emulation that badly need improving.

The fun for me in Nintendo 64 emulation has always been seeing people poke around with what information we have, and to discover how things actually work on such a buggy system.
The N64 is not "buggy". N64 emulation is about playing N64 games. Documenting the hardware and software is of no concern to end users.

I don't ever expect Project64 to be cycle accurate, and I am proud of that.
You shouldn't, because the current timing situation is a nightmare. I set many of the current counter factor values, and they're just plain wrong. Something better than the current hack-based timing system is absolutely essential. It's just not good enough. There are too many hacks in place to counteract inaccuracy problems caused by sloppy timing.

I prefer the ability to enhance the frame-rates, and graphical limitations of the real HW anyway.
Emphasis on "enhance". There's nothing wrong with PJ64 supporting less precise timing modes as an option. But the current situation is completely unacceptable.

theboy181
8th July 2017, 02:59 AM
https://www.youtube.com/watch?v=GcjSVYAGbmk

SuperTurboTurkeyStuffer
8th July 2017, 03:27 AM
If Gonetz and Olivieryuyu continue to work on reverse engineering and HLE-ing N64 video ucodes, it is arguable that LLE graphics will become redundant for general users. The sticking point is that GoldenEye and Killer Instinct require low level triangle rendering for skies and water. Glide64 and GLideN64 have a dodgy implementation copied from z64gl. That's why they can run in "LLE" mode. Fixing LLE triangle drawing is extremely low priority, but should be dealt with eventually. This would both fix GE/KI skies and allow for acceptable LLE microcode graphics emulation. There's no benefit to using LLE over an accurate HLE microcode, but the option would be nice, especially as it will be a while before every microcode is fixed.

Also, you can't just backport these HLE implementations to Glide64 and expect great results. Like, what's the point of having working dynamic lighting in Turok 3 on Glide64 when shadows and a bunch of other stuff is broken? There's just so much wrong with Glide64, and while I kinda respect anyone wanting to salvage something abandoned by both lead devs a decade apart, it's effort better put elsewhere, IMO.

RPGMaster
8th July 2017, 03:31 AM
There's no debate that GLideN64 is the most accurate HLE video plugin. It's unnecessary to try and explain all the ways in which GLideN64 is more accurate. If accuracy was the #1 criteria, I'm sure Angrylion's would be the default.

The problem with GLideN64 is that it requires relatively new hardware and has worse performance. Glide64 is more optimized overall. FB read performance will not be an issue if per-game FB notification is implemented.

What should be addressed are the flaws, not what it excels at. Being good at one thing doesn't necessarily make up for flaws. Which criteria is important, varies from person to person. I hardly see the suggestion "well go fix these problems yourself", as a real solution.

Posting about other emulators being superior with alternate accounts to mislead people is just cringy. Be the change, you want, and make an effort to help out.It's a shame some folks resort to plain false advertising to get others to use a different emulator. I wish these people kept their invalid opinions to themselves, instead of spreading FUD. PJ64 isn't even my main N64 emulator, but I still acknowledge it as the objectively best overall N64 emulator.

however PJ's design is in the interest of just having an out of the box experience for any PJ's end user who doesn't meet the strict HW requirements for some plugins.That's one of the reasons I support PJ64. I like what zilmar stands for. Much respect for that.

If I could have it my way the emulator would include Angrylion's RDP and LLE on by default. I'm sure that we all agree that if ALRDP performed on more than a handful of computers out there that this would be the best plugin to use as default.Exactly. I would do the same.

Zilmar's plan to invest time on GFX should be embraced, not ridiculed.This is so important! Graphics is the biggest issue with N64 emulation. No question. Either performance is lacking or accuracy and you have to pick your poison.

I can definitely relate to getting ridiculed / hate for trying to do something good. It sucks, but I just have to move on and go my own way. Gotta stay positive and keep movin forward!

SuperTurboTurkeyStuffer
8th July 2017, 03:43 AM
There's no debate that GLideN64 is the most accurate HLE video plugin. It's unnecessary to try and explain all the ways in which GLideN64 is more accurate. If accuracy was the #1 criteria, I'm sure Angrylion's would be the default.
It's more about explaining why GLideN64 is both fast and accurate. GLideN64's obvious advantage is that it is both accurate and very fast. Moreso than Glide64, which has no meaningful performance advantages and woefully awful accuracy for every single N64 game right down to Mario 64.

The problem with GLideN64 is that it requires relatively new hardware and has worse performance.
It requires newer hardware than a Glide-based plugin? What a shock!

Let's be clear here. GLideN64 does not have performance issues, performs objectively better than Glide64, and performance on older devices that aren't ridiculously ancient is not an issue. (Since a fix is being worked on for exactly these "I don't want to buy an actual GPU" cases.)

GLideN64 is a project that is dramatically improving on a pretty much week by week basis. Meanwhile, Glide64 has actually gotten worse since 2008 in a few areas. Texture rendering in particular. There's a serious texture corruption issue in Glide64.

Glide64 is more optimized overall.
I feel this is a misuse of the word "optimized". Glide64 has terrible performance and even worse accuracy. (Like, what's the point of running Conker slightly faster on Glide64 when the plugin can't render any of the ground textures properly?)

FB read performance will not be an issue if per-game FB notification is implemented.
Wait, you mean the absolutely terrible idea of using per-game hacks? The one that doesn't hold up to 30 seconds of thinking about potential edge cases? Proper FB notification is a feature that should be pursued, and GLideN64 supports it, but it has issues with too many games. Would be extremely useful for Pokemon Snap and Jet Force Gemini, though.

What should be addressed are the flaws, not what it excels at.
What flaws?

Being good at one thing doesn't necessarily make up for flaws.
What flaws? You're the one arguing that a plugin with serious issues that very likely can't be fixed is better because it is "faster". (How do you suggest Zilmar fix Glide64's mipmapping, noise emulation, and generally completely incorrect framebuffer emulation, for example? Gonetz was right to ditch it.)

PJ64 isn't even my main N64 emulator, but I still acknowledge it as the objectively best overall N64 emulator.
You can acknowledge whatever you like. PJ64 is not the "best overall" emulator out of the box. It has too many serious problems that require addressing. Anyone who recommends PJ64 in its current state should be ashamed of themselves.

RPGMaster
8th July 2017, 04:24 AM
It's more about explaining why GLideN64 is both fast and accurate. GLideN64's obvious advantage is that it is both accurate and very fast. Moreso than Glide64, which has no meaningful performance advantages and woefully awful accuracy for every single N64 game right down to Mario 64.That's objectively false. Glide64 still runs S2DEX games better. If you call the performance gap between Glide64 and GLideN64 "not a meaningful performance advantage", then HLE is a complete waste of time.

It requires newer hardware than a Glide-based plugin? What a shock!It shouldn't be a shocker that someone who cares about hardware compatibility would not make GLideN64 the default plugin..

Also, why is it a problem that it is slower? Especially considering its performance is quite obviously fine?Fine for you maybe. Not necessarily "fine" for everyone. Having slow HLE is pointless. Might as well use LLE and not have to deal with as many accuracy issues.

Let's be clear here. GLideN64 does not have performance issues, performs objectively better than Glide64, and performance on older devices that aren't ridiculously ancient is not an issue.It certainly does not perform "objectively" better. The only edge it has is FB read and maybe texture loading. GLideN64's sync mode performance is slower than z64gl on my desktop IGP, so that could definitely use some improvement.. Yes Glide64's FB read performance isn't great (a little slower than GLideN64's sync mode), but optimizing FB read performance shouldn't be a difficult task.

I feel this is a misuse of the word "optimized". Glide64 has terrible performance and even worse accuracy.As terrible as Glide64's performance is, it's still better than GLideN64's performance overall.

Wait, you mean the absolutely terrible idea of using per-game hacks? The one that doesn't hold up to 30 seconds of thinking about potential edge cases? Proper FB notification is a feature that should be pursued, and GLideN64 supports it, but it has issues with too many games. Would be extremely useful for Pokemon Snap and Jet Force Gemini, though.Implementing per-game FB notification is like working on HLE. It requires a lot of work, but the performance is much better when done right.

What flaws? You're the one arguing that a plugin with serious issues that very likely can't be fixed is better because it is "faster". (How do you suggest Zilmar fix Glide64's mipmapping, noise emulation, and generally completely incorrect framebuffer emulation, for example? Gonetz was right to ditch it.) Obviously the ones zilmar mentioned like the bloat. I hardly see "just port the gui to WTL" as a solution. I mean first of all, that's a no brainer and should go without saying. Second of all, GUI work might not be something he wants to do, after already doing so for Glide64. glN64 has all of those problems you mentioned :D . Glide64 is just a starting point.

You can acknowledge whatever you like. PJ64 is not the "best overall" emulator out of the box. It has too many serious problems that require addressing. Anyone who recommends PJ64 in its current state should be ashamed of themselves.You put far too much weight onto which plugins to pick as default. Users can choose whatever plugins they want. The exe is the most important factor. The out of the box experience for m64p is far worse. It doesn't even have a GUI for pete's sake. If you put more importance on what plugins are packaged with the emulator rather than the quality of the actual emulator, please have the decency to make that clear when advertising that "M64p > PJ64". I'm sure most people do not think what plugins are packaged with the emulator are the most important thing.

There are legitimate reasons to use M64p over PJ64, but to tell users (especially Windows users), that m64p is objectively better is just plain false. There's no good reason to spread such biased statements.

I still can't be bothered to touch that emulator. The only way to make it bearable is to use libretro.

theboy181
8th July 2017, 04:43 AM
I appreciate your concerns about default plugins, but I'm worried that you just came here and post your inner hate for PJ64. I get the feeling that you have some wish list for PJ64, but you are unwilling to help contribute to to the project. I hope that you will take the time to understand the direction zilmar has chosen with his project.

My intent was to let people know who you were, and I am not upset or having a melt down. As a junior PJ64 member with such strong misconceptions of PJ's goals I think people should be aware of your turf war attitude.

I don't want to have to reflect to the sites rules, but harassment is probably on that "not tolerated here" list.

I ask that you respect the project, and that you stop trying to pass your opinions as facts.

Please continue to have passion for N64 emulation. I know that the people who care have strong opinions.

SuperTurboTurkeyStuffer
8th July 2017, 04:57 AM
That's objectively false. Glide64 still runs S2DEX games better.
A number of S2DEX games feature custom microcodes, and the fact Glide64 doesn't exhibit worse symptoms is a good demonstration of how inaccurate it is. Then there's Nintama Rantarou Gallery 64, which is poorly coded and conflicts with a GLideN64 optimization. There's a hack that could fix it, but Gonetz doesn't fill GLideN64 with bad hacks to please people. Which is how emulators should be designed.

It shouldn't be a shocker that someone who cares about hardware compatibility would not make GLideN64 the default plugin.
Hardware compatibility baselines needs to be sensible. You don't pander to people with outdated hardware who refuse to upgrade at the expense of basic functionality. Let them use the old version.
GLideN64's sync mode performance is slower than z64gl on my desktop IGP, so that could definitely use some improvement.
GLideN64 is never going to be as fast as z64gl. z64gl is a bad plugin with bad optimizations. Accuracy has performance impacts. End of story. You're never going to create an accurate plugin that runs as fast as a bad one.
Yes Glide64's FB read performance isn't great (a little slower than GLideN64's sync mode), but optimizing FB read performance shouldn't be a difficult task.
As terrible as Glide64's performance is, it's still better than GLideN64's performance overall.
No, it is not. I get the feeling you have some ancient integrated GPU. As has been mentioned, the threading optimizations boost notebook iGPU performance in some titles by up to 3x in some titles.
Implementing per-game FB notification is like working on HLE. It requires a lot of work, but the performance is much better when done right.
There is no way to do it "right". It's a stupid idea.
You put far too much weight onto which plugins to pick as default. Users can choose whatever plugins they want.
This is an obnoxious attitude towards usability, and it makes the RDB a complete joke. Users have the freedom to choose whatever plugins they want. PJ64 shouldn't be defaulting intentionally to terrible plugins.

The out of the box experience for m64p is far worse. It doesn't even have a GUI for pete's sake.
This is incorrect. Mupen64plus doesn't have proper public releases, and their PR is complete shambles, but mupen64plus does actually include a GUI. (mupen64plus-ui-python, better known as M64Py. httpx://github.com/mupen64plus/mupen64plus-ui-python)

There are also forks like this, that include mupen64plus, a GUI, and GLideN64. Out of the box, it offers a vastly superior experience to Project 64.

httpX://m64p.github.io/

If you put more importance on what plugins are packaged with the emulator rather than the quality of the actual emulator, please have the decency to make that clear when advertising that "M64p > PJ64".
There's also the fact PJ64's audio is completely unacceptable "out of the box", while mupen64plus has no such issues.

There are legitimate reasons to use M64p over PJ64, but to tell users (especially Windows users), that m64p is objectively better is just plain false.
See above.

RPGMaster
8th July 2017, 09:13 AM
A number of S2DEX games feature custom microcodes, and the fact Glide64 doesn't exhibit worse symptoms is a good demonstration of how inaccurate it is. Then there's Nintama Rantarou Gallery 64, which is poorly coded and conflicts with a GLideN64 optimization.These are strong assumptions. I have reason to believe that the difference likely stems from the fact that GLideN64 was based on glN64 (which is worse than Glide64 in both performance and accuracy). You should at least understand why I might see things differently.

I mean come on man, do you really think it's not possible that maybe Glide64 still does certain things better? It's not easy to make software that's 100% superior to another.


Hardware compatibility baselines needs to be sensible. You don't pander to people with outdated hardware who refuse to upgrade at the expense of basic functionality. Let them use the old version.Sensible is subjective. Don't expect others to agree with your idea of "sensible". I probably have higher standards than typical people (for supporting more hardware), but much of that has to do with my experience as a programmer. Seeing things get achieved that people didn't think was possible. I'm also empathetic :D . I don't just want my hardware to run full speed, I want people with worse hardware to also be able to enjoy N64 emulation.

GLideN64 is never going to be as fast as z64gl. z64gl is a bad plugin with bad optimizations. Accuracy has performance impacts. End of story.The FB read performance increase is not due to a hack. GLideN64's performance improvement significantly reduced the performance gap after the refactoring, yet performance gap in sync mode was still significant. I believe that z64gl's method just happens to be faster, at least on my hardware.

Another fair counter argument imo is that GLideN64 is both faster and more accurate than previous versions. Automatically defaulting to the belief that "it's only faster because it's less accurate" isn't completely valid.

I have also seen cases where fixing bugs actually led to a performance increase. It happened with WDC after I fixed a bug in the RSP recompiler.

You're never going to create an accurate plugin that runs as fast as a bad one.Yet ironically software renderers perform well for me in some games where even Glide64 struggles with, on my laptop.

No, it is not. I get the feeling you have some ancient integrated GPU. As has been mentioned, the threading optimizations boost notebook iGPU performance in some titles by up to 3x in some titles.I'm not interested in workarounds such as multi-threading. I'd strongly prefer writing efficient code, than rely on just using more jiuce. I refuse to use async, so this option wouldn't help me anyway. I don't even need threading to get full speed on my desktop. I care about people with worse hardware than me. I don't like the fact that my 6 year old laptop cannot run the plugin at all (because it doesn't support 3.x). If i waited a year, I probably would have been fine. I don't think 6 years is a sensible cutoff for an HLE plugin that is far from perfect accuracy. Had there been a D3D backend, my hardware would have been capable of doing the effects properly anyway.

There is no way to do it "right". It's a stupid idea.Ok whatever man. I'll continue enjoying better performance and accuracy than with async.

This is an obnoxious attitude towards usability, and it makes the RDB a complete joke. Users have the freedom to choose whatever plugins they want. PJ64 shouldn't be defaulting intentionally to terrible plugins.Have you done the testing to prove that Azimer's surpassed Jabo's? Tbh it's a little unfair how judgmental some people are about Project64. We really need more people giving constructive feedback. I'm sure if we can confirm Azimer's has currently surpassed Jabo's, then we would switch right away.

This is incorrect. Mupen64plus doesn't have proper public releases, and their PR is complete shambles, but mupen64plus does actually include a GUI. (mupen64plus-ui-python, better known as M64Py. httpx://github.com/mupen64plus/mupen64plus-ui-python)

There are also forks like this, that include mupen64plus, a GUI, and GLideN64. Out of the box, it offers a vastly superior experience to Project 64.

httpX://m64p.github.io/I'm aware of the forks and saw that link. it even admits there are 5 games m64p can't run, that Pj64 can. So why say m64p >= Pj64 in compatibility? The thing is, it's still not convenient since it's a fork and not the official public release. I only recently discovered that link and since I can't use GLideN64 at the moment, i can't really even test it.. I know I'm not missing out on much anyway though :D. I've done my research and testing to figure out how to get good results on my laptop that some folks like to refer to as a "toaster" :D .


There's also the fact PJ64's audio is completely unacceptable "out of the box", while mupen64plus has no such issues.Last time I tried it, the audio wasn't impressive either. I appreciate the fact that I can at least have the opportunity to enjoy more games after tweaking stuff.

All I'm saying is at least be more clear why you prefer M64p when suggesting to others.

At the end of the day, zilmar prefers to use Glide64's code as a base and I think people should respect that, just as they respected Gonetz decision to use glN64 as a base.

LuigiBlood
8th July 2017, 10:28 AM
Can we talk about how mupen64plus barely has any updates to its emulation core? bsmiles32 is like the only person who knows N64 tech.

And honestly no, I still think it's worse than Project64, even 2.3. And I'm not a liar, how about you say something more meaningful than saying those people are liars?

While I can admit my lack of knowledge with 3D graphics emulation, something pains me more: why can't you take a powerful plugin like GLideN64 or even angrylion and try to add some kind of accuracy VS performance kind of thing like PCSX2? Like deliberately add hacks upon the user's choice. Via presets, for old PCs and alike.

Why isn't this talked about? Is this not viable or is this something no one has even thought about?

https://www.youtube.com/watch?v=GcjSVYAGbmk

How about releasing that optimized angrylion plugin that only like 2 people has?
And no shitty code is a extremely shit reason to not release something anymore.

zilmar
8th July 2017, 11:55 AM
>It is extremely bloated, the plugin is like 10mb, which is like double the rest of the emulator.

The mupen64plus version is 1.6MB. The bloat in the Zilmar spec is entirely derived from the QT-based GUI. If you wanted to streamline it, you could write your own GUI.


as you say it should be like 1.6mb, a lot of bloat there. It is a matter of priorities, yes I could fork and write my own UI for settings, I have done that already for glide64. But then I have to also mange my own fork and keep in sync which is more work, I am better off using that energy on project64-video.



>The build process is horrible, after spending a couple hours trying to build I gave up. I did not want to add all the crap needed to build it to my build machine.

Considering you release public builds once in a blue moon, just get Gonetz or someone else to build it for you if it's that much trouble. Also, again, this is exclusive to the Zilmar spec version. The mupen64plus version needs freetype, Visual Studio, and nothing else.


maybe when I am close to a 2.4 release maybe I can consider that, but it does mean then I am not adopting it any time soon.


>But glide64 just never worked as well for me on my computer and from other people I talked to that was the same, so I did not want to make the default usage worse.

I can't help wondering how old your PC is. Also, you are surrounded by people running hardware so ancient it can't run a plugin like z64gl. A GL2 plugin. There is a serious echo chamber problem, I'm sorry to say. You trust these people too much, and you'd been badly led astray by their "looks fine to me" attitude. Moving to Glide64 was a no-brainer... 7-10 years ago. But boo hoo, this laptop with an ancient integrated GPU and crappy Intel drivers can't run a plugin that was originally designed for Voodoo cards.


it might run full speed, i am not checking full speed, I am looking at the speed when not limited and comparison.



>For the 2.4 release I do plan to have glide64 as the default (forked as Project64-video, to stop any brand confusion).

Better than nothing, but riddled with problems all the same.


I do not plan to release 2.4 until it is a lot better, what problem in particular you want solved.


Because fixing PJ64's CPU emulation is gonna hit performance HARD.


I have no idea what your talking about, what do see needs fixing that would hit performance?


But at the same time, you're seeking to hack your way in circles instead of seeking accurate graphics emulation because...


I again have no idea what your talking about, I tried to avoid hacks were ever possible. One of the major things I want to do with gfx is do lle so I can make it as accurate as possible with out hacks.



I'd encourage you to look at ParaLLeL. The vulkan LLE graphics emulator. I honestly think it's as good as we're going to get in the near future although it's very WIP, and there's no need to reinvent the wheel here.


Not sure I will, I agree to not reinvent the wheel. Unless it is more accurate then angry lions, then I prefer to look at that.



>Things like Higher system requirements as well I do not like, I can live with if I have to but I prefer to try it getting working on lower end machines (which may not be possible).

The GLideN64 team are actively working to improve performance. There is a PR currently being worked on that dramatically improves performance on older hardware, especially laptops.

Examples include Perfect Dark jumping from 58 to 163VIs on an old laptop.


Never even got to performance as reason to exclude it, the min requirements to just have it functional, the build process, the size exclude it not the performance.



>The other thing with having my own fork/gfx plugin in is that I can have better integration with project64. The plugin will be designed to just work with Project64 I do not have to worry about breaking compatibility with other emulators.

You are the author of the Zilmar specs. You can change whatever you want. But you need to communicate with people. You need to formalize changes. For example, at one point you changed PJ64's cfg file location to the "Config" subfolder. Which is an okay idea, but then you never really formalized this. So all the other plugins, including GLideN64, are still using the "Plugin/GFX" folder, which you didn't think to grant write access to with the installer version of PJ64, meaning the plugin doesn't work without administrative permissions.


Nothing in the spec ever specified anything about config files. Actually the plugins are using Proect64 to handle settings. Which does store in the config folder because of windows file permissions, I make the config dir writeable by all users. I can offer suggestions how plugins could do settings, but I am not controlling how they do settings and it is not my job to tell them they have to do it a certain way.


I've spoken somewhat cynically of your efforts to port PJ64 to Android. I definitely don't approve of you charging money for functionality instead of asking for donations.

That was only in for a short time on the first release, it is just asking for donations now.


However, there is no reason why GLideN64 cannot become the best plugin for Android devices. The GLideN64 team have gone out of their way to support Android. When Gonetz implemented the new, accurate combiner, he left the legacy version in place for very low power devices.

There is always room for improvement, but GLideN64's performance is a lot better than naysayers who can't run plugins from over a decade ago want to paint it. As I said, you need to talk to people working on GLideN64 while also investigating it for yourself.


that could be true, It is why I did look and try to use it (tho I did give up). It does not have to have good performance tho it would be good to have. But it has to run on the general users computer. People will download it on crappy PC and expect it to work. I do the best to make that happen and people will still complain that N64 emulation sucks cause it does not work on there PC. Raising requirements does not help that.


There needs to be a serious reality check here. One of the strangest beliefs among casual emulation fans is that emulators get faster over time. I see people who expect Cemu's performance to improve at a steady rate, and they see more accuracy = lower performance as a terrible problem.

This has been a problem with N64 emulation for a while now. You can't have your cake and eat it, too. Why on earth are people surprised that GLideN64 is more demanding than Glide64? It's only natural that a significantly more accurate renderer would have higher hardware requirements.


this might be true, but people do not want to generally be educated they just want it to work, they do not want to be told there computer is not good enough. The better solution is try to get it work on a better range of PC then having to educate the users.


I believe it is time for a clean slate. A new Project 64 with a new hardware baseline. I don't like sounding bossy, okay? But think hard about this, please.

1: Make GLideN64 the new default plugin.

Never likely to happen unless requirements are less


2: Provide Project64-Video as a convenient fallback. Remove Jabo video. Great legacy support while GLideN64 improves. Aim high. Don't aim low.


Yes all closed source plugins should be removed


3: Rewrite the RDB with GLideN64 in mind. The improvement will be monumental. GLideN64 has a few issues that need addressing, but for a vast majority of games, the accuracy improvements are astounding.


I will see how much of the RDB gets re-written, but it should match the default plugins


4: Replace Jabo audio with Azimer's, and get the regressions solved as soon as possible. Talk with the Azimer contributors about possibly stopgap measures.


there has been some talks about having azimers plugin there, The other one is building my own basic audio plugin. But yes all closed source plugins should be removed.


5: Consider designing the desktop version of PJ64 with an automated update system where every week or so, you push out an incremental update. A prompt would show and say "Would you like to download the latest version." Why do this? Well, it'll allow for stuff like improvements to be rolled out as soon as possible, but while still allowing for testing and such. However, this design would require more bandwidth, so it's more of a general suggestion. N64 emulation is moving very rapidly. Particularly graphics emulation. Gonetz and the others have been making amazing progress. GLideN64 from two weeks ago is badly outdated already.

not against the idea, tho there would have to be two levels, one is bleeding edge as you described, stable for the more bigger releases.

I have been redoing the build bot for the new site, so I would be using that if I built that. The feature needs the new site for this to work. So getting the new site was a major step needed for this.

Bighead
8th July 2017, 04:54 PM
Once upon a time I was active in the N64 emulation community. I played my first emulated N64 game (which of course happened to be SM64) on UltraHLE. I remember when it was all so new and exciting because progress was rapidly being made. Stuff was happening, PJ64 and 1964 popped up. We could finally move on from Corn and SupraHLE that played 12 games combined. The world was an amazing place to live in. Then something happened. Things slowed down. It's hard to pinpoint exactly what, but hell I'll give it a shot because I have nothing better to do right now.

Backtrack a (random #) of years ago. Try to picture a room full of geniuses, all working towards a common goal, all tucked away into their own little cubicles hard at work. You had zilmar and Jabo making an emulator with help from smiff (PJ64), schibo and Rice making an emulator (1964), Azimer making an emulator (apollo64), hacktarux making an emulator (mupen64), LaC and Lemmy making an emulator (Nemu64), MasterPhW making an emulator (True Reality), MarathonMan eventually making an emulator (cen64), among others who haven't been forgotton. You have Jabo working independently on graphics, Rice working independently on graphics, ziggy working independently on graphics, Gonetz working independently on graphics, Orkin working independently on graphics, mudlord working independently on graphics, MasterPhW working independently on graphics, angrylion working independently on graphics. And as for audio... well, hats off to Azimer for always offering the superior audio solution, and it the few cases it was not, schibo also had a good audio implementation. And major props to Iconoclast for his astounding RSP work, and LuigiBlood for his dedication to N64DD. This list leaves out a lot of people, who have all also went off and done their own things (who can ever forget shunyaun, or pokefan with ACE64 and its many incarnations). As an observer, what can possible be perceived from this? It's almost like there seems to be a sort of trend, almost like... everyone is competing with one another! Or... something?

And this trend has extended for over a decade. It's almost like anyone who knows anything about emulating a Nintendo64, wanted to do what they excel at all by themselves, or in very small teams. Things have somewhat changed since then, but a lot still seems to be the same. And for what purpose is there to do it alone other than self glorification? The notion of complete control? Being the project BOSS? It can't honestly be self improvement, because that actually entails accepting we aren't the best at everything and there is much to be learned from others. This mentality of separation still seems to stagnate. You can't help but wonder what could have been if these wizards combined their efforts from the start. We'd probably be playing Rogue Squadron and Indiana Jones in HLE at 4k resolution by now, with absolutely no fear that the N64 is being properly preserved for future generations. Impossible, maybe? Maybe not. It's now one of those "we'll never know" situations.

There has also always seemed to be this hive mind notion to support legacy hardware in the N64 scene, and put all this worry and emphasis on "speed". But, by the time any reasonable amount of progress is made, that hardware that everyone seems so hell bent on not leaving behind, is most likely dead at the point the goal will be achieved. What's considered "fast" today is tomorrows "slow". Heck my current PC isn't even considered "mid-range" anymore by today's standards, and yet I have no trouble emulating almost anything that can be emulated at full speed + graphical enhancements, including Wii-U games. How does the desire for "LLE" and "cycle accuracy" and all those fancy buzz words even exist along side these needless concerns about performance? It's almost like not only wanting the cake and eating it too, but throw in ice cream, pie, and tasty sugary fruit!

And some of the arguments here just blow my mind, it feels like I'm reading a forum from 2001. Concerns over 10MB of bloat? A 250GB+ hard drive is basically a minimum standard in even the cheapest of laptops these days. You can pick up an 8GB USB stick for under 10 bucks. It makes me wonder what audience PJ64, and this proposed PJ64-Graphics plugin is even targeted at? I imagine the majority of most people who actually care about playing games, are just going to drop the GlideN64 plugin into the plugin folder and never give anything else a second thought. I don't even understand the notion of multiple plugins anymore. Because one does something better than the other? Why not combine efforts, then one plugin does both things better. I leave it to the N64 scene to latch onto such an antiquated philosophy. I get that there is always going to be diversion, multiple projects will always exist. higan vs SNES9x, PCSX2 vs Play!, CEMU vs Decaf, Dolphin vs Ishiiruka, rpcs3 vs rpcs3, NES²°³, Retroarch vs The World. But no other collective effort towards emulating a console has been more divided than the n64 scene. You need not look further than the comments in this thread for evidence.

This whole worrying about performance thing. Let's look at it from another angle. Look at how accuracy focused Dolphin is. Look at the new Wii-U emulator CEMU. Accuracy aside, both require a beefy system to even run decent. Yet... there seems to be an audience for them. Arguably one that far exceeds the N64 emulation player base. Tons of active users with an enormous following. Heck these days I usually end up playing the more popular N64 games that were ported to virtual console on Dolphin rather than fiddle with the nightmare that n64 emulators have become (and truthfully, always have been). Because what's being demonstrated here is what has held back this scene for over 10 years: a lack of cooperation.

At the end of it all, everything will remain as it always has been. But for some reason, I felt compelled to waste over an hour typing this up for no reason at all other than I'm tired, bitchy, insomnia drunk, and shrugged when I happened upon this thread. I'm not going to join in on the debate, but I'll eagerly watch how N64 emulation plays out over the next decade (assuming, I'm still alive).

Frank74
8th July 2017, 04:58 PM
@ the turkey arse stuffer.

The official Mupen64Plus repo runs like shit compared to PJ64 here. Especially the audio. Every game I tried crackles like hell.

I had to get logan's version of it to get anything remotely acceptable. Still no where near as good as PJ64 2.4. Audio is terrible. Speed is terrible.

GLideN64 works better in PJ64 than Mupen64Plus here.

Mupen 0.51 is better than plus. Your talking in a troll shit language style.

Yes, I was the person reporting and supporting fzurita's GLideN64 threaded plugin. I posted the performance increase in Perfect Dark from 50-70 to 160+ VI/s with frame limiter off. But that is to do with the fact that Intel drivers don't support threading. Other drivers do, and will see no benefit from fzurita's opengl threaded plugin.

retroben
8th July 2017, 06:27 PM
I agree with Luigiblood about the choice of a hacks mode,but specifically with GLideN64 for creating a faster modern blending mode with no lost visuals that either matches or more hopefully out-performs legacy blending without having legacy's visual bugs or modern's resolution performance hampering which mainly happens with close-up/excessive visual effects rendering such as zooming into a torch on Banjo-Tooie from inside the top entrance of Chief Bloatazin's Mayahem Temple Treasury.

The end goal should be to use less CPU/GPU while keeping as much accuracy as needed.

Nvidia for me has a huge impact on CPU performance (best exhibited in BizHawk's Mupen) for some reason on slightly higher resolutions,so maybe threading would hugely help combat that issue.

Android's Mupen64Plus FZ Edition and Libretro's multi-platform LLE solution are the most robust versions of Mupen right now and do a great job,former being the currently most well-equipped standalone N64 emu for Android.

I do say that newer PJ versions leave a lot to be desired compared to older versions,certain games running/not running excluded.
One is the memory tools closing when loading a savestate,another is the crashes caused by closing said memory tools,and most recently,finding out that Glide64 Final 2012 appears to no longer work,which is unfortunate since the PJ version of Glide,Project64-video has those texture rendering issues that I really hope can be fixed soon.

Still hoping for a working real-time ASM value mod refreshing solution for Recompiler so more codes can work with button activators and without savestate scumming or resorting to using Interpreter which makes some of the more fun corruption codes or even simple mod codes freeze like object/action/etc. swaps.

RPGMaster
8th July 2017, 07:01 PM
One big problem with this scene is that a lot of people just contribute to negativity. A lot of people criticize others without even giving advice. Also a lot of people ignore other people's (which hinders progress).
Can we talk about how mupen64plus barely has any updates to its emulation core? bsmiles32 is like the only person who knows N64 tech.Just backports and minor tweaks.

And honestly no, I still think it's worse than Project64, even 2.3. And I'm not a liar, how about you say something more meaningful than saying those people are liars?I don't know what his deal is tbh. SOme of the negative things he said about people, apply to him.

Why isn't this talked about? Is this not viable or is this something no one has even thought about?Well there is that z64gl fork and also ParaLLEl. I try to bring up hacks and often get shot down by others :( . So I say to myself "why bother anymore?" I still share ideas though, regardless of what others might think.

If Gonetz is interested in HW framebuffer, then I'd be more interested in supporting GLideN64 :D .


As an observer, what can possible be perceived from this? It's almost like there seems to be a sort of trend, almost like... everyone is competing with one another! Or... something?It's not competition because they have different goals. You have a point though. More cooperation would have benefited the scene. Honestly, what can you do if other developers do not wish to work together? I've tried talking about this issue with others and they either agreed with me, or told me I should just suck it up, no matter how I'm treated (as if I've never done that before :D ). Do you have any advice on that?


And this trend has extended for over a decade. It's almost like anyone who knows anything about emulating a Nintendo64, wanted to do what they excel at all by themselves, or in very small teams.
Teamwork isn't easy pal. SOme devs have been great (zilmar, MM, Angrylion, Squarepusher, etc) and I don't have a hard time collaborating with these people. Sometimes we'll have different end goals, but we can still work together on the common ones.
People seem to think it's somehow natural to be able to work with literally anybody. If it's that simple, please give advice to make it easier for others :) . I'm all ears.


There has also always seemed to be this hive mind notion to support legacy hardware in the N64 scene, and put all this worry and emphasis on "speed".
I don't see how that's a "hive mind notion". N64 is 20 years old. It does not require as much resources as newer systems to emulate. NOthing wrong with trying to support older hardware imo. If they want to do the extra work, why fault them for it? If performance isn't an issue, then Angrylion's should be the default.
@ the turkey arse stuffer.

The official Mupen64Plus repo runs like shit compared to PJ64 here. Especially the audio. Every game I tried crackles like hell.

I had to get logan's version of it to get anything remotely acceptable. Still no where near as good as PJ64 2.4. Audio is terrible. Speed is terrible.I didn't have a good experience with m64p either. Especially out of the box (aka no gui). The performance is definitely not good.

loganmc10
8th July 2017, 07:27 PM
I'd just like to clarify that the emulator at m64p.github.io isn't a fork of mupen64plus.

mupen64plus is designed to be an API. m64p.github.io is just upstream mupen64plus, except that I wrote a GUI for it and an audio plugin.

Also, I don't know what kind of toasters you guys use. I see a few complaints about performance. I have a 5 year old laptop with integrated graphics and every game I play runs at 60 VI/S (with mupen64plus and GLideN64). The only time there are slowdowns is if I use LLE graphics. My laptop runs Linux though, so it doesn't have some anti-virus and 100 other processes slowing it down I suppose :P

theboy181
8th July 2017, 11:27 PM
I have a quick question, about this thread. Does anyone even know if Gonetz would want his plugin included with this so called POS emulator?

I'm confused about what is happening with zilmar's project lately. I get the impression that we all feel entitled to its direction, but I don't see anyone here that makes significant contributions, in the shape of code, or time. Making a fuss about PROJECT 64 and the direction its headed, seems like first world problems to me.

We live in a time where the N64 has already had its day, and the fact that some of the talent from that day are still interested in making their emulator pleases me.

Are the ideas represented by our posts a suggestion of a team of developers working towards a single goal on a new project? There seems to be an opportunity there. I don't see how getting AAE is going to make PJ64 better.

I don't get why we underestimate the fact that there is only a handful of active developers left, and we shouldn't demand that they cater to the mindsets of our own personal wishlist's.

I find it kinda flattering that zilmar takes the time to voice his direction, and I hope that he continues to keep things going so that others can look back on Git, and on the forums then learn from the history it has left in its legacy.

I try not to read what the haters say about me personally, but when it comes to talking shit about this project, I will do what I can. I will never get tired of being a supporter, I hope more of us stand forth, and embrace others to contribute too.

SuperTurboTurkeyStuffer
9th July 2017, 12:32 AM
Yet ironically software renderers perform well for me in some games where even Glide64 struggles with, on my laptop.
You keep blaming GLideN64 for your notebook's shortcomings. That Intel iGPUs -- or at least their Windows drivers -- suck is neither ironic nor surprising. You're also better off with Linux and MESA with one of those GPUs, since the Intel drivers tend to have sucky GL compatibility.

I'm not interested in workarounds such as multi-threading.
You're saying that GLideN64 shouldn't code workarounds for people who refuse to buy "an actual GPU" as some smugly put it?

I don't like the fact that my 6 year old laptop cannot run the plugin at all (because it doesn't support 3.x).
There has to be some kind of cutoff. Certain API features are absolutely necessary because the N64 works completely differently to a PC, and shader-based tricks are needed to work around that. Mipmapping, for example.

Had there been a D3D backend, my hardware would have been capable of doing the effects properly anyway.
GLideN64 was refactored to be API-agnostic, but DX might not be able to match GL functionality. Vulkan probably could, though. Gonetz put a lot of work into making it possible for someone to write a new backend if they want.

Have you done the testing to prove that Azimer's surpassed Jabo's?
Azimer's isn't ready. It's not that simple. Does it work "better"? Yes. But is it "ready"? No.

I'm aware of the forks and saw that link. it even admits there are 5 games m64p can't run, that Pj64 can. So why say m64p >= Pj64 in compatibility?

Have you tried playing The World is Not Enough on Project 64 recently? Or Resident Evil 2? Or Tarzan? Or Rogue Squadron? Or Battle for Naboo? Or Indiana Jones? Or San Francisco Rush 2049? Because there audio is a stuttering mess. I do faintly recall this to be your fault somehow, but my memory is fuzzy. And there are other games with issues that mupen64plus doesn't have.

Or how about the fact FAT is being used to fix timing, crackling, and crashes, but it breaks RNG?


All I'm saying is at least be more clear why you prefer M64p when suggesting to others.
The short version is "mupen64plus isn't inexplicably worse than PJ64 1.6"

it might run full speed, i am not checking full speed, I am looking at the speed when not limited and comparison.
Just as an example, Turok 3 runs at 8-10x full speed with the frame limiter off on a Haswell i5.

I have no idea what your talking about, what do see needs fixing that would hit performance?
The counter factor hack has resulted in pretty much every N64 game running "wrong". I'm pretty confident that replacing this with an accurate solution would impact performance.

I again have no idea what your talking about, I tried to avoid hacks were ever possible. One of the major things I want to do with gfx is do lle so I can make it as accurate as possible with out hacks.
You've floated the idea of using per-game framebuffer hacks, similar to what Jabo did for his plugin. Respectfully, that's a terrible idea. There are too many edge cases, and it's the wrong approach IMHO.

Nothing in the spec ever specified anything about config files. Actually the plugins are using Proect64 to handle settings. Which does store in the config folder because of windows file permissions, I make the config dir writeable by all users. I can offer suggestions how plugins could do settings, but I am not controlling how they do settings and it is not my job to tell them they have to do it a certain way.
IMO, as the namesake of the Zilmar spec, you should define strong recommendations for stuff like this, so that people are on the same page.


That was only in for a short time on the first release, it is just asking for donations now.
Very pleased to hear that. Kudos to you.

But it has to run on the general users computer. People will download it on crappy PC and expect it to work. I do the best to make that happen and people will still complain that N64 emulation sucks cause it does not work on there PC. Raising requirements does not help that.
IMO, you should aim high, not low. It's better that a small minority of users have to go into the options that switch to Project64-Video than for everyone to be stuck with extremely poor graphics emulation unless they manually download the third party plugin.

The better solution is try to get it work on a better range of PC then having to educate the users. Never likely to happen unless requirements are less.
But what are these minimum requirements? I feel you have to set a baseline somewhere. Otherwise GLideN64 will never be good enough because, like, it doesn't work on a Riva TNT2 or something.

there has been some talks about having azimers plugin there, The other one is building my own basic audio plugin. But yes all closed source plugins should be removed.
Considering that PJ64 is based around LLE audio, perhaps writing your own audio plugin would be better. Most of Azimer's features are HLE-oriented, and not hugely useful for PJ64.

The official Mupen64Plus repo runs like shit compared to PJ64 here. Especially the audio. Every game I tried crackles like hell.
As I said earlier, have you tried playing RE2 on PJ64 recently?

I had to get logan's version of it to get anything remotely acceptable. Still no where near as good as PJ64 2.4. Audio is terrible. Speed is terrible.
I can only think that you have a very, very slow CPU that can't handle the relatively unoptimized RSP interpreter. You're essentially saying the audio is bad because your PC isn't fast enough?

Mupen 0.51 is better than plus.
This is true in one area, at least. Mupen64plus broke framebuffer notification. Mupen64 is the only emulator that has an acceptable implementation.

Yes, I was the person reporting and supporting fzurita's GLideN64 threaded plugin. I posted the performance increase in Perfect Dark from 50-70 to 160+ VI/s with frame limiter off. But that is to do with the fact that Intel drivers don't support threading. Other drivers do, and will see no benefit from fzurita's opengl threaded plugin.
What about AMD? The reason why AMD "sucks" with PCSX2 is because their drivers do not support threading optimizations. I imagine AMD hardware will see similar benefits.

RPGMaster
9th July 2017, 01:14 AM
You keep blaming GLideN64 for your notebook's shortcomings. That Intel iGPUs -- or at least their Windows drivers -- suck is neither ironic nor surprising. You're also better off with Linux and MESA with one of those GPUs, since the Intel drivers tend to have sucky GL compatibility.There is nothing I can do besides only using newer hardware.. If I have to use my newer hardware, I might as well just use LLE (which I do). Might as well enjoy far better accuracy..

I'm not a fan of Linux and there's no way I'm ever resorting to using M64p or any variant.


You're saying that GLideN64 shouldn't code workarounds for people who refuse to buy "an actual GPU" as some smugly put it?Multi-threading should be a last resort imo. That's literally the last workaround I'd ever do.


There has to be some kind of cutoff. Certain API features are absolutely necessary because the N64 works completely differently to a PC, and shader-based tricks are needed to work around that. Mipmapping, for example.
5 year cutoff is not ideal.


GLideN64 was refactored to be API-agnostic, but DX might not be able to match GL functionality. Vulkan probably could, though. Gonetz put a lot of work into making it possible for someone to write a new backend if they want.
Hardly anyone in the scene is interested in D3D, so i doubt that will ever happen. It's one of the few things I'll give Dolphin credit for.


Azimer's isn't ready. It's not that simple. Does it work "better"? Yes. But is it "ready"? No.
What do you want then?


Have you tried playing The World is Not Enough on Project 64 recently? Or Resident Evil 2? Or Tarzan? Or Rogue Squadron? Or Battle for Naboo? Or Indiana Jones? Or San Francisco Rush 2049? Because there audio is a stuttering mess. I do faintly recall this to be your fault somehow, but my memory is fuzzy. And there are other games with issues that mupen64plus doesn't have.I did indeed get blamed for it, but nobody ever proved it :D . Even a non-coder can do the math to figure out whether or not there is a bug in my commit.

To answer your question though, I don't use Jabo's Audio. So that issue does not affect me. His plugin was never suitable for musyx games. That's the beauty of plugins. I can use whatever I want :D .


Or how about the fact FAT is being used to fix timing, crackling, and crashes, but it breaks RNG?Mupen isn't any better in this department.


You've floated the idea of using per-game framebuffer hacks, similar to what Jabo did for his plugin. Respectfully, that's a terrible idea. There are too many edge cases, and it's the wrong approach IMHO.
What if we are capable of solving these edge cases? And even if we aren't, why not allow users to benefit for the games that aren't difficult?


I can only think that you have a very, very slow CPU that can't handle the relatively unoptimized RSP interpreter. You're essentially saying the audio is bad because your PC isn't fast enough?Aren't they using cxd4's RSP? How is it relatively unoptimized?

ExtremeDude2
9th July 2017, 01:32 AM
Aren't they using cxd4's RSP? How is it relatively unoptimized?

It's extremely optimized from what can tell having talked to him during his entire development process.

SuperTurboTurkeyStuffer
9th July 2017, 01:50 AM
Multi-threading should be a last resort imo. That's literally the last workaround I'd ever do.
Considering Nvidia thread literally everything, why? You complain that GLideN64 struggles on old Intel GPUs despite this being entirely Intel's fault, and then you criticise efforts to code a workaround for the shortcomings of Windows driver writers at Intel and AMD who can't implement something generic Linux drivers have featured for years.

5 year cutoff is not ideal.
It's not about what's ideal. It's about what is practical. Also, this is why you keep a broken legacy plugin as a fallback.

To answer your question though, I don't use Jabo's Audio. So that issue does not affect me. His plugin was never suitable for musyx games. That's the beauty of plugins. I can use whatever I want :D .
That doesn't excuse releasing public builds of PJ64 that are broken out of the box. Plugins are about allowing people to expand PJ64's functionality. They're no an excuse to release a broken product and rely on users to fix it themselves.

What if we are capable of solving these edge cases? And even if we aren't, why not allow users to benefit for the games that aren't difficult?
Because the underlying idea is bad, and because while some people think the N64 library consists of Mario 64, Smash Bros, and Mario Kart, the list of edge cases is endless. It's not going to work, and it's fundamentally a wrong-headed idea. Plus it has little meaningful performance benefit over more accurate techniques because as previously mentioned, GLideN64 is very fast. And is getting faster.

Like I said, you're blaming GLideN64 for the fact that your GPU has badly written drivers. And then you dismiss attempts to solve this issue because you don't like GL call threading for some reason despite this being the norm. Nvidia is the market leader. Everyone else gets scraps. That's how this works, although in emulation you do get this topsy turvey relationship where some users demand that emulators work well with ancient hardware and broken drivers. I'm not talking about you here, but rather the kind of people who blame everything but their own hardware.

Aren't they using cxd4's RSP? How is it relatively unoptimized?
In my testing, HatCat's RSP has always been slower than PJ64's recompiler. Also, there's an old issue where certain SSE versions behave oddly on certain hardware. Haven't looked into that in a while.

RPGMaster
9th July 2017, 03:30 AM
Lets face it, graphics is the biggest problem with N64 emulation. Plugins are either too slow, too inaccurate, or both. There's a reason that the "Dolphin VC > N64 emulators" meme even exists. These geniuses think that just because they see pretty graphics, that Dolphin VC is more accurate :D . Well, gotta love karma because they are missing out on the best experience :D .

Anyway, my point is that it's not a bad thing for zilmar wanting to work on graphics emulation. I think I would have done the same, if I was in his position. Although I'd prefer to just write a plugin from scratch.

You cannot always rely on others to get the job done. No one seemed to trust that there was anyone capable and willing to implement HLE yielding but that's ok ;) .

It's extremely optimized from what can tell having talked to him during his entire development process.Yea i think it is pretty optimized for an interpreter.

Considering Nvidia thread literally everything, why? You complain that GLideN64 struggles on old Intel GPUs despite this being entirely Intel's fault, and then you criticise efforts to code a workaround for the shortcomings of Windows driver writers at Intel and AMD who can't implement something generic Linux drivers have featured for years.I've never been a fan of the "just multi-thread it" solution. I easily could have just multi-threaded Angrylion's plugin and retired development for good. I'm not opposed to someone implementing multithread, but I just don't think that alone is good enough.

What I am against is the idea of multi-threading it and just calling it a day. Same with async. It seems no one really cares about sync's performance as much as they do async.


It's not about what's ideal. It's about what is practical. Also, this is why you keep a broken legacy plugin as a fallback.That's complacency. I wouldn't call it practical because excessive complacency hinders progress.


That doesn't excuse releasing public builds of PJ64 that are broken out of the box. Plugins are about allowing people to expand PJ64's functionality. They're no an excuse to release a broken product and rely on users to fix it themselves.I agree there is no excuse, but that's how things are. People like to stick to brand-name products and this is the outcome.

I know that I cannot sway public opinion, so I usually do not bother trying. I remember making a branch of Azimer's DS8 that sounded great for a lot of popular games (with FAT off), but hardly anyone seemed interested. At the end of the day, people are responsible for their own actions. A lot of these complainers about the "N64 scene", haven't done anything to help improve the scene.


Because the underlying idea is bad, and because while some people think the N64 library consists of Mario 64, Smash Bros, and Mario Kart, the list of edge cases is endless. It's not going to work, and it's fundamentally a wrong-headed idea. Plus it has little meaningful performance benefit over more accurate techniques because as previously mentioned, GLideN64 is very fast. And is getting faster.Sync mode certainly is not "very fast". Otherwise it should be the default... Saying that it has little meaningful benefit is like saying HLE has little meaningful benefit for performance. Having to only copy a small fraction of a screen, only while the jumbotron is visible, is a great boost in performance rather than unconditionally always copying the entire screen.


Like I said, you're blaming GLideN64 for the fact that your GPU has badly written drivers. And then you dismiss attempts to solve this issue because you don't like GL call threading for some reason despite this being the norm.If optimizations can solve the issue, then the fault isn't entirely drivers. GLideN64 doesn't have to stick with only supporting OpenGL. So blaming drivers is hardly an excuse imo. If no one else wants to add other backends, I'd rather just write my own graphics plugin then.


In my testing, HatCat's RSP has always been slower than PJ64's recompiler. Also, there's an old issue where certain SSE versions behave oddly on certain hardware. Haven't looked into that in a while.I see what you are saying now. It's too bad he removed SSSE3 since that gave me a performance boost.

the_randomizer
9th July 2017, 05:03 PM
Glad you're going with Glide 64 and not that horribly broken Rice Video lol. :D That plugin messes up the HUD in a lot of Konami games.

Frank74
9th July 2017, 06:20 PM
Have you tried playing The World is Not Enough on Project 64 recently? Or Resident Evil 2? Or Tarzan? Or Rogue Squadron? Or Battle for Naboo? Or Indiana Jones? Or San Francisco Rush 2049? Because there audio is a stuttering mess. I do faintly recall this to be your fault somehow, but my memory is fuzzy. And there are other games with issues that mupen64plus doesn't have.
Yes, TWINE, RE2, Naboo, Indy, SFR2049 all have good audio here. And the camera issue was fixed recently for Naboo/Indy. I reverted PR 984 which fixes audio stuttering with Jabo, but my Azimer's build is good without reverting that commit.

As I said earlier, have you tried playing RE2 on PJ64 recently?
Yes, it's pretty perfect with GLideN64 and Jabo with PR984 reverted or Azimer's new audio code.

I can only think that you have a very, very slow CPU that can't handle the relatively unoptimized RSP interpreter. You're essentially saying the audio is bad because your PC isn't fast enough?
Nope, I sometimes use cxd4's static interpreter RSP in PJ64 without any noticeable bottleneck, for testing against PJ64's RSP. I've even suggested before to use cxd4's rsp as an interpreter option in PJ64, because it runs very well here, faster than PJ64's RSP Interpreter (via debugger).

I get static/click free audio in nearly every game with PJ64, including Body Harvest.

Gauntlet Legends still has problems.

retroben
9th July 2017, 06:33 PM
-cxd4's rsp as an interpreter option in PJ64, because it runs very well here, faster than PJ64's RSP Interpreter (via debugger).

Really? Maybe I should check that out in hopes of better performance for now until hopefully that recompiler solution gets done for better ASM manipulation in real-time but without the freezes from accuracy so more glitch codes can be used and some even toggled for full enjoyment.

Frank74
9th July 2017, 07:26 PM
Really? Maybe I should check that out in hopes of better performance for now until hopefully that recompiler solution gets done for better ASM manipulation in real-time but without the freezes from accuracy so more glitch codes can be used and some even toggled for full enjoyment.

Here's my build with the config which can be opened from within PJ64 via configure RSP.
https://www.dropbox.com/s/7ds4v32pjb1pb73/Static%20Interpreter%20RSP.zip?dl=1

Answer 10 to first question for HLE GFX, LLE Audio. Or 00 for LLE GFX/Audio.
Run the config first. It doesn't use PJ64's Use HLE plugin options.

RPGMaster
9th July 2017, 08:31 PM
Yes, TWINE, RE2, Naboo, Indy, SFR2049 all have good audio here. And the camera issue was fixed recently for Naboo/Indy. I reverted PR 984 which fixes audio stuttering with Jabo, but my Azimer's build is good without reverting that commit.

Gauntlet Legends still has problems.How did you manage to get good audio for Musyx games? I've managed to do fine in some games, but Rogue Squadron, TWINE, and Gauntlet have given me trouble. I have high standards for audio, and it bugs me even if I hear one crackle every 5 minutes of gameplay (which is essentially the case for Rogue). So what are your settings for these games?

One thing I've noticed is that some games have very sensitive audio and what I mean is that performance has a significant impact. There are games (like Top Gear), where I need to run well above 100 VI/s in order to have acceptable audio. Yet I ironically get criticized for wanting better performance :rolleyes: , on top of caring about users with worse hardware.

What problems do you have with Gauntlet?
Glad you're going with Glide 64 and not that horribly broken Rice Video lol. :D That plugin messes up the HUD in a lot of Konami games.Thanks for bringing up Rice Video! That plugin would surely be the ideal plugin for supporting 15 year old hardware ;) . Maybe that should be the default :D. I'm excited because that would mean PJ64 will have better performance by default!

On a serious note, Ishiiruka (which is far superior to regular Dolphin) support D3D9 and so does PCSX2. Based on the few games I've tested, the experience was acceptable imo. I'm sure they could improve the accuracy further if they had dedicated D3D9 programmers. It's not like using a fairly old API would be absolutely terrible. If there's a dev willing to go out of their way to make sure more users are able to use their software, God bless them.

I think it's silly that people are attacking zilmar for trying to do the right thing. The attacks/negativity hinder progress far more than the act of not catering to end users with high-end hardware. CEN64 is even more accuracy focused and yet is at least runnable on low-end hardware (SSE2 came out in 2001). This allows developers with low-end hardware to contribute and use.

If it were up to me, I think D3D9, Windows XP, and (maybe) SSE2 would be my cutoff. If I were to focus more on LLE, SSE2 for sure and then 64-bit would probably be another cutoff.

Frank74
9th July 2017, 10:17 PM
How did you manage to get good audio for Musyx games? I've managed to do fine in some games, but Rogue Squadron, TWINE, and Gauntlet have given me trouble. I have high standards for audio, and it bugs me even if I hear one crackle every 5 minutes of gameplay (which is essentially the case for Rogue). So what are your settings for these games.

TWINE/RE2 are perfect audio with this:
Plugins:
https://www.dropbox.com/s/mpi2a2v3pikho51/TWINEconf.JPG?dl=1
https://www.dropbox.com/s/9l6s8tkstybessl/Plugins.zip?dl=1
Threaded option needs to be turned on before starting the game. All default options.

Audio settings default, except AudioThread Sleep on:
https://www.dropbox.com/s/hexzxw4nkw78wrs/TWINEaudioonf.JPG?dl=1

Edit:
Gauntlet needs a bigger buffer. It crackles with these settings. But is fine if I set buffer/backend FPS to 30. The lower the FPS buffer setting, the bigger the buffer. Though big buffer causes frame limiter to lock to 50 VI/s when you go below the FPS of the game.
Buffer settings don't take effect until you restart or load a save state.

the_randomizer
9th July 2017, 10:59 PM
How did you manage to get good audio for Musyx games? I've managed to do fine in some games, but Rogue Squadron, TWINE, and Gauntlet have given me trouble. I have high standards for audio, and it bugs me even if I hear one crackle every 5 minutes of gameplay (which is essentially the case for Rogue). So what are your settings for these games?

One thing I've noticed is that some games have very sensitive audio and what I mean is that performance has a significant impact. There are games (like Top Gear), where I need to run well above 100 VI/s in order to have acceptable audio. Yet I ironically get criticized for wanting better performance :rolleyes: , on top of caring about users with worse hardware.

What problems do you have with Gauntlet?
Thanks for bringing up Rice Video! That plugin would surely be the ideal plugin for supporting 15 year old hardware ;) . Maybe that should be the default :D. I'm excited because that would mean PJ64 will have better performance by default!

On a serious note, Ishiiruka (which is far superior to regular Dolphin) support D3D9 and so does PCSX2. Based on the few games I've tested, the experience was acceptable imo. I'm sure they could improve the accuracy further if they had dedicated D3D9 programmers. It's not like using a fairly old API would be absolutely terrible. If there's a dev willing to go out of their way to make sure more users are able to use their software, God bless them.

I think it's silly that people are attacking zilmar for trying to do the right thing. The attacks/negativity hinder progress far more than the act of not catering to end users with high-end hardware. CEN64 is even more accuracy focused and yet is at least runnable on low-end hardware (SSE2 came out in 2001). This allows developers with low-end hardware to contribute and use.

If it were up to me, I think D3D9, Windows XP, and (maybe) SSE2 would be my cutoff. If I were to focus more on LLE, SSE2 for sure and then 64-bit would probably be another cutoff.


Was I attacking Zilmar? No, I wasn't, I hope you weren't accusing me. I was serious because out of the two plugins, Glide 64 made more sense. Jabo's plugin is just...ugh. I'm nitpicky about emulation accuracy, Jabo can't even emulate the alpha dithering effects many first and a few third party game used. Even the Wii U emulates the effect perfectly, but Jabo, heh it doesn't. Glide 64 isn't bad, and that's fine, but I personally use GlideN64 because it's just what I use *shrug*

RPGMaster
9th July 2017, 11:24 PM
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?

Was I attacking Zilmar? No, I wasn't, I hope you weren't accusing me. I was serious because out of the two plugins, Glide 64 made more sense. Jabo's plugin is just...ugh. I'm nitpicky about emulation accuracy, Jabo can't even emulate the alpha dithering effects many first and a few third party game used. Even the Wii U emulates the effect perfectly, but Jabo, heh it doesn't. Glide 64 isn't bad, and that's fine, but I personally use GlideN64 because it's just what I use *shrug*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 :D .

Frank74
10th July 2017, 12:28 AM
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?

It's XA2 New Audio code, not legacy.

I've just noticed static start in Top Gear Rally after a few minutes with default settings though. There's still a timing problem with that game. FPS at 95 and only 2 buffers seem better. So smaller buffer. It's been playing in the background with those settings for ten minutes without any static.

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.

SuperTurboTurkeyStuffer
10th July 2017, 12:30 AM
Yes, TWINE, RE2, Naboo, Indy, SFR2049 all have good audio here. And the camera issue was fixed recently for Naboo/Indy. I reverted PR 984 which fixes audio stuttering with Jabo, but my Azimer's build is good without reverting that commit.
That's not a solution. Everyone knows they work fine with Azimer's. Everyone knows you have to revert the PR to "fix" them with Jabo's. I'm talking about this very moment in time. When Jane Doe or John Smith downloads Project 64 and wants to play Rogue Squadron.

The audio is screwed. They need this fixed. They don't need to be told to revert a pull request or download and tune a different audio plugin. That is absolutely ludicrous. Sometimes the lack of consideration for the end users blows my mind a tiny bit.

It's like saying, "Na, PJ64 doesn't have comprehensively broken graphics emulation because you can just download GLideN64 to fix that. Why didn't we include it? Oh, we were scared of people with really, really, really, really old hardware who prefer everyone have broken emulation than for people with really, really, really old hardware to have to select a legacy plugin from the options menu."

I think it's silly that people are attacking zilmar for trying to do the right thing. The attacks/negativity hinder progress far more than the act of not catering to end users with high-end hardware.
"High-end hardware." By 2017, GLideN64 requires low-end hardware. There is "low end", and then there is "stop dreaming that this will ever emulate the N64 correctly".


CEN64 is even more accuracy focused and yet is at least runnable on low-end hardware (SSE2 came out in 2001). This allows developers with low-end hardware to contribute and use.
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.

If it were up to me, I think D3D9, Windows XP, and (maybe) SSE2 would be my cutoff.
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.

retroben
10th July 2017, 01:37 AM
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=0B1nr_75cEfQOMjJQN3NlTEFBQ1k

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

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

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=0B1nr_75cEfQOcTRKaFpXN1pwVjQ

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

SuperTurboTurkeyStuffer
10th July 2017, 02:17 AM
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.
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.
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
10th July 2017, 03:00 AM
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 :D.

They need this fixed.
How should it be solved?


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.

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
10th July 2017, 06:01 AM
Vulkan can achieve better performance with lower overhead which would really help GLideN64 perform better if implemented well enough.

SuperTurboTurkeyStuffer
10th July 2017, 06:33 AM
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.

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.

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
10th July 2017, 08:29 AM
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.


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 :D.

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
10th July 2017, 06:23 PM
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 :D .

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
21st July 2017, 02:41 AM
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
21st July 2017, 10:57 PM
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
27th July 2017, 02:38 AM
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.

Wally123
27th July 2017, 02:44 AM
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

GlideN64 wraps Voodoo3 functions (Glide3x) to OpenGL. It even says so in the mission statement on Indiegogo

https://www.indiegogo.com/projects/gliden64-graphics-plugin#/

As for the "Bloated" GUI, it is far better to have everything self contained than it is to make users install all the required components of the GUI themselves. That and it makes it more compatible with the MupenPlus core for RetroArch. I do agree with zilmar that it is a tad bloated as a plugin, but as far as being able to be used in RetroArch, IMHO it is a fair price to pay for being cross platform between Mupen and Zilmar spec plugins.

loganmc10
27th July 2017, 02:55 AM
GlideN64 wraps Voodoo3 functions (Glide3x) to OpenGL. It even says so in the mission statement on Indiegogo

No, it says that Glide64 used Glide3x. Trust me, GLideN64 doesn't wrap any functions, it is written directly in OpenGL.

HatCat
14th August 2017, 04:53 AM
Qt in and of its self runs OpenGL, so keeping the render API GLIDE instead of GL would be dumb as hell if you're depending on Qt already.

Similarly, Qt libraries are all heavily designed in C++, so why even bother coding in C on top of colossal dependencies.

All the fancy alpha-transparent windows and objects blending in KDE is Qt using the graphics card through OpenGL. Interesting, but it's all done in C++ with a ton of console warning messages and much higher memory usage and latency. I think just GTK (under Xfce or maybe GNOME) is still not as lightweight as I like to go but still way simpler with more than a sufficient amount of modern desktop design concepts for my purposes.

ExtremeDude2
15th August 2017, 12:33 PM
It's alive :eek: