Go Back   Project64 Forums > Public Version > Project 64 - v2.x - Issues

Reply
 
Thread Tools Display Modes
  #11  
Old 23rd June 2013, 03:53 AM
KenPruitt KenPruitt is offline
Junior Member
 
Join Date: Jun 2013
Posts: 5
Default

I didn't know that syncing the audio to the game could actually slow down the game....
Reply With Quote
  #12  
Old 25th June 2013, 03:46 PM
Tasoulis Tasoulis is offline
Senior Member
 
Join Date: May 2011
Posts: 167
Default

Im pretty sure a good RDB update will make 2.1 the best version to have. So far i test games one by one and i can already make more games move and sound perfect than in 1.6 or 1.7

The default 2.1 settings are just no good. For starters, all games have both "fixed audio timing" and "sync using audio" checked by default. This is good for smooth audio but it causes unstable VI/s which means stuttering frame rate in every game. At least one of the two has to be unchecked. I have unchecked both for most games i tried and with the right sound plugin (either Azimer's 0.60 or shunyuan's) i get smooth, pop-less audio along with uninterrupted 60VI/s in more games than i ever could with other versions.

Last edited by Tasoulis; 25th June 2013 at 03:48 PM.
Reply With Quote
  #13  
Old 26th June 2013, 05:29 AM
dsx_ dsx_ is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2010
Location: Australia
Posts: 1,105
Default

i think zilmar wants the audio to be popless "out of the box" so fixed audio timing is enabled by default to stop jabo's audio plugin from having issues, even if it means the VI/s vary between 59-63, which isnt really a big deal imo
Reply With Quote
  #14  
Old 26th June 2013, 12:43 PM
Tasoulis Tasoulis is offline
Senior Member
 
Join Date: May 2011
Posts: 167
Default

Quote:
Originally Posted by dsx! View Post
i think zilmar wants the audio to be popless "out of the box" so fixed audio timing is enabled by default to stop jabo's audio plugin from having issues, even if it means the VI/s vary between 59-63, which isnt really a big deal imo
The numbers may be very close to the 60VL/s target, but the end result is noticeable video stuttering anyway, which can be just as annoying as audio pops in some games.

Also, not every game has audio pops despite what audio options you use, but with both those options enabled, every single game has stuttering frame rate. Its a "pick your poison" matter, but imo, default options should be with these two options disabled (or at least one of the two) because the stuttering video affects all games otherwise.

I guess newbies on N64 scene won't notice the stuttering video as much as audio pops if they haven't played the games before, so that makes some sense. Still, not a big deal, it doesn't matter what poison you chose, what matters is an updated RDB of CFG file with the correct options and recommended plugins for each game. So the majority of games can be as close to perfection as possible by default and the end user will only have to do minor corrections.

That's what i'm trying to do with my setup and roms, but its very time consuming, some games are easy to configure but many are marathons of trial and error.

Last edited by Tasoulis; 26th June 2013 at 12:50 PM.
Reply With Quote
  #15  
Old 27th June 2013, 12:47 AM
furryfangs's Avatar
furryfangs furryfangs is offline
Project Supporter
Member
 
Join Date: Sep 2009
Posts: 85
Default

Quote:
Originally Posted by Tasoulis View Post
The numbers may be very close to the 60VL/s target, but the end result is noticeable video stuttering anyway, which can be just as annoying as audio pops in some games.

Also, not every game has audio pops despite what audio options you use, but with both those options enabled, every single game has stuttering frame rate. Its a "pick your poison" matter, but imo, default options should be with these two options disabled (or at least one of the two) because the stuttering video affects all games otherwise.

I guess newbies on N64 scene won't notice the stuttering video as much as audio pops if they haven't played the games before, so that makes some sense. Still, not a big deal, it doesn't matter what poison you chose, what matters is an updated RDB of CFG file with the correct options and recommended plugins for each game. So the majority of games can be as close to perfection as possible by default and the end user will only have to do minor corrections.

That's what i'm trying to do with my setup and roms, but its very time consuming, some games are easy to configure but many are marathons of trial and error.
if i had to take a wild guess the RSP plugin would be the main reason for stuttering frames and audio pops call me stupid if i'm wrong :3
__________________
Windows 7 Home Premium NVIDIA GeForce GTS 450 1TB HDD Intel Core i3-2100 10gb RAM NVIDIA High Definition Audio.
Reply With Quote
  #16  
Old 27th June 2013, 02:41 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

