mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support

[maxbeanz]

But people must also enable 'Advanced' options in retroarch before they can even see the skew options.

[grant2258]

@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.

[dankcushions]

@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.

[grant2258]

@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

[dankcushions]

@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

[grant2258]

@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

[dankcushions]

@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.

[Riverstorm]

@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.

[dankcushions]

@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?

[Riverstorm]

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.

[grant2258]

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.

[dankcushions]

@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.

[grant2258]

@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

[Darksavior]

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?

[markwkidd]

@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.

[Darksavior]

@markwkidd I'll try without the nv file. The only audio boost I use is in the alsa mixer and I crank it right below red. I noticed plus had the volume default much higher than normal. I'll check that out with the keyboard.

UPDATE: Deleting the nv file brought back the audio to it's default very low state that normal 2003 also has. I never modified it. No more scratches. I do hear a tiny pop here and there but they're minor..the scratchy audio is what was annoying me. Thanks. My keyboard isn't responding in-game, it's probably a controller priority on my end but problem seems fixed so I won't bother.

[markwkidd]

@Darksavior thank you -- that confirms my overall theory that there is clipping. What is good on my crappy laptop speakers is not a universal default after all. Shocking! LOL.

I will change the default audio level to something in between the factory default and the current default ASAP.

[markwkidd]

The headline for today is that we have closed out Phase 3 of development on the new input system.

This is exciting partly because coders can move to Phase 4, where we finish everything off. The other exciting part is that the Phase 3 input system is now on the master branch for public use.

Three default RetroPad layouts to choose from on a per-player basis

Now you don't have to set one default for all players. In Phase 4 these per-player control layouts will move to the Controls menu, but for now they're still in Options.

By default the MAME Remapper is turned off via a new core option.

This is because:

1. Using the MAME Remapper makes netplay impossible unless both players keep their .cfg files synchronized. (The way I implemented "Dual Joysticks" has the same drawback -- I didn't understand Netplay as well way back then.)
2. As of RetroArch 1.7.3 it should be possible to do any mapping via RetroArch that is possible to do with the MAME remapper.

This is a bold claim and it may turn out that we still need to do some work on the core end to make it true for input devices and games that have't been tested yet. You can turn the MAME Remapper back on, but consider leaving it off to help with testing.

If you are experienced using the MAME Remapper and would like to try to "port" your mappings to be purely RetroArch then that is something we can chat about in this thread.

[grant2258]

I will also be able to give advise to people with drangonwise encoders 6 or 8 button layouts that will work in mame and other cores.

[robertvb83]

@markwkidd @grant2258 this is an amazing work i will try to do some testing later.

is there any controller subtype doing this numbering with my 6 button fighting stick?

i have retropad configured like this
YXL
BAR

for most games including all neogeo i want
345
126
and i understand that this will be achieved by the 6-button layout subtype

but for fighting games like sf2 i like to have
123
456
what should i configure there?

maybe in the end i will end up using
345
123
as my standard so for 3button games i still use only bottom row and for 4 button i will change to snes type yxab
i would be totally fine setting this manually i just want to hear your advice