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:
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
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@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
Well the defaults are up to them at the end of the day I guess. They would need good reason to change it. To be honest it was us sending too any samples per frame for the games frame rate that is the cores fault for doing that
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
They would need good reason to change it.
you can see from the link there is already support to change it.
To be honest it was us sending too any samples per frame for the games frame rate that is the cores fault for doing that
right, the core should be sending less samples per frame, but not hiding the true framerate from the api, but we've had this discussion.
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
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))
Well the statement above implies something about vsync but I'm not sure what. I don't understand what you're trying to say hence the original comment. If you could skew up to a true 60 FPS vsync wouldn't really be needed. Are you saying the skew feature shuts off vsync automatically based on the FPS set by the core?
If it can hit 60 FPS exactly vsync is turned off by the core but if it can't vsync is turned on (left on)? You said it's always on.
Even if you turn vsync off the monitor is still running a 60Hz refresh. Your saying skew calculations are discarded when vsync is off after you said it's always on?
What is the refresh rate of the monitor when it's turned on for a game that isn't a perfect 60Hz? If it's not perfectly inline I would suspect tearing and other anomalies will follow? So this is confusing.
If you can't hit 60Hz exactly you don't really get an option to change the refresh rate of the monitor (special video cards already do this).
Matching the content delivered is more in line with what gsync does which changes it's refresh rate based on the content delivered. High end monitors used gsync vs vsync but all hardware needs to be aware. Isn't the point of the skew feature to match the monitors refresh rate and not the other way around that which would be simple ol' vsync.
Your explanation seems to lack information to sufficiently explain it was the whole point of the statement of saying maybe you should use vsync loosely.
If you wish to explain it better so it could be documented more clearly that would be a great help in understanding because what I read it doesn't really make sense. It seems like "bad" explanations are more about a lack of knowledge and understanding. This is where a MAME programmer would come in handy that could truly explain the process of what's between syncing odd resolutions to a monitors native refresh rates which never aligns perfectly for back in the day arcade games.
I thought the whole point of the conversation was to clear up all this confusion and explain this feature better so Mark could document it. If you have a better explanation of the process that would really help many people in understanding.
-
@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:
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))
Well the statement above implies something about vsync but I'm not sure what. I don't understand what you're trying to say hence the original comment. If you could skew up to a true 60 FPS vsync wouldn't really be needed. Are you saying the skew feature shuts off vsync automatically based on the FPS set by the core?
no, what i'm saying is that if you don't skew a 57.4 game, and have vysnc on, by definition you will get judder. 57.4 is not a factor of 60, so the retroarch GL (or whatever) driver has to dupe a few frames every second to maintain sync. if you don't have vsync on, with a 57.4 game, and don't skew, you get tearing.
what the skew does is mean that the 57.4 game is sped up to match your display hz, so that vsync on does not cause a judder. yes, i suppose you could effectively disable v sync at that point, but my understanding is that if you disable v sync, it will assume you're happy with tearing and not both to skew anything. you could test this if you wanted.
If you wish to explain it better so it could be documented more clearly that would be a great help in understanding because what I read it doesn't really make sense. It seems like "bad" explanations are more about a lack of knowledge and understanding.
i understand it perfectly. i'm not here as your resource. if you don't like my explanations, then feel free to research the issue yourself, rather than insult. the code is there, and other explanations are there. there are also retroarch forums, discords, irc channels and so forth.
I thought the whole point of the conversation was to clear up all this confusion and explain this feature better so Mark could document it. If you have a better explanation of the process that would really help many people in understanding.
i think mark has already achieved that in his wiki page. you can try and drill more information from me but i think we've long established that you are incapable of doing that. can we not?
-
I thought the whole point was to help each other understand and utilize that knowledge as a resource. That was the point of the conversation. To utilize someone else as a resource for proper information so a Wiki article could be created clarifying the confusion.
I was sincere in my lack of understanding and questions asked. Saying an explanation is "bad" is in no way an insult. I guess I could have used a different word but I have no idea what hence the use of quotes to add your own word here.
Thanks for whatever this statement means...huh?
you can try and drill more information from me but i think we've long established that you are incapable of doing that. can we not?
What??? Can we not what? Incapable of doing what? What are you talking about? I have absolutely no idea what you're trying to say or asking here even but I imagine it wasn't a friendly gesture. Clearly something's gone awry. You're right I'll stick to my side of the fence at Github or wherever and do my own research from here on out when I need help. Thanks Dan.
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.