@iainjh hi ! see some clarifications below.
The directory of the game does not need to have the short name and in fact does not strictly need to have the .svm extension either. Adding the .svm extension is only required for EmulationStation to launch the game directly by selecting the game folder and not having to go inside it and select the shortname.svm file.
The shortname.svm file inside the game directory with shortname inside the file is required for the lr-scummvm core to recognise the game.
When you use the standalone scummvm (not the lr- core), the .svm files get created in $romdir/scummvm, not inside each game directory. Unfortunately these do not work for the lr- core and you will have to create them inside each game directory in addition to the ones outside.
Having both emulators at the same time means you will have duplicate entries in EmulationStation, one for the top-level .svm files for standalone scummvm and another for the game directory containing the .svm file inside for the lr-scummvm core.
Right now there is no way (afaik) to have an unified system for both (but read below).
There is a very recent PR for lr-scummvm that will add support for autodetecting the game according to the gamefiles inside the game directory. This will make adding the shortname.svm file inside each game directory obsolete (point 2 above).
When that PR is merged I will be working on integrating that functionality and will revisit an approach to have both emulators (standalone and lr- core) to co-exist with the same game directories. For now, just be patient :)
@inolen one more question...is it possible to make save input for a specific game or a specific button to switch from gamepad to axis controler. The problem is mainly that I'm also using two Hori Fight Sticks mini 4, so there is only a stick (gamepad) :) In some games there is the main controler the axis or gamepad. So every time I want to play a different game I have to reconfigure the controller from axis to gamepad or vice versa.
This is just a wish (feature?:) )...nothing more :) If it's to complicate to implement or configure then don't bother :)
Thank you again for your QUICK and mostly EFFECTIVE anwsers :)
@sdtom An issue is opened with lr-mupen64plus-next on GitHub. Happens across different platforms. It seems like it has garnered their immediate attention. May want to update from source, as they have it marked as internally hotfixed.
Follow it here: https://github.com/libretro/mupen64plus-libretro-nx/issues/49.
Skyscraper 3.4.1 released: https://github.com/muldjord/skyscraper
Further optimized artwork space requirements. Now checks if original takes up less space than resized artwork, then forces use of original for those cases
The 'thegamesdb' module now also supports wheel and marquee for the games that have them (Thank you to 'tv21' for pointing this out)
Updated developer and publisher json list for 'thegamesdb'
thegamesdb now supports retrieving wheel and marquee artwork resource types. And I optimized the artwork resource export pipeline a bit further. If you scraped with 3.4.0 there's no need to redo it, it's only a small difference.
Alright im not coming outta retirement just had some unfinished business namely some code sitting around which adds the proper M68705 MCU for both
Renegade and Nekketsu Kouha Kunio-kun, problem was i could not suss out a way to workaround some incompatible code which sends a signal between
the main CPU and the MCU so the games did not boot, so i drafted in dink of FBN dev fame since he wasn't too busy just now to take a look at the code
and he sorted it all out in under two mins.
So thanks to him you can now play both of these games in MAME2003+ safe in the knowledge they are no longer using buggy MCU simulation code
and as such they can now be considered 100% faithfully emulated.....
Funny enough although i dabble with this core i dont actually use it, but just incase someday i do decide to pick it up i added support for this wee game which i like,
and since like the above games we now have a proper M68705 MCU dump for it, it's finally 100% emulated so no better time to add support for this quirky little number
from the golden age of Taito....
@AmigaGamer are you able to give me specific instructions on how to get it running I have retropie set up on my pi 4 with xfce and want to get openmw working finally got devilitionx working in ports menu if you can't tell me specifically what you did can I at least get help with the open graphs and that specific flag about decompression thanks
Thanks very much for the recommendation @mitu. @Clyde explains it much better than me. My wait time is definitely less than 10-15 seconds, more like 5-10, but that will vary with the emulator. Maybe you have a lot of emulator/system override customization @Clyde? this would slow the startup for sure.
Maybe this is not the case with a 3b+ and even less with the Pi4 but adding an image with useful information to read/look at helps with "masking" the wait time.
@Tim-s-up The retropie weekly dev builds are usable and nowhere near as buggy as lakka. For example, Lakka still crashes endlessly with the ozone theme since July. Also, retropie uses retroarch as well...
I was able to get this working without the script!
Like you mentioned, add a new line with "hdmi_blanking=1" to /boot/config.txt.
You must also add "consoleblank=600" to the existing line (not a new line!) in /boot/cmdline.txt.
Reboot and your screen should turn off after 600 seconds (10 minutes) of idle time.
This goes against the recommendation in the RetroPie manual install instructions (here), though I'm not sure why they recommend using consoleblank=0 in the first place.
Hope this helps!
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.