Pj64 users generally have no worries about the RSP because they tend to use HLE-filtered video with inaccurate graphics and the ability to play a decent fraction of the games compatibly.

The only time the RSP typically factors in for most people is just audio sound, and even then, Jabo's RSP recompiler eliminates almost all the overhead (edit, of course, it would eliminate far more if a recompiler was made out of my RSP interpreter, but it's not the most interesting thing...not as easy to implement cycle-accuracy there to balance accuracy with speed). It's virtually as if the RSP goes unemulated to you guys.

When using LLE or playing certain games however, it starts to matter.

Last edited by HatCat; 27th June 2013 at 02:44 AM.
Reply With Quote
  #17  
Old 27th June 2013, 03:09 AM
furryfangs's Avatar
furryfangs furryfangs is offline
Project Supporter
Member
 
Join Date: Sep 2009
Posts: 85
Default

Quote:
Originally Posted by FatCat View Post
Pj64 users generally have no worries about the RSP because they tend to use HLE-filtered video with inaccurate graphics and the ability to play a decent fraction of the games compatibly.

The only time the RSP typically factors in for most people is just audio sound, and even then, Jabo's RSP recompiler eliminates almost all the overhead (edit, of course, it would eliminate far more if a recompiler was made out of my RSP interpreter, but it's not the most interesting thing...not as easy to implement cycle-accuracy there to balance accuracy with speed). It's virtually as if the RSP goes unemulated to you guys.

When using LLE or playing certain games however, it starts to matter.
i know only a small fraction about emulation.
do you have to tie the RSP around the other plugins or does it not work that way?
__________________
Windows 7 Home Premium NVIDIA GeForce GTS 450 1TB HDD Intel Core i3-2100 10gb RAM NVIDIA High Definition Audio.
Reply With Quote
  #18  
Old 27th June 2013, 03:42 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

The RSP is a communications signal processor.

It services all the requests between the host VR4300 main CPU of the N64 and, primarily, the display drawings processor which graphics plugins emulate.

It's also needed to maintain the signal data memory sent for the audio interface to process. So audio plugins in LLE such as Jabo's would not work without the RSP.

Controller plugins to my knowledge have absolutely nothing to do with the RSP, although I wonder if it's possible to modify PIF or transfer pak data or crap like that I don't know a thing about. The memory pak, probably not directly. I did reverse the N64 mempak format a little.
Reply With Quote
  #19  
Old 27th June 2013, 04:00 AM
furryfangs's Avatar
furryfangs furryfangs is offline
Project Supporter
Member
 
Join Date: Sep 2009
Posts: 85
Default

Quote:
Originally Posted by FatCat View Post
The RSP is a communications signal processor.

It services all the requests between the host VR4300 main CPU of the N64 and, primarily, the display drawings processor which graphics plugins emulate.

It's also needed to maintain the signal data memory sent for the audio interface to process. So audio plugins in LLE such as Jabo's would not work without the RSP.

Controller plugins to my knowledge have absolutely nothing to do with the RSP, although I wonder if it's possible to modify PIF or transfer pak data or crap like that I don't know a thing about. The memory pak, probably not directly. I did reverse the N64 mempak format a little.
i figured as much is that why the glider64 plugin is not as capable or is that because the plugin is in it's early stages?
__________________
Windows 7 Home Premium NVIDIA GeForce GTS 450 1TB HDD Intel Core i3-2100 10gb RAM NVIDIA High Definition Audio.
Reply With Quote
  #20  
Old 27th June 2013, 04:13 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

Glide64 has been around for a long time...probably nearer the age of UltraHLE which did gfx in HLE since before Project64.

It's not immature or anything like that, just unorthodox.

When you do things in HLE, you just analyze the RSP code yourself and rewrite what the RSP does in the C language or whatever, and it statically compiles as x86 code for the PC rather than native RSP code.

It's neither accurate nor maintainable, however.
RSP code segments are tremendously huge, and if you misread or mistranslate anything you'll have a hell of a time isolating the bug.

It would be safer, more accurate and compatible, and less hazard-prone to just do it in LLE, where it's not statically pre-compiled.

Since the RSP can write to some of the special-purpose CPU registers, data memory read by the RDP, and the CPU's Rambus DRAM you could theoretically use the RSP to meddle with controller data or stuff in the other interfaces theoretically I guess...but generally in the commercial games the RSP is not used for such things, just gfx and audio.
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 10:27 PM.


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