View Single Post
  #29  
Old 8th July 2017, 11:55 AM
zilmar zilmar is offline
Core Team
Alpha Tester
Project Supporter
Administrator
 
Join Date: Jun 2005
Posts: 988
Default

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
>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.


Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
>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.

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
>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.


Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
>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.

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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?

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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.


Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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.


Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
>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.


Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
>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.

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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.

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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.

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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.

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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.

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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.
Reply With Quote