mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support
-
@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.
-
Well im still at a loss with my way and the audio skew there is no difference visually when both are compared with vsync on or off. Im not sure what the issue is if you can show me a visual difference between ill go with it.
Mame has built in timing functions to deal with vsync by adjusting the audio and video timing as needed as well so the audio and video doesnt get out of sync with each other.
If any user points out and bad effects of my way compared to audio scew ill be happy to change the code at that point.
I really dont see a need to until that day comes. I dont see any extra tearing compared to the audio scew maybe someone else will and tell us how to recreated the situation. If that situation arises it will be dealt with im not stuck on one setting just dont see the problems your saying its causing visually.
-
@grant2258 all i can tell you is that it's a real feature that works. this link has some more info (quite a good explanation, as it goes): https://forums.libretro.com/t/perfect-audio-video-synchronization/12072
you're effectively doing the same thing in mame2003plus already, but the difference is, you are effectively forcing a setting of 'no skew', whereas if you didn't force this retroarch would otherwise allow it to be user configurable. i'm a libretro/RA purist and i think the front end should handle everything it purports to.
i have tried to video the differences before but the judder doesn't really show up on my iphone recordings - at a 57.4 to 60 skew, we're talking ~3 frames out of 60 that would otherwise be juddering.
a proper software capture slowed down would show it, i guess? never attempted to do that.
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@grant2258 all i can tell you is that it's a real feature that works. this link has some more info (quite a good explanation, as it goes): https://forums.libretro.com/t/perfect-audio-video-synchronization/12072
you're effectively doing the same thing in mame2003plus already, but the difference is, you are effectively forcing a setting of 'no skew', whereas if you didn't force this retroarch would otherwise allow it to be user configurable. i'm a libretro/RA purist and i think the front end should handle everything it purports to.
i have tried to video the differences before but the judder doesn't really show up on my iphone recordings - at a 57.4 to 60 skew, we're talking ~3 frames out of 60 that would otherwise be juddering.
a proper software capture slowed down would show it, i guess? never attempted to do that.
well from a purist point i can see where your coming from I just dont know ra inside out. The only thing about RA that really itches my nose is c89! lol
-
I tried mk2 today with latest 2003plus source, and the sound effects are more scratchy than normal 2003. Has that game been given the downport treatment?
-
@darksavior we're trying to "lock in" a lot of things.. it's possible some of this polishing treatment caused an audio regression in MK2. I would like to explore another option that isn't as much of a regression as the consequences of a MK2 audio level fix.
The first thing I'd like to ask you to do is erase your mk2.nv file from inside the saves folder and reload the game to see how it sounds. I don't think this will produce results but before we go down the rabbit hole I want to make sure of the baseline with no nvram file.
I'd also like to make sure that there is no audio boost in your retroarch settings. You might have done this in the past because Mortal Kombat 2 comes from the factory with the volume set very low in the service menu. That has recently been fixed in mame2003-plus, so if you have any other measures in place to accommodate for the low volume you might be overcompensating now that it is fixed by default.
If it still sounds worse than mam2003 at that point, but before I ask you to file a github issue: Do you have a keyboard so that you can enable
mame_keyboard, press F2, and enter the service menu?You should find that the volume setting in the Mortal Kombat 2 service menu is at maximum -- which I believe is what it should be based on my testing on my own system. Maybe somehow it's clipping because of the service menu setting itself. The way to test this is to lower the volume in the service menu -- maybe by 50% -- and see whether you still have the audio quality issues.
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.