@mitu Yeah, I figured it shouldn't have any effect on audio output. The only audio settings I've changed are in /usr/share/alsa/alsa.conf, where 2 is the number of my audio device:

defaults.ctl.card = 2 defaults.pcm.card = 2

@slug54 said in Need help getting analog sticks working in lr-mame2003 or any version of lr-mame:

If I choose the option for Left Analog Forced

It entirely ignores whether something is already mapped or not to the left analog stick, so i don't recommend ever using that crap. The non-forced option is supposedly safer in that concern, but i have seen reports proving otherwise from people using it.
I'm 99% sure there used to be a core option to map digital-to-analog-left and/or analog-left-to-dpad in some of the vintaged mame cores, but that doesn't seem to be the case anymore.

I'd recommend setting "Analog to Digital Type" back to "none" and using either MAME2003-plus (lr-mame2003-plus) or MAME (lr-mame), both seem to handle this safely out-of-the-box.

Tbh, i don't understand why retropie is still trying to push users toward lr-mame2003 in this day and age, lr-mame2003-plus is the non-arguably improved version of it, and lr-mame run fairly well on newer raspberry models.

Alternatively you could also use FBNeo (lr-fbneo) which also handles this out-of-the-box and offers interesting control alternatives for Battlezone.

@hsamuels said in >5s delay when starting each arcade game:

Does modetest need to check the current and available resolution each time a game starts up? Can it happen once at power-up?

Not sure if you still have the test system around, but we added a modification to runcommand to skip the modeset invocation on systems without KMS (i.e. Pi3 and olders). Give it a try to see if the loading speed is down to the previous timings from the older versions.

@Dochartaigh said in Mame2003 doesn't quite work on Pi Zero 2 W:

@dankcushions said in Mame2003 doesn't quite work on Pi Zero 2 W:

@Dochartaigh said in Mame2003 doesn't quite work on Pi Zero 2 W:

Just did that on my RP4 today (fresh install from your 4.7 image, not trying the new 4.8 I just noticed today yet until bugs are worked out) and it's STILL giving me a 2 year old version of mame2003... Nov 2 2020, 1.8.8.

4.7 release date: 2nd nov 2020

Sorry, missed your post when I replied earlier. So updating 'from source' does NOT give you the newest version? I thought that was the entire point of updating from source like I just did?

1.8.8 is the retroarch version. retropie locks to a tested version of retroarch, so to update it you first have to update the retropie-setup script - option S here:

https://user-images.githubusercontent.com/540857/106713057-e03e2b00-65c7-11eb-9529-766986334e8b.png

then update retroarch in packages > core > retroarch (update via binary or source)

the style of the menus depends on the version of retroarch AND the version of mame2003, but i imagine your version of mame2003 is now up to date. verbose logs remove all doubt and tell us all the versions involved.

This (talking about the RP4 still) also definitely updated since launch of 4.7, no matter what that date says. Like my original post here was about, complete with screenshots, this game wasn't working on the Zero 2, but WAS working on the RP4 (4.7, updated to 4.7.3ish, with 'from binary' mame2003). Like I just posted about, when I updated the RP4 'from source' earlier today (running 'update retropie setup script' first), it now has the same graphical glitches the Zero 2 has... so now I'm completely and utterly confused... ;)

i don't know about the emulation capability of mame2003 so i don't know, but it sounds like the current version has some glitches. you should supply a verbose log to see if there's any clues: https://retropie.org.uk/docs/Runcommand/#launch-with-verbose-logging

@dankcushions said in Noted lr-mame2003 performance issues after RA update to 1.9.5:

@jamrom2 said in Noted lr-mame2003 performance issues after RA update to 1.9.5:

As of now, I set up lr-mame2003 as I need it with a few options, saved the retroarch.cfg once and turned off "save on exit". It's now pulling the video parameters of every game I throw at it based on what I have listed in the file I posted to you.

i guess i'm not totally clear on what you want to achieve. retropie at the basic level has a global retroarch.cfg (/all/retroarch.cfg) which has the baseline settings for all libretro (lr-) emulators. then beyond that there's per-directory configs (eg /mame-libretro/retroarch.cfg) which by default point to an input_remapping_directory, and then defer back to the global config, as you've shown above.

then additionally you can have per-game overrides, per-core overrides, and gamename.ext.cfg overrides. to set up any of these you don't need to ever set 'save on exit' on. it's probably safest to manually create them, actually.

