Weird Mouse Cursor bug in MAME (non-libretro)
-
Yeah - asking on the MAME sub is useless, because this problem only affects the Retropie build. Standalone MAME on Linux or Windows doesn't have this problem.
and yes - once I point out it's the Retropie build, they will either ignore or flame me.
and No, LR-MAME high score saving doesn't work. It's not implemented correctly in Libretro. Even putting all teh configs in the correct place and editing the various INI and config files to mirror the setting of standalone does nothing.
Also - LR-MAME can be a little laggy/audio stutters, whereas the standalone MAME build doesn't. The LR API memory usage nudges it just enough not to be perfect.
-
@JSM said in Weird Mouse Cursor bug in MAME (non-libretro):
No, LR-MAME high score saving doesn't work. It's not implemented correctly in Libretro
As i said, it actually does work, i remember someone posting the method a few months ago, iirc you have to change some core options additionally to the mame config file editing.
@JSM said in Weird Mouse Cursor bug in MAME (non-libretro):
Standalone MAME on Linux or Windows doesn't have this problem.
My 2 cents : MAME standalone dislikes running on a headless system.
-
@barbudreadmon None of this addresses the fact that the Cursor bug is, infact, a bug. It shouldn't display the cursor when launching a game. Period.
-
@JSM nevertheless, it's not a retropie bug. retropie just builds MAME from https://github.com/mamedev/mame/ - it sounds to me like it's a historical problem with borderless window modes - a windows install probably doesn't have this issue by default, and maybe neither a linux install with X.
perhaps you could try adding the -nomouse argument to the mame launch command in
/opt/retropie/configs/mame/emulators.cfg- however it seems that might have issues - and apparently it's the default anyway(although i don't recall having this same issue the last time i tried MAME in retropie, but it's been a while)
-
@barbudreadmon said in Weird Mouse Cursor bug in MAME (non-libretro):
My 2 cents : MAME standalone dislikes running on a headless system.
Probably because is not a common configuration on Linux.
@JSM you may try to run it under a desktop session and see if it behaves differently.
If it works, you can install thematchboxwindow manager and modify theemulators.cfgconfiguration file and prependXINIT:to the standalonemamelaunching command. Runcommand will take care of starting thex11session and the emulator. -
This sounds like it's probably a great work around.
Stupid questions:
-
Is matchbox available to install from the retropie config menu, or do I have to do a manual install? (in which case I would need to know the command line to get the install downloaded and running.)
-
prepending XINIT - a little more detail on this would be helpful. Where is XINIT stored, and are you saying just copy and pasted the edited MAME standalone launch command into it, or is XINIT a protocol? (sorry, I know this is a noob question, but I'm not a Linux expert)
-
-
Is matchbox available to install from the retropie config menu, or do I have to do a manual install? (in which case I would need to know the command line to get the install downloaded and running.)
It's not installable separately, but you can install it via command line (
sudo apt install matchbox-window-manager). If you install thesteamlinkport, then it will be installed as part of the dependencies for it so you don't have to install it manually - I recommend you do this.prepending XINIT - a little more detail on this would be helpful. Where is XINIT stored, and are you saying just copy and pasted the edited MAME standalone launch command into it, or is XINIT a protocol? (sorry, I know this is a noob question, but I'm not a Linux expert)
XINIT:tellsruncommandthat the emulator should be launched in a minimal desktop session and it takes care of launching it for you, without adding any extra scripts. By default, for themamesystem, theemulators.cfgwould contain:mame = "/opt/retropie/emulators/mame/mame %BASENAME%"replace it with
mame = "XINIT:/opt/retropie/emulators/mame/mame %BASENAME%" -
@mitu yeah, thanks for the idea, but this didn't work either.
-
@JSM If standalone MAME can't work properly on a pi, i suppose you'll have to use lr-mame, FWIW i found the post mentioning how to get working hiscores in lr-mame.
Or you could use one of the better libretroized cores, tbh i'd recommend avoiding lr-mame and lr-mame2016 since they can't even display shaders on vertical games properly.
-
@barbudreadmon The whole point of using LR-MAME or MAME standalone was that they are the only ones to produce correct, accurate faithful sound for a number of games. FBneo is a hacky mess that still uses inaccurately implemented samples and speed hacks, and MAME2003 isn't even close to accurate on sound or colors. 2010 and 2016 are crash filled messes.
At the end of the day just telling people "we can't figure out how to fix this minor bug in this universally accepted standard emulator in our RPi platform, so why don't you use this hack-filled inaccurate version that is 18 years out of date" is pretty much the worst version of "help" you can offer. Especially when the person reporting the bugs specifically said, numerous times "please don't suggest other emulators". It's the equivalent of taking your car to the mechanic to get a tire patched and he tells you to buy his used car with bald tires instead.
-
@JSM said in Weird Mouse Cursor bug in MAME (non-libretro):
FBneo is a hacky mess that still uses inaccurately implemented samples and speed hacks
You obviously don't understand what you are talking about, so please stay respectful about people's work. Why do you think FBNeo devs regularily appear on MAME changelog ? Most of the time both emulators will be equally accurate, sometimes one or the other is more accurate.
As for the samples, there is no way a sound directly recorded from the arcade board would be inaccurate, if anything MAME's netlist (their analog circuitry library) is more likely to be inaccurate since it is emulation, meaning there could be bugs in the library (and there probably are, since they have been fixing it over the years) or the handcrafted digital representation of the analog circuitry. MAME's approach might be equally accurate if it has no bugs, but there would still be the drawback that it's more costly ressource-wise.
Don't get this wrong, MAME isn't using netlist because it's "more accurate" (again there is literally no way emulation could be more accurate than the real thing), they are using netlist because this is a preservation project, and it's more worthwile in that context to document a circuitry blueprint than to use recorded sounds.
Also note that FBNeo is actually using both methods : the samples method when proper samples are available, and the analog circuitry emulation when there aren't. There is no need for 2 preservation projects so we prefer a more pragmatic approach.
@JSM said in Weird Mouse Cursor bug in MAME (non-libretro):
we can't figure out how to fix this minor bug in this universally accepted standard emulator in our RPi platform
This is a MAME bug, ask the MAME team.
-
It's not a MAME bug. It doesn't happen in MAME on any other platform. It only happens in the Retropie build. It is a Retropie bug. More specifically, it is a bug in how this specific build of MAME behaves only on Retropie.
Samples are always inaccurate, to varying degrees. These aren't direct digital copies of the audio from the ROM at it's orignal bitrate and waveform bandwidth. They are analog waveform recordings (magnetic media recorded approximations), converted to low resolution digital audio format. They are subject to the quality of the recording format, equipment, and media and knowledge of audio capture engineering used by the sample recorder.
They are the functional difference between an MP3 converted at 128kb and the original master recordings made in a studio on 2inch analog tape (or 96Khz Digital audio capture in Protools, etc.) They are sampled and then converted to a lower resolution (lossy conversion) format to allow for quick playback due to smaller file size, based on game mechanic triggers in the emulation.
I'm not an emulation coding expert, which is why I come here to report bugs for others to correct in the emulators. That is what this forum is for.
But I am a professional audio engineer. I have a bachelors degree in Audio Engineering from Berklee. I work as a studio engineer and producer in one of the premier recording houses on the east coast. While I appreciate that you feel you have to "defend your turf" because you're on the FBNeo dev team, please don't try to lecture me on audio quality.
-
@JSM said in Weird Mouse Cursor bug in MAME (non-libretro):
It's not a MAME bug. It doesn't happen in MAME on any other platform. It only happens in the Retropie build. It is a Retropie bug. More specifically, it is a bug in how this specific build of MAME behaves only on Retropie.
We have no specific patches added to MAME - it's a straight compile from vanilla sources. See here.
I'm not an emulation coding expert, which is why I come here to report bugs for others to correct in the emulators. That is what this forum is for.
Yes, this forum is for bug reports and support. Unfortunately there's nothing we can do to fix the behavior you're seeing - looks to be an upstream bug/issue, as @barbudreadmon mentioned.
When there's something that's Pi specific and we can track it down to a CPU/Architecture issue, we report this ourselves upstream or sometimes we are able to provide a patch. In this case they don't seem to be interested in accepting the bug report and fixing or providing a diagnostic.
-
@mitu It is RetroPie specific, because it does not occur on any other platform. It only occurs in the RetroPie build of MAME. It is not a bug that exists in any other build of MAME, anywhere.
-
RetroPie is not a 'platform' - is just a vanilla RasPI OS (Buster) as distributed by the Raspberry Pi folks. As I said - there's nothing special about our MAME build.
-
@JSM said in Weird Mouse Cursor bug in MAME (non-libretro):
It's not a MAME bug. It doesn't happen in MAME on any other platform.
Again, it is a MAME bug, because retropie isn't applying any change to the MAME code...
@JSM said in Weird Mouse Cursor bug in MAME (non-libretro):
Samples are always inaccurate, to varying degrees. These aren't direct digital copies of the audio from the ROM at it's orignal bitrate and waveform bandwidth. They are analog waveform recordings (magnetic media recorded approximations), converted to low resolution digital audio format. They are subject to the quality of the recording format, equipment, and media and knowledge of audio capture engineering used by the sample recorder.
They are the functional difference between an MP3 converted at 128kb and the original master recordings made in a studio on 2inch analog tape (or 96Khz Digital audio capture in Protools, etc.) They are sampled and then converted to a lower resolution (lossy conversion) format to allow for quick playback due to smaller file size, based on game mechanic triggers in the emulation.
I'm not an emulation coding expert, which is why I come here to report bugs for others to correct in the emulators. That is what this forum is for.
But I am a professional audio engineer. I have a bachelors degree in Audio Engineering from Berklee. I work as a studio engineer and producer in one of the premier recording houses on the east coast. While I appreciate that you feel you have to "defend your turf" because you're on the FBNeo dev team, please don't try to lecture me on audio quality.And yet, when you compare a Donkey Kong cabinet with both emulators, FBNeo actually sounds way closer to the cabinet.
Note that the dkong samples were carefully re-recorded long ago, if you were to use the original samples that were released back around 1998 (probably the ones you refer to with your "magnetic media") then yes, the quality would be bad. -
@barbudreadmon said in Weird Mouse Cursor bug in MAME (non-libretro):
Again, it is a MAME bug, because retropie isn't applying any change to the MAME code...
Just to expand on this and on the fact that's happening only on the 'RetroPie platform' : what's specific to RetroPie is the fact that we're running without a desktop environment (as you mentioned earlier).
This means we're using the RPI SDL's drivers for rendering and event/input handling. There might be issues with that specific RPI driver, which, due to the limited target audience, might not appear on other platforms (PC/X11/Windows/etc.).
However, by running
mamein the desktop env - as tested earlier - means that a well known and used Linux rendering path/driver in SDL is used (X11).Since the issue appears also in this configuration, as @JSM reported, then I don't think the RPI driver is at fault here - as far as this rendering path is concerned, the RPI is just a normal Linux desktop environment. -
@mitu Yeah, only a MAMEdev could tell what's going on since they have the better knowledge of their codepath.
-
@barbudreadmon said in Weird Mouse Cursor bug in MAME (non-libretro):
And yet, when you compare a Donkey Kong cabinet with both emulators, FBNeo actually sounds way closer to the cabinet.
No, it doesn't. Not even close. I've tested it at Funspot in NH with their real cabinets. Plus I played them all in real time in 1981-83.
FBNeo sounds like the NES version. Not the original Arcade version.
-
@JSM said in Weird Mouse Cursor bug in MAME (non-libretro):
No, it doesn't. Not even close.
Sound on the real cabinet isn't muffled the way MAME emulates it. You can easily find videos of the real cabinet with good enough audio to confirm this, and anyway bad audio would muffle the audio but not the other way around. I suppose maybe the amp present on those cabinets isn't emulated by MAME or something, iirc they consider it's not part of the machine. FBNeo won't have this issue since the recorded sounds are most likely already amplified.
@JSM said in Weird Mouse Cursor bug in MAME (non-libretro):
I've tested it at Funspot in NH with their real cabinets. Plus I played them all in real time in 1981-83.
Meaning in noisy environments and/or very long ago.
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.