Go Back   Project64 Forums > General Discussion > Site News

Reply
 
Thread Tools Display Modes
  #31  
Old 8th July 2017, 04:58 PM
Frank74's Avatar
Frank74 Frank74 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Aug 2013
Location: UK
Posts: 745
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.

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.

Last edited by Frank74; 8th July 2017 at 05:04 PM.
Reply With Quote
  #32  
Old 8th July 2017, 06:27 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 642
Default

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.

Last edited by retroben; 8th July 2017 at 06:30 PM.
Reply With Quote
  #33  
Old 8th July 2017, 07:01 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2013
Posts: 1,960
Talking

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

Quote:
Originally Posted by Bighead View Post
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 ). Do you have any advice on that?

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

Quote:
Originally Posted by Bighead View Post
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.
Quote:
Originally Posted by Frank74 View Post
@ 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.
Reply With Quote
  #34  
Old 8th July 2017, 07:27 PM
loganmc10 loganmc10 is offline
Junior Member
 
Join Date: May 2017
Posts: 5
Default

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

Last edited by loganmc10; 8th July 2017 at 11:22 PM.
Reply With Quote
  #35  
Old 8th July 2017, 11:27 PM
theboy181's Avatar
theboy181 theboy181 is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Aug 2014
Location: Prince Rupert,British Columbia Canada
Posts: 405
Default

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.
__________________
So you think you can TECH!! Watch this!! https://www.youtube.com/watch?v=NAUKPq5QjL0

Last edited by theboy181; 9th July 2017 at 12:40 AM.
Reply With Quote
  #36  
Old 9th July 2017, 12:32 AM
SuperTurboTurkeyStuffer SuperTurboTurkeyStuffer is offline
Junior Member
 
Join Date: Jul 2017
Posts: 16
Default

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

Quote:
Originally Posted by Frank74 View Post
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.
Reply With Quote
  #37  
Old 9th July 2017, 01:14 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2013
Posts: 1,960
Talking

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

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

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

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

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

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

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

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

Quote:
Originally Posted by SuperTurboTurkeyStuffer View Post
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?
Reply With Quote
  #38  
Old 9th July 2017, 01:32 AM
ExtremeDude2's Avatar
ExtremeDude2 ExtremeDude2 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2010
Location: USA
Posts: 2,294
Default

Quote:
Originally Posted by RPGMaster View Post
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.
__________________
Quote:
Originally Posted by dsx! View Post
are you american or something
Reply With Quote
  #39  
Old 9th July 2017, 01:50 AM
SuperTurboTurkeyStuffer SuperTurboTurkeyStuffer is offline
Junior Member
 
Join Date: Jul 2017
Posts: 16
Default

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

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

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

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

Quote:
Originally Posted by RPGMaster View Post
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.
Reply With Quote
  #40  
Old 9th July 2017, 03:30 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2013
Posts: 1,960
Talking

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 . Well, gotta love karma because they are missing out on the best experience .

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 .

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

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

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

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

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

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

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 11:09 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.