mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support
-
(@dankcushions I'm reading your history of work on github about this skew setting)
Edit for more content: My approach is often to create a doc -- in some cases the doc explains why no action was taken and gives the users some ideas on how to proceed on their own. I'm trying to figure out if that's better in this case or whether it's better to submit a PR to RetroArch.
In general, I've been told that cores shouldn't be coded "to" RetroArch. I think we're all agreeing for now that there's nothing going on in mame2003/plus here so we don't want to code some workaround.
Beyond that I'm leaning towards a very brief write-up on
audio_max_timing_skewthat summarizes what we've just covered here with some of your discussion with hunterk on github. -
On one hand: I have a stupidly large record collection and a pretty good recall of music that's in it. I would know instantly if there were problems like this with my music.
But I only play a handful of video games personally. I don't know what they are supposed to sound like! I can certainly tweak settings to some extremes and see what happens though.
I have to agree. I'm impressed how people pick up the subtle differences and even games I commonly played I miss too. I didn't notice the ga2 shadows until someone else pointed it out. Nostalgia trumps I suppose. Any music genre from the 70s or 80s though I can tell you album, artist, track and if it's been remastered or altered in any way. Except boy bands, I had to draw the line somewhere.
@markwkidd - Is there'a a mame2003_plus Wiki somewhere that you're adding this information or mainly posting on the Github main page?
-
@markwkidd i think that's a good approach.
it was a frustrating subject for me as windale/zappautopia (same person) had blinkers on with it - all they cared about that the sound was wrong. the fact that this was a retroarch feature, working as designed, and could be configured to suit them did not seem to get any traction.
anyway, as far as i'm aware audio_timing_skew is relevant to mame2003 vanilla only, as plus reports everything below 60 as 60: https://github.com/libretro/mame2003-plus-libretro/blob/6ab5d92c00a02b1ea1fd9c1dc8880e4a36811089/src/mame2003/mame2003.c#L565 - this will bypass timing skew - retroarch will presume your game is a 60fps game that is dropping frames, and not a 57.4 fps game that should (according to the default settings) be skewed to 60.
so, any testing you do would have to be with mame2003 vanilla.
-
If you will indulge me in letting me put on my technical writing hat only -- would folks be willing to take a look at the Troubleshooting RetroArch Audio Skew Issues doc I have drafted?
I'm looking especially for feedback on mistakes in how I characterize the feature and the fix. Also for any specific games that are known to have audio issues that can be affected by
audio_max_timing_skew.I hope that the payoff will be being able to say "read the docs" next time this comes up :)
-
RetrArch includes a setting called audio_max_timing_skew. The audio timing skew feature is helps RetroArch know when to resample the audio when it is making adjustments like resampling NTSC console games that display at rates like 60.0988Hz to sync on displays that run at 60.0Hz
my understanding is that it 'resamples' (perhaps not the right word) the fps as well. that is, a 57.4fps game on a display of 60Hz:
- is sped up so it becomes true 60fps (ie, does not tear (v sync off), or does not hold the occasional frame for 2 frames (v sync on))
- the audio is resampled to the new fps as you say.
a game running faster than 60fps, yet still within your skew threshold, will be slowed + pitched down.
Issues with Audio Skew in mame2003-plus
again, audio skew has no effect on mame2003-plus. see my above post. it does on mame2003 vanilla (and i guess any other core).
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
my understanding is that it 'resamples' (perhaps not the right word) the fps as well. that is, a 57.4fps game on a display of 60Hz:
is sped up so it becomes true 60fps (ie, does not tear (v sync off), or does not hold the occasional frame for 2 frames (v sync on))
the audio is resampled to the new fps as you say.That makes sense! I will add. And I will move the wiki to mame2003 instead. Fun!
Now it's here: https://github.com/libretro/mame2003-libretro/wiki/Troubleshooting-RetroArch-Audio-Skew-Issues
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
me that should (according to the default settings) be skewed to 60.
so, any testing you do would have to be with mame2003 vanilla.your not set to 60 fps your at game rate fps unless im miss understanding something here
-
I think you need to use vsync loosely in this scenario. I'm not sure on the Pi (does it have vsync capabilities even?) but usually on a PC when you're under the monitor refresh rate you leave vsync off as it isn't going to do anything. Except maybe lower the refresh to match the video capabilities in multiples. When the framerate is above the monitor refresh rate frames get "throttled" and sent to video purgatory.
-
I doubt there will be any difference for audio scew and how we are doing it. if there is we can change it just dont see any problems at all if there is a diffence between audio scew and the way we are doing it ill change it. If audio scew is smoother at 57 fps id be surprised but pleasantly if it does improve things cant see it though never say never!
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
me that should (according to the default settings) be skewed to 60.
so, any testing you do would have to be with mame2003 vanilla.your not set to 60 fps your at game rate fps unless im miss understanding something here
yes, exactly. if you set at 60 then audio skew does nothing, because it thinks your game is 60 fps and just dropping frames. if you report the game as 57.4fps (as mame2003 vanilla does) it will skew it.
-
@riverstorm said in mame2003-plus: 250 new games, new input system, new features, new bugs:
I think you need to use vsync loosely in this scenario. I'm not sure on the Pi (does it have vsync capabilities even?) but usually on a PC when you're under the monitor refresh rate you leave vsync off as it isn't going to do anything. Except maybe lower the refresh to match the video capabilities in multiples. When the framerate is above the monitor refresh rate frames get "throttled" and sent to video purgatory.
pi has vsync and it’s on by default. yes, retroarch will always send 60 fps to your 60 fps display, but (with the skew feature) it will speed up a 57.4 fps game to true 60, rather than hold ~3 frames every second to for 2 frames, to judder it to an effective 57.4 speed.
-
Am I right at the big picture level that -- when this feature kicks in -- it's boiling down to a choice between:
- Pitch changes to the emulated audio OR
- Judder/held drames/dropped frames in the video
In yet other words: There is no way to avoid either audio inaccuracy or issues with video frames when displaying 57.whatver Hz in a 60hz video environment.
-
mark try both see if one is any better than the other its all theory atm pitch only changes because the game runs too fast you run faster the pitch will change. I would like to hear feedback from users on this one :) is audio scew on any better than the way mame2003+ is doing it
-
@markwkidd 1. also includes changes to game speed. but yes, unless you turn off v sync and skew i guess (then u get tearing)
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
mark try both see if one is any better than the other its all theory atm
how? i’ve tested it quite a bit grant.
-
@dankcushions what audo scew setting should i put in for 2003 i just want to se if its smoother video wise if its better we will just use that way not a debate here just want the best way implemented im 0n 0.05 just now. I changed it to 0.03 restarted retroatch game reprots the right fps but is playing too fast. Well i had to restart it does seem to settle speed wise but i see no real difference in this and the original mame2003+ . I hope we can get some feebakc on this from users and see if they have a preference
-
@markwkidd said in mame2003-plus: 250 new games, new input system, new features, new bugs:
Judder/held drames/dropped frames in the video
I've updated my draft here: https://github.com/libretro/mame2003-libretro/wiki/Troubleshooting-RetroArch-Audio-Skew-Issues
Do with it what you will, folks.
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@dankcushions what audo scew setting should i put in for 2003 i just want to se if its smoother video wise if its better we will just use that way not a debate here just want the best way implemented im 0n 0.05 just now
assuming something 57.4fps
0.01. this will effectively disable skew functionality so it will be less smooth, right speed, right pitch.
the default 0.05 will skew it.
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
pi has vsync and it’s on by default. yes, retroarch will always send 60 fps to your 60 fps display, but (with the skew feature) it will speed up a 57.4 fps game to true 60, rather than hold ~3 frames every second to for 2 frames, to judder it to an effective 57.4 speed.
If the FPS are being delivered slower or faster than the monitor refresh rate then tearing can occur. It's really about being out of sync. If they are delivered slower vsync will try to match the FPS to a multiple of the monitor say 30, 60 or 120. If faster then vsync isn't doing much usually. I believe what you're saying but I think this could be better explained or use different words possibly? Slowing down the FPS makes sense but speeding up FPS isn't really what vsync does and seems more like a core/code thing.
Maybe it doesn't matter but once you go down the road of using words "loosely" when they don't seem to be correct then it becomes the gospel and everyone starts using incorrect terminology. Such as vsync is speeding up FPS when really that just sounds silly as vsync can't make your hardware run faster but tries to sync the two. Doing some fancy coding can work magic for your FPS it seems though.
I see a lot of threads of people writing buffers for vsync on the Pi or messing with timings in scripts but where are you getting your Pi vsync information from? Do you have some links by chance?
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@dankcushions what audo scew setting should i put in for 2003 i just want to se if its smoother video wise if its better we will just use that way not a debate here just want the best way implemented im 0n 0.05 just now
assuming something 57.4fps
0.01. this will effectively disable skew functionality so it will be less smooth, right speed, right pitch.
the default 0.05 will skew it.
ok will retest with 0.01 0.03 seemed to work after a restart
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.