Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #821  
Old 27th May 2014, 06:33 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

After trying a few games with the intel sse4 build, I saw that GCC sse4 and Intel sse4 are pretty close. My debugger is acting weird so I'll put that on hold for now lol. Time to work on sound .

For sound, do you think we'd need per game settings? Or would a good implementation work well for every game?

Also, do you think PGO would be worth trying out for rsp and gfx?

This sound testing stuff's complicated lol. It's like plugins were designed to be used with specific settings. For instance azimer's audio is more in sync when I use pj64 1.6 interpreter with CF = 2. I usually play on CF = 1, but now I need to figure out how that setting works. I've also been looking at Mupen 0.5's source. I must say, it's very clean . I'd say it's easier to understand than 1.6 or 1964 0.85.

I also need to figure out how to fix an emulator core so that audio works more accurately. I wouldn't want to design a plugin to only be good with a specific emulator + specific settings.

Last edited by RPGMaster; 27th May 2014 at 09:35 AM.
Reply With Quote
  #822  
Old 27th May 2014, 09:58 AM
userss userss is offline
Junior Member
 
Join Date: May 2014
Posts: 5
Default

cant say enythink its better
Reply With Quote
  #823  
Old 27th May 2014, 12:42 PM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Quote:
Originally Posted by RPGMaster View Post
Also, do you think PGO would be worth trying out for rsp and gfx?
FWIW, I saw a ~5%+ speed boost across all ROMs, even though I only "trained" the binary with PGO using one specific ROM. It's easy enough to do with gcc that it can't hurt to try, and I'll be surprised if you don't get at least some improvement, however minor.

Speaking of compiler assisted optimizations, it would be nice if somebody ran UBSan on all these plugins and scrubbed any remaining undefined behaviour out of them (if there is some).

Last edited by MarathonMan; 27th May 2014 at 12:45 PM.
Reply With Quote
  #824  
Old 27th May 2014, 09:49 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

In that case, I'll experiment with PGO.

Speaking of UB... After updating Clang, even that compiler won't work with Zilmar's Basic Audio now... There must be a lot of UB in that source code.

Does anyone know what counter factor Mupen 0.5.1 uses? It seems to have the best audio timing out of the big 3 (Pj64, Mupen, and 1964). I also heard less crackling. For pj64 and 1964, the audio improved when I switched from CF = 1 to CF = 2.

Edit: I found the issue. It's so weird when things work fine on 1 compiler, but are broken on another. After looking closely at the assembly code, I realized what the error was.
Code:
rgdscbpn[3].dwOffset = DSBPN_OFFSETSTOP;
rgdscbpn[3].hEventNotify = rghEvent[3];
rgdscbpn only has 3 slots, not 4, so that code needs to get erased. I guess some compilers handle things differently. It's weird how with the buggy code, it worked with Intel if SetupDSoundBuffers wasn't inlined. Next time I run into a problem where it works on one compiler but not the other, I'll try to fix the problem instead of relying on the compiler it works for.

Last edited by RPGMaster; 27th May 2014 at 10:42 PM.
Reply With Quote
  #825  
Old 28th May 2014, 12:02 AM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Mupen uses counter factor 2, this has recently been made configurable in m64p as well see https://github.com/mupen64plus/mupen...b9f10c9ce0e866 for reference
Reply With Quote
  #826  
Old 28th May 2014, 04:23 AM
zuzma zuzma is offline
Junior Member
 
Join Date: Jan 2013
Posts: 28
Default

@RPGMaster

I only recall it being used to fix freezing games in mupen64plus not for anything audio related. I think there was one case where it sped up killer instinct gold for mobile devices. Don't remember the CountPerOp setting though. All you have to do to change it is add in CountPerOp=(number) into the mupen64plus.ini file.

edit: Too bad most of the frontends for m64p are derpy as fuck. It'd really stand out if it was easier to use. : p

Last edited by zuzma; 28th May 2014 at 04:34 AM.
Reply With Quote
  #827  
Old 28th May 2014, 05:07 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

I don't really mind Mupen64Plus as a theoretically console-only application (better than the GUI-only 1964 winapi, except not even that if it makes me ctrlaltdel all the time!); I'd just rather pay a little more attention to what people like Hacktarux are doing with the r4k interpreter, instead of what okaygo and some other guys are doing with recompiler + some features.

Edit: Yeah RPGMaster I remember finding something like that too. He was doing modulus by 3 even though there were 4 array elements or, something like that. Maybe there are 4 sound buffers or states, and he accidentally declaed it as 3? Or hell, maybe you fixed it already. :P
Reply With Quote
  #828  
Old 28th May 2014, 05:40 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Thanks for the info guys. I didn't know 2 was the most stable, until recently . I thought it just had to do with computer speed.

Quote:
Originally Posted by HatCat View Post
I don't really mind Mupen64Plus as a theoretically console-only application (better than the GUI-only 1964 winapi, except not even that if it makes me ctrlaltdel all the time!); I'd just rather pay a little more attention to what people like Hacktarux are doing with the r4k interpreter, instead of what okaygo and some other guys are doing with recompiler + some features.

Edit: Yeah RPGMaster I remember finding something like that too. He was doing modulus by 3 even though there were 4 array elements or, something like that. Maybe there are 4 sound buffers or states, and he accidentally declaed it as 3? Or hell, maybe you fixed it already. :P
I agree with you about paying attention to Hacktarux's code rather than the other ones. His code is certainly the easiest to follow. I'd personally prefer winapi over stdio, but it's still good. Do you have the slightest idea what part of the code would impact things like audio timing? I know it's probably in the cpu section.

For the fix I just commented out that part. I may just add 1 to the total array size and uncomment the code. I haven't noticed a difference between the 2 yet. Lol I have no idea what I'm doing. I tried doing 6 buffers instead of 3 and it was all jacked up xD. That's what happens when I mess around with stuff before reading the basics ;/ . Since it's been stated that emulators aren't accurate enough for CF = 1, I'll base everything off of CF = 2.

I tried Mupen64plus yesterday, and idk if it's the core or the plugins, but it didn't seem as smooth as mupen64 0.5.1. I'm thinking maybe it was just the plugins. Not many to choose from lol.
Reply With Quote
  #829  
Old 28th May 2014, 06:04 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

Based solely on my own experiences, the standalone version has had issues for a while now, at least on Windows. I've pretty much given up on it and use the libretro version instead, which runs far better for me. Only thing it hasn't implemented is the z64 plugin, but they're adding Angrylion's plugin instead.
Reply With Quote
  #830  
Old 28th May 2014, 03:22 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

@GPDP
can't really confirm that, but w.e. retroarch is a tad easier since it automatically activates options which aren't exactly deemed necessary but may be wanted for an effect or two (at a speed hit)

@RPGMaker
From what I understand the whole concept of setting a CF is a hack because the emus aren't cycle accurate, CF = 1 isn't necessarily "more accurate" in general.
As for slower performance on mupen that could really be the plugins, they all use opengl and your video hardware seems to struggle with it as you have mentioned a few times
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 04:28 PM.


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