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

robertvb83

it seems like such button naming DB is already existent! there is a controls.ini / controls.dat / controls.xml file. I cannot find one that is later than 0.141.1

there is someone who made a github project to convert controls.xml into controls.json here. which is discussed here

it looks like something that could be used here?

markwkidd

@robertvb83 said in mame2003-plus: 250 new games, new input system, new features, new bugs:

it seems like such button naming DB is already existent! there is a controls.ini / controls.dat / controls.xml file. I cannot find one that is later than 0.140

there is someone who made a github project to convert controls.xml into controls.json here. which is discussed here

it looks like something that could be used here?

I think you are really onto something here! It might be possible to write a script that parses the controls.dat/ini/xml and turns it into something that can be automatically added to mame2003-plus. BTW MAME 0.140 is probably a good starting point anyway.

I have some ideas based on your post on how this could be implemented at a large scale and it's killing me not to be trying the ideas out right now! hehe

robertvb83

@markwkidd ok i guess then the old approach is not so relevant anymore, however i testet street fighter and it works perfectly

also ingame the functions are represented correctly!

markwkidd

@robertvb83 said in mame2003-plus: 250 new games, new input system, new features, new bugs:

@markwkidd ok i guess then the old approach is not so relevant anymore, however i testet street fighter and it works perfectly

also ingame the functions are represented correctly!

Yay, thanks! That is definitely relevant. Starting with a solid baseline is something I have started to appreciate as a philosophy when it comes to input code.

grant2258

you should be able to grab all this info from the latest mame with xml or any other list function it provides and parse it with python. just be careful with the usual rom zip name changes ect because different revisions of roms sometimes user different inputport settings

Darksavior

Looks like the system32 games have a lower pitched audio. Not sure when it started. The bug is only in Plus. Original 2003 is fine.

grant2258

@darksavior said in mame2003-plus: 250 new games, new input system, new features, new bugs:

Looks like the system32 games have a lower pitched audio. Not sure when it started. The bug is only in Plus. Original 2003 is fine.

yea does seem off but so does the driver I compared the cpu speeds and ym speeds in lastest mame and they dont match up with the speeds our driver has. mame2003+ aims to run the at the speed the hardware intended. I could be a glitch in timing system as well cant rule that out.

You can see mame2003+ when playing data east games. mame2003 just plays these games too fast the pitch is completely in them. I dont know how fba handles robocop if its running 60fps the pitch will be wrong like mame2003.

markwkidd

Is this one of those issues which can be resolved by turning off/down the RetroArch 'audio stretch' function?

grant2258

@darksavior said in mame2003-plus: 250 new games, new input system, new features, new bugs:

Looks like the system32 games have a lower pitched audio. Not sure when it started. The bug is only in Plus. Original 2003 is fine.

I tested in mame078 mame2003 mame 2003 plus none of them are correct to current mame in pitch its more pronounced in mame2003+ because the timing of the driver wrong

grant2258

@markwkidd said in mame2003-plus: 250 new games, new input system, new features, new bugs:

Is this one of those issues which can be resolved by turning off/down the RetroArch 'audio stretch' function?

its just not right none even in mame 078 mark

the ym soundchips are different speeds and the other soundchip i cant remeber the name of is off speedwise as well in the driver. It would need updated to work properly on all versions of mame2003 if fba is the same as mame2003 something is wrong there too

grant2258

@markwkidd here is the difference between mame2003 and mame2003+ its easier to tell on this game start ddragon2 its 57.44 fps youll clearly hear mame2003 is playing the audio to fast and the game as well

dankcushions

@grant2258 turn down/off audio skew and mame2003 plays them at the right speed. there's no bug.

markwkidd

I am curious about how it sounds with Audio Skew turned off.

Regardless of the results of that specific test, I am reminded of a thought I had in the past.

Are there downsides to recommending that people in general disable Audio Skew for the mame2003-plus core or turn it down to some amount below its audible threshold?

