mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support
-
@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
-
@riverstorm 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:
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.
right - this is what audio skew does. it changes the game + audio speeds to match the vsync fps, within the skew threshold. please see the new wiki page.
-
@grant2258 0.03 will work also. it’s a simple calculation - it’s the limit of the change the skew will do. 60/57.4 = 1.045. therefor any skew from 0.04 and below will mean a 57.4 game will not skew.
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@grant2258 0.03 will work also. it’s a simple calculation - it’s the limit of the change the skew will do. 60/57.4 = 1.045. therefor any skew from 0.04 and below will mean a 57.4 game will not skew.
ok that makes sense what ive found is visually i dont see a difference when the audio screw is set and mame2003+ way of doing it.
They have the same effect as each other. What i can do is put both options in the core i personally cant see any difference could just be me though. how far can we go with the scew @dankcushions i just want to check framerates and such make sure skew can cover them all.
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
right - this is what audio skew does.
Right, that's what the audio skew does and that's not vsync. There's two things happening here at the same time.
With vsync the monitor is telling the video card to match the framerate. The monitor is controlling the flow of frames. I don't see any mention of the Hz changing on the monitor but more about the delivery of frames through coding.
If I am explaining this to my brother I would probably use vsync but for people here it seems like using proper terminology is more appropriate.
I could call a bison a buffalo and many do because they are similar and they were never taught the difference, maybe they don't care, but why not use the correct terminology. Anyway you get the point and use whatever words you feel are actually correct.
-
@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:
@grant2258 0.03 will work also. it’s a simple calculation - it’s the limit of the change the skew will do. 60/57.4 = 1.045. therefor any skew from 0.04 and below will mean a 57.4 game will not skew.
ok that makes sense what ive found is visually i dont see a difference when the audio screw is set and mame2003+ way of doing it.
They have the same effect as each other. What i can do is put both options in the core i personally cant see any difference could just be me though.
personally i think by putting an option in 2003+ you are duplicating the option in retroarch. retroarch gives you full control of this behaviour.
how far can we go with the scew @dankcushions i just want to check framerates and such make sure skew can cover them all
i don’t understand the question. the skew defaults to 0.05. you can change that to whatever you can change to in the RGUI.
-
@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 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@grant2258 0.03 will work also. it’s a simple calculation - it’s the limit of the change the skew will do. 60/57.4 = 1.045. therefor any skew from 0.04 and below will mean a 57.4 game will not skew.
ok that makes sense what ive found is visually i dont see a difference when the audio screw is set and mame2003+ way of doing it.
They have the same effect as each other. What i can do is put both options in the core i personally cant see any difference could just be me though.
personally i think by putting an option in 2003+ you are duplicating the option in retroarch. retroarch gives you full control of this behaviour.
how far can we go with the scew @dankcushions i just want to check framerates and such make sure skew can cover them all
i don’t understand the question. the skew defaults to 0.05. you can change that to whatever you can change to in the RGUI.
midway games run at 48/48 fps what scew setting for that right now we are dropping the timing rate in 2003
-
@riverstorm 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:
right - this is what audio skew does.
Right, that's what the audio skew does and that's not vsync. There's two things happening here at the same time.
when did i say it was vsync? if you turn vsync off, there is nothing to skew to, so it effectively turns off the skew feature, whatever you have skew threshold set to.
i’m not really clear on what you’re getting at. i know how vsync works.
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
midway games run at 48/48 fps what scew setting for that right now we are dropping the timing rate in 2003
you want to know what skew to set it at to skew a 48 fps game to 60? i gave you the calculation.
60/48=1.25. so skew of 0.25 (0.26 to be safe). that would make them sound and play insanely fast, though.
-
@dankcushions tapper is 30 fps
this is the only time the mame 2003+ way is applied in mame 2003 to let them games run right
-
@grant2258 since 30 is a factor of 60 there should be never any skew of a 30fps game - it can be vsynced perfectly already.
maybe i’m not being clear enough but the default of 0.05 is designed so that games close to your hz can be (imperceptibly to most?) skewed to match it, not to skew all games. if you raise that skew you’re going to have a bad time.
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.