lr-mame2003 driver improvement and backport

Riverstorm

@AndersHP - Also remember right now it's still experimental. It's in that section. It's in a very rapid development cycle and some things might be broken and fixed an hour later. I've downloaded from source 5 or 6 times this past week.

You can definitely make it your preferred emulator (especially if there's new games that are favs) if you have the correct ROMs to build a set and are alright with some occasional quirky behavior.

You can also pull only the new/updated ROMs that run only in Plus and use the Arcade folder that allows multiple emulators for one platform. I can make a DAT for that too.

Any testing and feedback is great of what works and what's broke. It might become the preferred emulator down the road or merged with lr-mame2003 down the road. It's hard to say as folks higher up will need to decide a course of action.

dankcushions

plus has had issues with failing builds and so forth. it will get there! just be patient whilst development goes on :)

edwardthehuman

When I install this I get:
Could not successfully install . /home/pi?RetroPie-Setup/tmp/build/lr-mame2003-plus/changed.txt not found.

Then it tells me to see the log to see what the error was about. TO whom can I provide the log file?

mitu

@edwardthehuman What version of RetroPie are you using ? I remember this has been corrected a few versions ago - you should update your setup script to 4.4.

edwardthehuman

@mitu Hi, i tried it first using 4.3 and didn't work. So I just updated it to 4.4 and still the same result. Thanks

mitu

@edwardthehuman It seems the github repository is undergoing a few changes which have not been picked up by the install script. Wait a few days until things settle down and I'm sure it will work again.

edwardthehuman

@mitu Okay I will wait a few days before installing it again. Thank you

markwkidd

I think this PR should update RetroPie-Setup the way it needs to in order to compile again: https://github.com/RetroPie/RetroPie-Setup/pull/2369

I've been making changes oriented towards having a long-term stable period in the repository. I've updated the license and documentation within the repository to match github convention.

I've also been removing one of the layers of abstraction between libretro and MAME around file handling functions. There's a bit more to do but the end is in sight. Not the sexiest section of the code, but this project is intended to make it easier for new developers to come along in the future and understand how mame2003/mame2003-plus locates, loads, and handles files internally.

grant2258

@markwkidd said in lr-mame2003 driver improvement and backport:

I think this PR should update RetroPie-Setup the way it needs to in order to compile again: https://github.com/RetroPie/RetroPie-Setup/pull/2369

I've been making changes oriented towards having a long-term stable period in the repository. I've updated the license and documentation within the repository to match github convention.

I've also been removing one of the layers of abstraction between libretro and MAME around file handling functions. There's a bit more to do but the end is in sight. Not the sexiest section of the code, but this project is intended to make it easier for new developers to come along in the future and understand how mame2003/mame2003-plus locates, loads, and handles files internally.

I seen youve been doing quite a bit of work mark. I noticed issues when changing the sample rate the changes your doing are needed and appreciated. It could be a wild guess where a variable was being set at times in the options

markwkidd

@grant2258 I actually started out just wanting to clarify how the paths were selected for the various filetypes, specifically with samples in mind. Of course it got to be a bigger project than that as these things do.

I would still like to simplify the file path section but I think with my latest PR I am done for now. Assuming there are no regressions.

The only other project I have is to try figure out why I don't have access to the libretro logging interface at some times when I think I should, for example when samples are being loaded. I've been told in the past to try to avoid logging to printfbut I must not understand something about the libretro log callback because it's not always there when I need it.

markwkidd

One nice thing that is happening today is that twinaphex is putting in time updating the Makefile and updating some other mame2003-plus components. It's good to have the lead dev working in the codebase every once in a while I think :)

grant2258

@markwkidd would need an example in the code to see where you need the logging to work and it's not. I can take a look if you like

markwkidd

@grant2258 said in lr-mame2003 driver improvement and backport:

@markwkidd would need an example in the code to see where you need the logging to work and it's not. I can take a look if you like

Thanks, I keep putting this off. The background to this is that twinaphex asked in general for me to not add more printf logging, so I'm trying to use libretro's log system to the greatest extent possible.

Here's some logging code that I think should be executing with any game that supports samples: https://github.com/libretro/mame2003-plus-libretro/blob/master/src/common.c#L260

I'm not seeing that logged to in the console in --verbose mode.

From my understanding, log_cb should already be initialized here: https://github.com/libretro/mame2003-plus-libretro/blob/master/src/libretro/mame2003.c#L480-L483

I assume it's that I don't understand something about libretro logging.

I could just try to initialize log_cb again in common.c like it's done in mame2003.cbut that seems like an ugly way to go.

   struct retro_log_callback log;
   if (environ_cb(RETRO_ENVIRONMENT_GET_LOG_INTERFACE, &log))
      log_cb = log.log;
   else
      log_cb = NULL;

Riverstorm

I was running some games through mame2003_plus. Basically the games I have in my list around 330 or so to see how they performed. I found a few errors. Would you rather see these posted over at Github as a ticket?

Arkanoid (US) (arkanoiu) - Player 2 flipped upside down (vertically)
Dragon Spirit (dspirit) - Player 2 filled upside down (vertically)
Kick (kick) - Player 1 and 2 only flip horizontally (lays on left and right side)
D.D. Crew (ddcrew) - Crashes black screen
Pig Newton (pignewt) - Crashes black screen
Vector games seem to work but look awful. I couldn't find the settings for beam intensity, beam thickness, flicker, etc.

Games that seem to work great in mame2003_plus. I had these previously running AdvMAME as it seems to handle all games fairly well but it was nice to seem them running in plus:

Demolition Derby
Puzzle Bobble / Bust-A-Move
Puzzle Bobble 2 / Bust-A-Move Again
Rampage
Skull & Crossbones
Xenophobe