so i'm not sure exactly what hierarchy of configs you want to end up with, and what you currently have.

Ultimately... to not have this happen the next time I choose to upgrade any core part of the build... LOL. I thought I was doing something good by updating RA from 1.8.8 to 1.9.4 then .5. But my build has apparently become so convoluted that I disrupted areas I wasn't aware of.

I'm going to say by adding in the scriptmodules I added more issues than I was aware of. Just the idea that I turn off a shader and I loose performance means something is crossed somewhere.

I'll keep poking around my config files and hopefully find out what's causing some of this. What you and mitu offered was insightful and helped a lot.. but I think this is something that will ultimately leave me with a "it's working good enough" scenario.

@dankcushions said in Need lr-MAME2003 core options for config file:

input_overlay_enable_autopreferred = "false"

Tried this, doesn't work from the local overlay/scaling file that is associated with the rom in the rom folder.

Seems MAME2003 is not reading this file for the overlay size specs anymore. Previously, you had to make a config file that pointed to the overlay, then the scaling and and opacity was set there as well. Did something change because it's not reading this file for those settings anymore, even with the auto-scaling "off" in the On-Screen Overlay menu. The overlay shows, but it's scaling is all screwed up because it only reads the settings in the core retroarch.cfg.

I does read everything else in this file though.

005.zip.cfg

video_shader = "/opt/retropie/emulators/retroarch/shader/arcade-bezel-shader/crt-pi-vertical.glslp"
video_shader_enable = "true"

input_overlay = /opt/retropie/emulators/retroarch/overlays/arcade-bezel-overlays/005.cfg
input_overlay_enable = true
input_overlay_opacity = 0.900000
input_overlay_scale = 1.000000

custom_viewport_width = "741"
custom_viewport_height = "933"
custom_viewport_x = "589"
custom_viewport_y = "70"

video_scale_integer = false
input_overlay_enable_autopreferred = true

**** nevermind... I see what's changed... it's PORTRAIT now. It's reading that setting just fine.

I deleted the old retroarch.cfg and allowed it to rebuild a new one, and there it was.

@mahoneyt944

Hi......

i was about to open a new thread when i can reuse this instead....

You can suggest because the HOME button of XBOX 360 Wired Controller it's can not recognized and i can't bind it anythings to him ?

@dankcushions yeah, from a libretro implementation POV, but afaik lr-mame2003-plus would still be a far better choice than lr-mame2003 if libretro features are what you are looking for.

@iandaemon It was a typo, thanks for noticing.

@mahoneyt944 , @Melvin-FoX Thanks for the suggestion, disabling the digital autocenter did the trick!

Everything is fine now, the site came back online, restarted the install and it went fine till the end.
Thanks!

It works on the 2010 MAME core in Retroarch.

@grant2258 Hi Grant - yes I think I've realised that this is the problem. The default RetroArch setup creates a virtual gamepad and binds both virtual gamepad and keyboard. I think the problem with Defender is that these mappings overlap - so the virtual gamepad is triggering as well as producing a keypress, and these are both bound to different things (eg thrust AND fire).

Thanks for your help!

EmulationStation has the X button mapped for choosing a random system or game. If you're in the system list, X will position you to a random system, if you're in a game list (inside a system), it will position you to a random game - you just have to press A to start the game.
Modifying the existing behavior - to start the game automatically - means you're going to have to program it into EmulationStation - something that's non-trivial for someone that's not familiar with programming or EmulationStation's source.

@dankcushions That's waht i thought. Thank you.

@stoney66 Thanks for that.

I had a look at those cfg files and they all looked fine.

So I did a completely fresh install of RetroPie.

Tried it out, R-Type controls worked fine.

Then I started adding nice tweaks such as ES Themes etc, and suddenly R-Type had the same problem - P1 right not working unless I re-configure the MAME2003 controls every time.

Not sure what change I applied that caused this, so I'm going to do it all again step-by-step and see when it reoccurs.

My gut feeling is this is a bug in the Pimoroni Picade HAT drivers.

did you compile the latest version from source ?

@mitu I redid the controls again for the "v" key (from everything I can tell this is not used elsewhere). This time I used the in game menu with the tab key. Still the right direction does not work. Also I have several existing directional buttons mapped to keys that are used for other functions but all of those keys are functioning normally.

@mitu that was my first thought as well but the retropie user that's being used on my system is already part of those groups.