lr-mame2003 driver improvement and backport

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

Riverstorm

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

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.

Ah, ok, that would free up 2 buttons then as I did 4 buttons for players 3 & 4 thinking like NeoGeo games but not sure. I shaved off 4 buttons from player 1 as I figured 6 is good enough.

I tried following IPAC inputs that are mainly the same as the 'MAME default' inputs except for player 4 which used the keypad back in the day. If I left it on the keypad that would free up plenty of characters as directional inputs use letters too. But my wireless keyboard has no dedicated keypad and shift characters tend to be a challenge for general input buttons.

Thanks for the vector settings I will test them out and see how they look. I think to compete will AdvMAME it will need all the options available. I am not sure if you ever looked at AdvMAME but I can post a pick of Tempest or something as following Cavers vector doc they look pretty incredible.

markwkidd

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

Thanks for the vector settings I will test them out and see how they look. I think to compete will AdvMAME it will need all the options available. I am not sure if you ever looked at AdvMAME but I can post a pick of Tempest or something as following Cavers vector doc they look pretty incredible.

I started to post a link to the RetroPie forums thread pertaining to the mame2003 vector rendering bounty, but I guess we don't have a thread for that in these forums. Maybe there should be.

There is a github issue for it: https://github.com/libretro/mame2003-libretro/issues/332

And there is currently an $80 bounty for solving the problem.

Your screenshots of AdvanceMAME would be welcome in that issue, especially if they can show tempest with a similar screen to the comparisons I've put up between MAME 0.78 and mame2003.