[Solved] pifba, dpad, source

Efriim

@Efriim
This will download the sources to RetroPie-Setup/tmp/build/'packagename'
sudo retropie_packages.sh 'packagename' sources

This runs the super useful scriptmodule build
sudo ./retropie_packages.sh 'packagename' build

This will move the binaries to the /opt/retropie/ installation
sudo ./retropie_packages.sh 'packagename' install

If a previous build is already configured, this step can be skipped.
sudo ./retropie_packages.sh 'packagename' configure

barbudreadmon

@Efriim said in [Solved] pifba, dpad, source:

I'm having difficulties mapping the dpad for pifba

Why bother with pifba in the first place ? I looked at your old posts, you don't seem to be using pi0/1 (playing n64, dreamcast, ... ?), pifba is inferior to lr-fbneo (previously lr-fbalpha) on everything and by far (access to the dipswitches is only an example), its only redeeming feature is that it's a bit nicer on cpu ressources (thanks to inaccurate emulation), which is a no-concern if you aren't using pi0/pi1.

Efriim

@barbudreadmon
Actually the main reason behind it was, the retroarch-core-options file was really becoming excess with all the fbacore options. Creating a core configuration for other games, it loads this entire file 16kb of data loaded and saved. I found a way around this by creating an options file for each fba game, that way it doesn't flood the retroarch core-options and any option files I create thereafter. That isn't very much, I was just optimizing.
My device is underclocked, but it handles lr-fba just fine. The source edit didn't take very long.

I also wanted to know the breakdown of commands for the package manager, and I found them.

mitu

@Efriim said in [Solved] pifba, dpad, source:

Actually the main reason behind it was, the retroarch-core-options file was really becoming excess with all the fbacore options. Creating a core configuration for other games, it loads this entire file 16kb of data loaded and saved.

I don't think that's the case. The retroarch-core-options.cfg contains about 15 options for the ~~FBA~~ FBNeo core. Any game options are not stored in this file, but in the ~/.config/retroarch/config/<core>/<game>.opt file and it's loaded just for that specific game. The main core options file doesn't get 'bloat', it has the same set of options for the core that only change values.

Efriim

@mitu The core options for fbneo were over 60kb before I deleted all them. Each game takes an additional 32 lines, 22 for control macros and 10 for dip switches. These are saved in retroarch-core-options.cfg. When loading and creating options for games it loads this entire file and saves a custom one for the game, if an option file for the game is created it will load and save that instead. I created individual options for all the fbneo games so it doesn't gather a collection of uneeded options in the retroarch-core-options.cfg

https://pastebin.com/9uF7THz3

mitu

@Efriim said in [Solved] pifba, dpad, source:

When loading and creating options for games it loads this entire file and saves a custom one for the game, if an option file for the game is created it will load and save that instead

How are you creating/saving the game options ?

Efriim

@mitu
I was using the retroarch quick menu. Then I made a bunch with text editor and edited the all of them over the network share. I saved only 5mb of data plus address space.

grant2258

yea have to agree if it is saving the dip switched and all info for every game in the core options file I would probably do the same as you instead of dealing with a huge global core option file. I cant confirm this behavior thanks for sharing the tip. I wonder where standalone is storing all this info will need to take a look out of curiosity.

barbudreadmon

@grant2258 Standalone uses ini files, same as mame. I was also concerned about the size of retroarch-core-options.cfg in the past (i think i even opened an issue a long time ago about this), but i was told it's not a problem for RA, i agree it's a problem if you intend to edit the file by hand though. At the very least it's not storing macros anymore (up to 50 macros per game iirc).

Efriim

@barbudreadmon
Yeah, it was the principality of it, saving and loading game specific options in a global config. I think I could not get either the macros or cabinet settings to work this way, rendering them beyond completely pointless. I think the actual cabinet settings for the retroarch core are saved in /roms/neogeo/FBA/ along with high score, and I don't know what was up with the macros.