I am on vacation right now and cannot test it, but i cant wait to try those "Cave 2.0 SHMUPs".
As mentoined before i am a die hard Fan of CAVEs games, "DoDonPachi" is the best SHMUP ever for me.
Thanks a lot to Dink and the rest of the FBNEO DEV-Team!!!
I added usbhid.mousepoll back to the boot config file, set the GRS spinner to pulse at 512, and did some testing. Without that command or when I set it to value 0 (system use polling rate requested by device), my spinner runs slow. When I force the system to poll at either 1, 2, 4, or 8, the spinner runs at a much faster speed. The spinner moved at the same speed with all four values, so I left it on 8 to save CPU cycles on the Pi.
I set MAME sensitivity according to the formula (14%) and the blaster now free spins at the familiar speed. I can also properly adjust Major Havoc. Interestingly when I do a 5-space full turn test, a full turn with the GRS is exactly 10 spaces. The blaster isn't moving twice as fast; the blaster clicks at the same speed as this guy's setup with a turbotwist:
I wonder if the GRS is reporting a half turn as a full turn.
In any case, I'm willing to call this issue resolved to my satisfaction.
As the name implies it's basically CHDs (Compressed Hunks of Data) are typically any type of "rotating media" of the day, like a CD/DVD/Laser Disc/Hard Disk. Basically an image that is used along with the ROMs. I think the MAME core folks developed the CHD format.
They are just games that have more detailed graphics, more audio, better processing, better whatever...streaming graphics, streaming audio, etc. requiring more space than a ROM chip can hold. I think Killer Instinct used FMVs (one of the 1st?) and Carnevil streams a good amount of the game as it was digitized footage. I imagine it's more about a particular games "demands/requirements" and less about it being CHD based. I don't think the overhead of accessing the image alone is making it "unplayable".
The only issue I seem to be having now is even though I have 2 joystics any game with MAME if selecting 2 player all plays off the first joystick. but so far I have only tested games that had only one joystick. I still need to test games that had multiple joysticks for players to play at the same exact time.
That's completely normal if you've ever played the actual arcade games. The only time you'll have the second controller active is on games where both players play at once.
Would those be treated as multiple cores for core overrides and remaps?
No, they're not treated as different cores.
You can change the remap folder in the retroarch_vert.cfg to point to a different folder and the remaps would be stored separately. By default, the remap folder is the same as the config folder (i.e. /opt/retropie/configs/<system>).
If you do the remap from the Mame menu though, that's a per-game config which is saved in the core sub-folder and it would be applied to both emulator entries.
What I would still be missing I think is a per-game-per-emulator setting, like the cocktail DIP switches. For example if I wanted to launch 1942 in Mame-Vertical with a vertical config, go into MAME Tab menu, set the game dipswitch of Cocktail/Upright to cocktail, it would create a game-based override which would also affect the game if I were to launch it with MAME-Horizontal.
That's not going to work if you're using the multiple-emulators-but-same-core configuration, since those settings are stored in a nvram file that's unique per-core + game.
In general, you should choose a configuration approach and stick to it, either:
use different entries with the same core, but any settings need to be done from RetroArch and not using the Mame's internal menu/service menu
use different cores for each 'emulator' (Mame 2003 for vertical, Mame2003-plus for the other) and have the Mame internal settings separately.
I also had another lingering question - The lr-mame2003-plus documentation makes mention of an input mode called "mame_keyboard", along with "retropad" and "simultaneous", but I don't see this option anywhere. Was this renamed to just "keyboard" instead of "mame_keyboard" adn the docs are out of date?
It's part of the Core Options , under Input Interface, I think it was renamed to just keyboard.