testers invited for upcoming MAME 2003 stable release
-
To me that code looks identical to the MAME 2003 mapping we had back in April 2018: https://github.com/libretro/mame2003-libretro/blob/f360d9082f1f6cda8d94a2b636112f4bb8b17084/src/libretro/joystick.c#L13-L31
Now I know we aren't talking about cps2.c or the RetroPad declaration but my problem is that I can't remember where to look for the code where RetroPad A and RetroPad B have been swapped. In other words, what did I change to inadvertently fix the swapped buttons?
-
we would need to backtrace the changes leading to this issue imho it will probably be some changes to input structure defaults changing the offsets from the ones that where already saved around that time and deleting the old default.cfg would fix the issue.
The input defaults that werent used should have been set to code none instead of being deleted to maintain cfg compatibility with the original mame. as long as the order doesnt changed it will be right. to fix this properly this should be set back to the original setting in both plus and mame2003
and commits like this.
actually a lot of these default code offsets where changed
the simple truth is your old configs where saved like afc55aaa6374e413d64ee4ac1c943e70dcaa03ef#diff-c7698bf8bb6ee8a6035a02a296c7a9b4
this why i tell people to delete the config files because depending how you game was run and on what config it would changes to that particular data and time.
The setting doesnt matter only the order of it all. You should pay close attention to all the things that where changed in inptport.c back then thats why we have these issues needless hacks changed things
-
edit: Ah hah, that commit is from February 2018, not February 2019 as I first read it. I see what you mean. Already with that commit, pre-existing CFG remaps were invalid.
-
@markwkidd it too late now the files will already be mixed through time and corrupted if anyone has backups from day dot and has run mame with these changes. If you truly want to fix this you should pick one of the inputport.c plus or 2003 or the original(recommended) structures and tell users they have to start again. These files wont work properly on input this game on mame as is
-
@grant2258 I just noticed the link you sent was February 2018 rather than February 2019 as my eyes first saw it. I'm glad I didn't make such a substantial change in my last round of work and then forgotten about it in a couple of weeks -- a year is enough to forget though, lol.
At any rate, my agenda with hacked/non-standard input mappings is to revert them to the way they originally were in MAME. I'm trying not to (further) disrupt existing configurations with my commits right now but as far as I'm concerned it's just a matter of time.
-
@markwkidd just done a mini bisect on the issue date https://github.com/libretro/mame2003-libretro/issues/353
As far as the segfault goes it doing even pre your message changes. It doesnt segfault during a gdb session. I would imagine it some sort of RA windows initialization or race issue. Cant really rule the core out though just cant debug it because its working in a debugger.
I would imagine its probably a race condition that doesnt happen in debug mode because its not running fast enough or some other type debugger initialization that set the memory differntly.
-
@grant2258 said in testers invited for upcoming MAME 2003 stable release:
@markwkidd just done a mini bisect on the issue date https://github.com/libretro/mame2003-libretro/issues/353
As far as the segfault goes it doing even pre your message changes. It doesnt segfault during a gdb session. I would imagine it some sort of RA windows initialization or race issue. Cant really rule the core out though just cant debug it because its working in a debugger.
I would imagine its probably a race condition that doesnt happen in debug mode because its not running fast enough or some other type debugger initialization that set the memory differntly.
Ugh :| It be better if the segfault was because of the messages after all so it could be fixed for real.
-
Well it is crashin in linux as well truns out i had to do a git fetch orin and git merge origin/master. This in itself isint a problem the problem is some emulation will do out of bounds reads thats why there way a key press wait in that message box so the emulation didnt start until you read that message. Its the age old message/confirmation combo that is needed in RA
-
@grant2258 said in testers invited for upcoming MAME 2003 stable release:
Well it is crashin in linux as well truns out i had to do a git fetch orin and git merge origin/master. This in itself isint a problem the problem is some emulation will do out of bounds reads thats why there way a key press wait in that message box so the emulation didnt start until you read that message. Its the age old message/confirmation combo that is needed in RA
There has always been an option to disable all of the pre-emulation messages even in MAME 0.78 so it doesn't seem like they would have designed with the expectation that the messages would display.
-
Not going to waste time debating this just let games not working segault even with messages on. Im passed the point of caring to be honest. Deal with the Ra end any way you like. Ill just be doing updates like arcadez mame specific for plus ill free the thread up for other users dont use this core anyway
-
narrowed the ra bug down to the history files its been fixed was probably corrupted from 1.7.5 if anyone else runs into it just delete the old history file
https://github.com/libretro/RetroArch/pull/7946
https://github.com/libretro/RetroArch/pull/8022 -
@grant2258 said in testers invited for upcoming MAME 2003 stable release:
Not going to waste time debating this just let games not working segault even with messages on. Im passed the point of caring to be honest. Deal with the Ra end any way you like. Ill just be doing updates like arcadez mame specific for plus ill free the thread up for other users dont use this core anyway
It's all good. There are a couple of issues now which are definitely on my plate.
Because I am a little bit lazy I sometimes try I ask you everything you know about the topic before diving in. It's nice in this case it was not only a bug outside the core but it's already been fixed.
-
you should add info for people to delete there cfg files as the formats changed with the refactors. I tested with cfg files that were there already there .
-
Well found another bug not sure when this one crept in but the midway games need fixed again as this was changed during the refactoring.
its broke in plus as well with if you turn off bypass audio skew.
unfortunately the bypass audio skew needs fixed in mame2003 and its off by default. Since you are syncing the cores ill let you decide what you want to do with it.
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.