testers invited for upcoming MAME 2003 stable release
-
@grant2258 said in testers invited for upcoming MAME 2003 stable release:
reset game removed from mame tab menu (same in plus)
As far as I know the libretro reset function is hooked into the same code as was formerly in the MAME menu. Unless there is a functional difference I think this is OK.
-
i know it hooked up to the reset function I just dont see why there is a need to remove it the tab menu ?
-
@grant2258 said in testers invited for upcoming MAME 2003 stable release:
no notification of working clones (same in plus)
There should still be the 'legacy' clone notification in MAME 2003 as of the current commit.
Should the new stackable widget notifications get re-added to RetroArch soon (they got reverted last night due to an OS X issue) I would consider migrating the working clone notifications entirely to the libretro frontend here in MAME 2003, but for now the clone alerts should still be appearing in the good old fashioned way.
-
unfortunately this isint the case start moonwalk you go straight to a segfault both in plus and 2003
-
@grant2258 oh my. I had that bug with
moonwalkin 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.
-
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
-
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
moonwalkin 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. :)
-
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
-
@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.
-
@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.
-
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
-
@grant2258 I'm going to add the hardcoded A and B to the TODO list alongside the analog input API for now
-
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
-
@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
-
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 -
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.
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.