View Single Post
  #27  
Old 8th July 2017, 09:13 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,014
Talking

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

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

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