mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support
-
@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.
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@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.
how to you want to handle midway games then ?
-
@grant2258 all i’m telling you is how the feature works. i don’t want to work on anything.
-
okies well we are changing the sample timing slice to 22050 for games below 47 in mame2003 atm to get them working atm was just asking how to apply this to these games was all so we can remove it. Notice i said timing slice not sample rate
-
But people must also enable 'Advanced' options in retroarch before they can even see the skew options.
-
@maxbeanz said in mame2003-plus: 250 new games, new input system, new features, new bugs:
But people must also enable 'Advanced' options in retroarch before they can even see the skew options.
well i dont see any advantage with this over the way mame2003+ is doing it. It is good to know how it works though.
-
@maxbeanz said in mame2003-plus: 250 new games, new input system, new features, new bugs:
But people must also enable 'Advanced' options in retroarch before they can even see the skew options.
right, becuase it’s an advanced feature that effectively no-one should be changing. it should have a default that is sensible.
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
that effectively no-one should
I think it would an advantage to add this to retro-pie defaults
-
@grant2258 i am fine with the defaults as retroarch provide them. i don’t think we should override them when it’s not a retropie-specific thing. retroarch are open to change. no one but me* has ever asked, despite the 100s of posts about this.
*=i was going to get them to change the default but then i changed my mind: https://github.com/libretro/RetroArch/issues/4662
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.