The minimum audible Audio Skew number was determined somewhat informed manner in a libretro forum thread that I can find now that I have the right term.

dankcushions

@markwkidd said in mame2003-plus: 250 new games, new input system, new features, new bugs:

Are there downsides to recommending that people in general disable Audio Skew for the mame2003-plus core or turn it down to some amount below its audible threshold?

yes - the point of the default skew setting is to skew (speed up/slow down the audio/video) games that are close to 60FPS to 60FPS (or, whatever your screen hz is). otherwise, you get judder with vsync. the use case for this was NTSC games with strange 60.X timings, i believe.

now, i personally think the default setting is a little too large (you can easily notice the effects skewing a 57.4fps game), but that's a retroarch problem. i think they would be open to lowering the default. i think that's a much better solution than getting the users to mess with the settings, or fooling the API until it thinks you're running a 60fps game.

grant2258

yea need to get that magic number to test it out. The think that confusing though is games like mk and stonebal (i just found out about this one) are working ok on mame2003 without the audio scew it just seems the 57 fps are getting chomped by this. On our end 2003 what we are doing is only playing 57.4 worth of sample time its the audio timing of 48k taking the 60fps time that pushing the framerate up with the audio scew as is. I originally thought the timing changes the samplerate it doesnt. The only way you can change the sample rate is with ra settings as far as i can tell

markwkidd

OK I will locate the libretro forum thread about the audio skew and see if RetroArch is amenable to a PR lowering the default. If not maybe it's worth a note somewhere in the mame2003-plus docs.

On this theme, in a general way:
@dankcushions I would also really like to help create a PR to add the "RetroPie udev ordering patch" to RetroArch as an option in the cfg. I know there is an issue about it that you participated in but I think that's could be another example where a PR is the best way to communicate with RetroArch.

Unfortunately I haven't yet added a RetroArch cfg option so I'll need to learn.

grant2258

@markwkidd we dont need an audio screw for mame2003+ only 2003 needs its atm setting it shouldnt effect us at all we are within the ra timing system not fooling anything just playing the sames sample frames per second to what it shoud be can add both options as a core setting if you like though. Midway will have to be the new way 30fps is too much for audio scew as far as im aware

markwkidd

@grant2258 and @dankcushions can you take a look at the post James-F makes here: https://forums.libretro.com/t/default-audio-rate-control-delta-value-0-005-is-bad-and-quite-audible/15129/36

That is the key message -- that this audio_rate_control_delta is only used when there the frontend does not have accurate refresh rate about the user's monitor or when then monitor's refresh rate is varying wildly. There are other posts on this theme here and there in the thread including some from Dwedit that might be relevant.

James-F describes a procedure to manually set the refresh rate. Is anyone willing to try this?

If I understand James-F, then that maximum skew amount should never be necessary because the feature is more intended to adjust between 60fps and the framerate/refresh rate supported by the user's monitor than it is meant to be adjusting between the framerate of the emulated game and 60fps.

If the refresh rate is not getting set automatically accurately by something in the RetroArch-Rasbian-Hardware monitor path then the audio winds up getting compromise when the total difference reaches a certain point.

So if that's true, the solution really isn't lowering the maximum skew which would fix the audio but introduce video problems, but do a better job to set the refresh rate for the user's system. Anyway this is yet another area I'm not familiar with.

Hmm.

dankcushions

@markwkidd said in mame2003-plus: 250 new games, new input system, new features, new bugs:

That is the key message -- that this audio_rate_control_delta

different setting. the one that affects us here is audio_max_timing_skew

it's a very simple setting and you can see the effects very easily. i encourage you to test with it.

dankcushions

@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:

we are within the ra timing system not fooling anything

if a 57.4fps game is not reporting 57.4fps to timing.fps, it's fooling the system. if it's reporting it correctly, the default audio skew will skew a 57.4fps game to 60fps, every time.