@mitu i remember adjusting that to see what it does. now i know! looks like i had set it to 0. reset it to 100 and looks like the issues are fixed. think i was over looking this as it was one of the menu options that was opaque when selected, making it hard to read.

thanks for the help!

This topic is a bit old, but I had a similar issue and found the root issue so it may help you or others in the future.
https://retropie.org.uk/forum/topic/28291/right-analog-one-direction-is-ignored/2

Long story short, maybe EmulationStation gamepad mapping configurator 'dead-zone' is too big for your gamepad.

Ok I finally found where this issue was coming from. And it has nothing to do with other controllers afterall.

See the plastic case around the right joystick is not completely flat. Such that the 'Up' direction does not go exactly as far as the other directions in fact.

The axis values setup with uinput were : 0 to 40.
The real ADC values read were :

left-right axis : Between 4(left) and 37 (right) Up-Down axis : Between 6(up) and 38 (down)

So the up direction was 6 units from the minimum value, while the others were only 4 units or less from min/max values. And it seems that was the issue here. This 6 must have been considered inside the 'Dead-zone' of the joystick for the EmulationStation mapping configurator.

After modifying the python script such that the axis setup was between 0 and 36, and reducing the read values of ADC by 4, I now have :

The axis values setup with uinput were : 0 to 36.
The real ADC values read :

left-right axis : Between 0(left) and 34 (right) Up-Down axis : Between 1(up) and 35 (down)

And now it's registering correctly.

Though I think this issue is probably the same for the other topics/gamepads that I found on reddit/this forum. It's probably the joystick "dead-zone" which is too big in the emulationstation mapping configurator for those specific gamepads.

@kay-Row Create an account - where ?

@mitu Sorry, but it seems that I can only edit my posts during a limited time. After some time has passed, the edit option dissappears.

I don't know if it is because I'm a new user or if it is the same for everyone.

Everything seems okay now. I had a Linux system I needed to set up. (Others were in use and I couldn't easily use them for this.) I got it up, added GPartEd (which, interestingly, did not include GPart as a dependency) and read the card from there. GPartEd could not find anything wrong with the partitions on the card, but after I used it to read and very, the card worked when I put it in the Pi!

I didn't write anything to this device, in Mac or Linux, so my guess is that GPart or GPartEd did something while just reading. Maybe it had trouble with a few bytes or when it wrote a date, it updated something else. I don't know, but just reading it and having GPart look at it was enough that the card started working when I tested it.

It's worth noting that when I booted it with my Pi, the system did have issues with partitions and scanned them, but found no errors.

I'll be taking it down and testing it in the arcade setup this evening.

Solved?

The problem was that the pi4 has 2 "connected" outputs (given by xrandrs output), this means that the MODE_CUR array is increased by one (HDMI-1 HDMI-2), and MODE_CUR[5] becomes aspect ratio instead of being the refresh rate, my solution basically looks for /primary/ instead of /connected/... but no clue if that will mess things up for others.

runcommand.sh
runcommand.sh.diff

A 32Gb card would be more than enough for RetroPie + OS, if you intend to keep your games/ROMs (plus scraped artwork) on an external USB disc.

@rostomzer It should work, but if you're updating RetroPie, it will get overwritten and you'll get back the previous version.

Sorry, I got distracted installing Doom and Quake 2.

After downloading a new set of ogg files, I've got the music working. It seem that my files were corrupted.

Now, the only question is how to use mods in lr-tyrquake...

@tomassi said in Amiberry not autobooting lha files:

In the summer I bought a 'retro-frenzy' game console which is essentially a raspberry pi with thousands of games on it.

We don't support 3rd party images, especially the ones sold with ROMs and Retropie. Use the image from retropie.org.uk/forum and if you still have an issue, then open a separate topic and post the details of your system - as detailed in https://retropie.org.uk/forum/topic/3/read-this-first.

@ramco That's weird, I never saw a TV/Remote who shuts down Kodi or the Raspberry, the power button is never assigned to o CEC button, it should only turn off the TV.
Probably it is your TV brand, never heard about that one. Each TV brand as it's own CEC implementation and name, yours might be one of the weakest.
You said you are running Kodi 18.2, Kodi is currently in version 18.8, update it and check, although I doubt it will fix your problem.

oohhhhhhhh. Thank you so much for all your help. Also will this work on a raspberry pi 4?

@Clyde Great! It works perfectly. And thanks also for the detailed explanation!

@mitu and @top-specci FYI, if you want your games to always load at a predefined area (Bypassing a long intro, etc)

Create a save state through Retroarch like normal, find that saved state "yourgame.state" and add ".auto" to the end of it

Ensure that you have savestate_auto_save = "false" and savestate_auto_load = "true" in your /opt/retropie/configs/all/retroarch.cfg file (Or specific config file of your choice)

This will give you the flexibility you need, without worrying that you will override that default save state to load your game by.

@sergioggo96 said in Pegasus Frontend scraping issue:

But once i boot pegasus with this theme Switch OS it doesnt appear anything. Any suggestion?

I'm not familiar with Pegasus and its themes, but are you sure you've run the 'generate' gamelist step in Skyscraper, after it downloaded the artwork for your games/roms ?

@mitu Thanks! I think I isolated the issue though: The refresh rate. I'm not sure why, but with the Pi and the same 32" LG monitor -- smooth at 60hz. When I adjusted the monitor to 50hz and set libretro to match the 2048 sample deviance went down dramatically in all the impacted emus. But I also tweaked a bit too much to be certain that's entirely it -- but that's what it seems to be thus far.

If my fix is a red herring I'll give your advice a whirl too. Thanks for another triage tip!

I have solved it!

It looks like it was the difference between using mame2003_libretro.so and mame2003_plus_libretro.so. I had copied mame2003_libretro.so from the regamebox distribution to the retropie distribution by mistake when I was testing to see if that file was the difference in performance... As can be seen above by my documentation of the command which runs the emulator in regamebox, it uses mame2003_plus_libretro.so.

So, to recap, if you are experiencing the usual slowdowns with double dragon while using retropie distribution and would like to eliminate it, you can just copy mame2003_plus_libretro.so from the regamebox distro into retropie wherever mame2003_libretro.so is... and of course have the settings set to use mame2003_libretro.so. Also, i assume if you install the mame2003_plus core and instruct retropie to use it, the effect would probably be the same.

Hope this helps someone out, I know there is lots of talk about laggy double dragon, and there really is no fix because it is emulating lag which was present in the actual hardware of the arcade cabinet... i've seen posts saying to use the bootleg version (ddragonb.zip) because it was built on better hardware, but this looks like a solid and more appropriate approach to fixing it!