testers invited for upcoming MAME 2003 stable release

markwkidd

Current version: MAME 2003 v78.1-beta1

During the last month I have been porting some of the recent additions and improvements from MAME 2003-Plus to MAME 2003 from areas other than the game drivers. This ported code includes functionality like the 4-way joystick restriction core option, support for backdrop artwork, and support for FLAC audio samples.

The intention is to be able to designate a "stable" MAME 2003 release in the next few weeks that benefits from the non-driver improvements from Plus except for certain input improvements that will require MAME 2003 users to delete and recreate custom mappings. (Porting those parts of the Plus code will be reserved for a future update to regular MAME 2003. Let's keep it relatively simple for now!)

I have been testing this code as I port it, and there is no evidence so far of major problems, but testing from MAME 2003 users would be very useful to make sure that the current MAME 2003 code is, in fact, stable. :D

This thead is an invitation to those who are interested in rebuilding their MAME 2003 binary from source: please post here or in the MAME 2003 github repository if you discover any "regressions" that I have introduced with the ported code.

TODO for MAME 2003 v78.1:

Port finalized vector resolution fixes from Plus

TODO for a future stable release

Port libretro analog input API support
Remove hardcoded swap of RetroPad A and RetroPad B
Restore legacy volume mixer UI if it can't be implemented via libretro frontend (seemingly impossible as of 2/2019)
Restore legacy overclocking UI if it can't be implemented via libretro frontend (only possible in a very ugly way as of 2/2019)

grant2258

Volume mixer is missing (same in plus)

no notification of working clones (same in plus)

Retropad Y and A are reversed (hardcoded)

reset game removed from mame tab menu (same in plus)

you receive no notifications at all now if you have fps on and when they do work you dont have time to read them. These messages where at least accessible the way they where in all conditions (in plus and 2003 now as well)

markwkidd

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

grant2258

i know it hooked up to the reset function I just dont see why there is a need to remove it the tab menu ?

markwkidd

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

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.