@markwkidd - Do you know where the settings are for Libretro defaults you linked up the thread? I know it's not in all/retorarch.cfg. I can't find those settings anywhere. When testing 4 players with a keyboard it's a pain to have double inputs etc. I have all 26 alphabet keys assigned and the overlap with certain games makes them impossible to play. I do have all the keyboard keys memorized for 4 players though. :)

markwkidd

@riverstorm said in lr-mame2003 driver improvement and backport:

Would you rather see these posted over at Github as a ticket?

In general, yes it's good to have information logged in github when it gets down to specific titles and you have done the testing already.

Arkanoid (US) (arkanoiu) - Player 2 flipped upside down (vertically)

Dragon Spirit (dspirit) - Player 2 filled upside down (vertically)

Kick (kick) - Player 1 and 2 only flip horizontally (lays on left and right side)

D.D. Crew (ddcrew) - Crashes black screen

Pig Newton (pignewt) - Crashes black screen

I think everyone who is working actively on mame2003-plus is more or less reading this thread, but this is definitely good material to start a github issue.

Vector games seem to work but look awful. I couldn't find the settings for beam intensity, beam thickness, flicker, etc.

For mame2003-plus binaries built in the last week or two there are working core options for vector intensity, thickness, and flicker. There is a core option for increasing the resolution that doesn't work right yet, and there is a new disabled option for antialiasing that is subject to a bug.

@markwkidd - Do you know where the settings are for Libretro defaults you linked up the thread? I know it's not in all/retorarch.cfg. I can't find those settings anywhere. When testing 4 players with a keyboard it's a pain to have double inputs etc. I have all 26 alphabet keys assigned and the overlap with certain games makes them impossible to play. I do have all the keyboard keys memorized for 4 players though. :)

retroarch.cfg is indeed where those keybindings are found. It may be that if some have a default setting they don't show up. The bindings can be changed from within the RetroArch XMB GUI as well as by editing the cfg file by hand.

If you're going to use a keyboard for mame2003 and bypass the RetroPad input abstractions, I'd set up a core override cfg for mame2003 and unbind everything to nul that's listed as Gameplay Controls here: https://docs.libretro.com/guides/retroarch-keyboard-controls/#retroarch-keyboard-gameplay-controls

Then I'd suggest looking through the rest of that RetroArch Keyboard Controls doc and bind any other keys that conflict with the mame2003 keyboard input scheme.

grant2258

@markwkidd Mark use two simple printf statements

one where the log is initialized
printf("starting the logging here");
one on src/mame,c printf("want to log here");

as far as i can see src/mame.c is used before retroarch is initialised
i could be though I was just glancing at the code

struct retro_log_callback log;
if (environ_cb(RETRO_ENVIRONMENT_GET_LOG_INTERFACE, &log))
log_cb = log.log;
else
log_cb = NULL;

i thing your going to have to either do a extern retro_log_callback log; or start the log again when its outside the retroach env. I dont think there is any way round this

markwkidd

@grant2258 yes that would be a simpler way to move forward. SMH. I'll take that approach this evening when I get some more coding time.

Riverstorm

@markwkidd said in lr-mame2003 driver improvement and backport:

For mame2003-plus binaries built in the last week or two there are working core options for vector intensity, thickness, and flicker.

I rebuilt from source over the weekend. Are the option names and parameters documented anywhere? At defaults they are very thick and bulky.

It may be that if some have a default setting they don't show up.

Thanks, yeah, that's right I need the 'mega' retroarch.cfg to get the specific option name or write out a core override within RGUI. I was spinning on that one for a long time. Thanks.

I use a keyboard as I don't have a 4 player cab and 4 controllers is clumsy to test so I use the keyboard as the next best alternative for testing 4 player games with all players running in game.

I will try your suggestion. I am open to all options. Over the weekend I was testing and certain keys for certain players would do weird things until it dawned on me what was happening. I usually don't see those issues with 1 and 2 players or even with 4 controllers but 4 on a keyboard or an IPAC looks to be a challenge to map everything without overlap. I even had to cut players 3 and 4 short to only 4 buttons. We need a few extra alphabet letters. I think for mapping like GPIO or an IPAC to keyboard equivalent inputs you would need to use the keypad also. There's just not enough characters for 4 players.

A few years back I did a GPIO input setup that works good but would give some issues when you would use things like a semicolon, etc. basically certain characters didn't translate well to GPIO input with RetroPie.

I will open a ticket over at Github. I didn't even make it half way through my game list. I kept getting sidetracked playing...errr....testing games. I will add more as I work through what I have loaded in my list. Any other games you need tested just let me know.

markwkidd

@riverstorm said in lr-mame2003 driver improvement and backport:

I even had to cut players 3 and 4 short to only 4 buttons. We need a few extra alphabet letters. I think for mapping like GPIO or an IPAC to keyboard equivalent inputs you would need to use the keypad also. There's just not enough characters for 4 players.

I ran into this issue of limited keys while mapping Player 3 and Player 4 for mame2010. MAMEdev says that there are no three-player and four-player games with more than a certain number of buttons. I cannot say for sure but my recollection is that no arcade games with 3 or 4 players have more than three (3) buttons per player.

If that's true, it's no problem to have fewer buttons available for the third and fourth players.

markwkidd

@riverstorm said in lr-mame2003 driver improvement and backport:

I rebuilt from source over the weekend. Are the option names and parameters documented anywhere? At defaults they are very thick and bulky.

The new vector-related option names aren't documented anywhere that I know of yet but you can take a look at this few lines of code: https://github.com/libretro/mame2003-plus-libretro/blob/master/src/libretro/mame2003.c#L147-L152

APPNAME is a macro that becomes mame2003-plus, so the options have names like mame2003-plus-vector-translucency