testers invited for upcoming MAME 2003 stable release

grant2258

unfortunately this isint the case start moonwalk you go straight to a segfault both in plus and 2003

markwkidd

@grant2258 oh my. I had that bug with moonwalk in my local branch and I fixed it. Perhaps I didn't push that commit. Thanks for the heads up on this, for the second time
I believe :)

The good news is that the two codebases are now so closely synchronized that this kind of problem is almost certain to affect both cores and have the both fix both both now. If you count that as good news, which I do.

grant2258

let me know when the fixes are uploaded i using the latest 2003 code compiled myself. Im not sure i like the idea of all this syncing its just breaking plus

markwkidd

I didn't do anything else but running the latest MAME 2003 and MAME 2003-Plus I do not get a crash on moonwalk.

When I load moonwalk in MAME 2003, I still get the usual black box suggesting the bootleg clone:

Not that there isn't anything left for me to do on the frontend messages, just some good news that there isn't a segfault with the current code. :)

grant2258

both are segfaulting for me on clean compiles on windows. i just compiled retroarch to the lastest pull request and got the same. See if anyone else has any issue not worth looking into if its only happening to me.

It seems to be working on retroarch 1.7.5 i even compiled to retroach to 1.7.6 tag deleted all my configs still the same and cleared the mame2003 save folder. Hopefully its just me or something on my system causing it. luckily retropie is still on 1.7.5 as far as i know.

update seems to be working fine in linux will file this one as a windows mystery. Plus doesnt display the message in the window in legacy mode but thats for another thread

markwkidd

@grant2258 As always I appreciate your work and attentiveness on this. I'm going to assume that, for now, MAME 2003 is in a stable place regarding the driver warnings. Edit: I'm pretty sure at some point I must have commited WIP code to the repositories because you're describing a crash that is exactly like one I encountered locally when I was working on the driver warnings. I just want to reiterate that I believe you!

Meanwhile I have thought of some refactoring/simplifying I can do to the driver warning code which I will pursue in Plus. If it turns out there is still a bad pointer lurking around in there it will not hurt to have a cleaner starting point.

markwkidd

@grant2258 said in testers invited for upcoming MAME 2003 stable release:

Retropad Y and A are reversed (hardcoded)

If I understand this issue, it wouldn't be fixable without messing up existing CFGs, right? Or is this an issue where it's possible just to swap the labels for these mappings in the UI and at least have them display accurately?

IIRC we didn't fix this head-on in Plus, but it got fixed as part of the overall overhaul of control mapping. Maybe I'm fuzzy on it though.

grant2258

you would need to ask the people directly involved why this was done. When you say break cfs`s that depends on perspective break configs acording to mame specs or mame2003 specs. Either the person had no idea how the input system works or it was intentional if anyone doesnt want this changed to the way it should be they should make there case

markwkidd

@grant2258 I'm going to add the hardcoded A and B to the TODO list alongside the analog input API for now

grant2258

looked at the code again it appears you already removed this in the re factoring so if its going to break configs you already done it

markwkidd

@grant2258 I've been working so carefully to avoid disturbing MAME 2003 input code over the last few weeks. I didn't change the CPS2 driver at all, which I thought was one of the necessary aspects of undoing the hack. Maybe I did the driver warnings right but messed this one up.

If you're willing to look at this another moment with controller layouts in mind, would you suggest that I revert the "hack" commit to cps2.c now? https://github.com/libretro/mame2003-libretro/commit/ad7f766564e8936656d8707dc3fa671324ba7df1#diff-ab7d24d9c4ec9f0e588623a5f90707b5

grant2258

Im a bit lost here on what your trying to do undoing this with the current layout would map sf2 wrong you only have mame2003 mapping atm.

 	#define EMIT_RETRO_PAD(INDEX) \
    {"RetroPad" #INDEX " Left", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_LEFT, JOYCODE_##INDEX##_LEFT}, \
    {"RetroPad" #INDEX " Right", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_RIGHT, JOYCODE_##INDEX##_RIGHT}, \
    {"RetroPad" #INDEX " Up", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_UP, JOYCODE_##INDEX##_UP}, \
    {"RetroPad" #INDEX " Down", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_DOWN, JOYCODE_##INDEX##_DOWN}, \
    {"RetroPad" #INDEX " B", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_B, JOYCODE_##INDEX##_BUTTON1}, \
    {"RetroPad" #INDEX " Y", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_Y, JOYCODE_##INDEX##_BUTTON2}, \
    {"RetroPad" #INDEX " X", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_X, JOYCODE_##INDEX##_BUTTON3}, \
    {"RetroPad" #INDEX " A", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_A, JOYCODE_##INDEX##_BUTTON4}, \
    {"RetroPad" #INDEX " L", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_L, JOYCODE_##INDEX##_BUTTON5}, \
    {"RetroPad" #INDEX " R", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_R, JOYCODE_##INDEX##_BUTTON6}, \
    {"RetroPad" #INDEX " L2", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_L2, JOYCODE_##INDEX##_BUTTON7}, \
    {"RetroPad" #INDEX " R2", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_R2, JOYCODE_##INDEX##_BUTTON8}, \
    {"RetroPad" #INDEX " L3", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_L3, JOYCODE_##INDEX##_BUTTON9}, \
    {"RetroPad" #INDEX " R3", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_R3, JOYCODE_##INDEX##_BUTTON10}, \
    {"RetroPad" #INDEX " Start", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_START, JOYCODE_##INDEX##_START}, \
    {"RetroPad" #INDEX " Select", ((INDEX - 1) * 18) + RETRO_DEVICE_ID_JOYPAD_SELECT, JOYCODE_##INDEX##_SELECT}, \
    {"RetroMouse" #INDEX " Left Click", ((INDEX - 1) * 18) + 16, JOYCODE_MOUSE_##INDEX##_BUTTON1}, \
{"RetroMouse" #INDEX " Right Click", ((INDEX - 1) * 18) + 17, JOYCODE_MOUSE_##INDEX##_BUTTON2

markwkidd

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?

grant2258

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

https://github.com/libretro/mame2003-libretro/blob/b0142d797cf5caebd2d012acb6fa811de3b0eeb3/src/inptport.c#L403 current

and commits like this.

https://github.com/libretro/mame2003-libretro/commit/afc55aaa6374e413d64ee4ac1c943e70dcaa03ef#diff-c7698bf8bb6ee8a6035a02a296c7a9b4

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

markwkidd

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.

grant2258

@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

markwkidd

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

grant2258

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

markwkidd

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

grant2258

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