Development of module-script generator for lr-mess, lr-mame and mame standalone
-
MAME 0.252 is now released
https://www.mamedev.org/releases/whatsnew_0252.txttsimquest and tmegaman3 are not included in this update.
-
Yes, I read it.
Hopefully the improvements will help for the emulation-speed.Sad to here that these handhelds aren't added yet.
-
@Folly @DTEAM Before I open up a new thread [1], i thought to try it here 1st with all your Expertice - For current mame (non libretro) .ini files placed in roms/mame/ini and mame artwork placed in roms/mame/artwork are working fine. I tried the last few days to get the right place for e.g. artwork/asteroid.zip and vector.ini to work with lr-mame, maybe you know the path for the files?
I tried it on a Pi4 with a) Legacy OS (USB HDD) and Retropie installed "on-top" manually and b) also with a fresh 4.8 Pi4 Retropie .img (SD Card) and I am totally at a loss in identifying the place(s) lr-mame is looking for mame.ini/vector.ini/?.ini and artwork files.
1: Main reason I am asking here (1st) is more a question of "I want to know it, because I can't find it out and it would be nice to use current lr-mame instead of mame" during some tryouts i am venturing into and not something urgent on my real setup.
-
I tried the last few days to get the right place for e.g. artwork/asteroid.zip
I tried here with lr-mess.
https://retropie.org.uk/forum/topic/29682/development-of-module-script-generator-for-lr-mess-lr-mame-and-mame-standalone/1220
For lr-mame the path should be the same.
However, you can read that adding artwork to lr-mess/lr-mame will slow down emulation to a degree where it's not playable anymore.
On my x64 VM speed should be better.........
I did a test right now but both lr-mess and lr-mame will crash on this VM when adding artwork in BIOS/mame/artwork.The only solution I can think of is to use retroarch overlays for lr-mame just like we do with the handheld ( gameandwatch, konamih and tigerh )
I assume .ini files go in the BIOS/mame/ini, though I never tried or used it.
-
-
@Folly Thanks , and I've found out that I missed to enable read config within RAs core menu for artwork/inis to be actually read (previously I had just enabled MAME INI paths from that menu).
-
Ok, just for understanding it properly.
You changedmame_read_config = "disabled"
to enabled in the retroarch-core-options.cfg .
So the lr-mame core will now read ini files right ?
In which menu did you add the paths artwork and inis ? -
Did you notice that I have been working on a new work in progress wip-mamedev.sh module-script ?
-
@Folly said in Development of module-script generator for lr-mess, lr-mame and mame standalone:
You changed mame_read_config = "disabled" to enabled in the retroarch-core-options.cfg .
So the lr-mame core will now read ini files right ?
In which menu did you add the paths artwork and inis ?Apparently my misconception/missunderstanding in regards to the how read config and enable Mame Ini paths worked (to be honest, i totally missed "read config" so far [1]) was the culprit that I haven't got it to work earlier. I have now tried again on a fresh image with just lr-mame and mame installed in addition to the defaults. And I think this is what I learned now: Whence read config is enabled in lr-mame, it will read stuff from the folder(s) ~/RetroPie/BIOS/<ini|arwork|*> [2]. If in addition "use MAME INI path" is enabled, it will read the .ini(s) from /opt/retropie/configs/mame artwork etc. and utilize the path(s) defined in the mame.ini there instead.
1: ... as I always thought up to now that the read option was there to select a config to be read as an override for the current session :bang:
2: placing additional .ini(s) in ~/RetroPie/BIOS/ini seem to be read: at least I've tested it with mame.ini, arade.ini, vector.ini, vertical.ini and asteroid.ini. Any path settings (artwork, etc) from within these ini will be ignored. So its possible to keeping mame standalone and lr-mames ini files separated, but utilizing (a) shared sample/artwork folder(s) may (?)only be achieved via either symlinks or by changing the paths from mame(standalone).ini to point to .../BIOS/mame/* instead of .../roms/arcade/* and .../roms/mame/* (?). -
Ok, I think I get it.
It will read a mame.ini if placed in BIOS/ini and there we can, for example, set the same paths or different paths if we want. -
@Folly said in Development of module-script generator for lr-mess, lr-mame and mame standalone:
It will read a mame.ini if placed in BIOS/ini and there we can, for example, set the same paths or different paths if we want.
Oops, sorry If my phrasing implied that - I meant to say that lr-mame will (if not using(/without enabled) mame ini path) read inis from BIOS/ini/*.ini, but ignore any pathes set therein and just (including BIOS/ini/mame.ini) utilize general settings (like contrast, gamma, unevenstretch, etc., maybe even bgfx/hlsl/glsl/etc. settings - but I never tried those so far (on the raspi, and hlsl is AFAIK windows only)) from those. Whereas, if "enable mame ini path" is turned on, it will honour the pathes set in /opt/retropie/configs/mame/mame.ini and ignore all things placed in ~/RetroPie/BIOS/mame.
Edit: Haven't tried out what will happen/be with enabled "MAME INI path" in lr-mames core options and mame standalone ain't being installed (absence of path and content in /opt/retropie/config/mame).
-
Let me know how it goes.
-
@Folly said in Development of module-script generator for lr-mess, lr-mame and mame standalone:
Let me know how it goes.
Not sure if anyone can understand my scripted notes, but here is the log of my nowadayseveningtryouts and I am somewhat frustrated, maybe all that lr-mame RA-core-options stuff would make more sense under a pure retroarch install environment where lr-mame hasn't to compete with upstream mame.
Regardless of my frustration, for the purpose of that what I wanted to try, I can only conclude, that I need to install both lr-mame and mame and have to keep away from lr-mame/core options: write config, as that enabled is just messing things up [and without (upstream) mame installed, i have no idea where to place artwork/ini/samples that will be read/utilized by lr-mame].
@Folly, sorry for the longer post(s) involved and maybe it would have been better if I should have opened a separate Topic for it :/
-
No problem posting it here.
This is stuff we can about over here so we can discover new things we didn't know before.
Sometimes it can be useful for improving the module-script.Seems that you are more a standalone mame user.
RA has some advantages but that's indeed not always the case ;-) -
@Folly said in Development of module-script generator for lr-mess, lr-mame and mame standalone:
RA has some advantages but that's indeed not always the case ;-)
Well, yeah - a minor reason for my tryouts included the possibility to (as AFAIK libretro overlays are just overlays) use lr-mame with asteroids to get the (classic atari) backdrop from Mr.Do's mame artwork file and use lr-mame to cover it with a bezel (in the hope that a) it may allow me to use a bezel not included in the mame artwork file and b) maybe it (double finger crossed) will turn out to be faster in this chain, compared to (upstream) mame + artwork is applying backdrop and bezel - but I am still a few microns away from the time to spend on that experiment ;), but apart from that - you are right, as using an I-PAC2 Keyboard Encoder (set to keyboard), non libretro cores (at least for the arcade case) are easier to handle (IMHO), but are missing the vitals of libretro overlays and shaders :smirk: (and for those games upstream mame cannot handle, I am a big fanboy of both FBNeo and lr-m2k3+ (also because of the incorrect handling of vertical games being rotated within the core and reported/handed over as horizontal to the retroarch api and shaders))
-
I understand what you want to accomplish.
Use a bezel overlay of astroids with RA/lr-mame, correct ?There are 2 ways to accomplish that.
We can discuss that later is you want, let me know.
Btw.
Speed will not make a huge difference between using standalone mame + artwork and lr-mame + bezel overlay. -
@Folly It was just one of the things on my maybe/checkout/couldbe list... but yes, for asteroids I thought, that as libretro/retroarch overlays can't act as backdrops, i use lr-mame to utilize a mame artwork file with a backdrop and let libretro(-mame) overlay it with a bezel.
...
Thinking about of using lr-mame to show asteroids_acc_backrop.png from the mr.do file as a real backdrop and then overlay it with the bezel from the artwork file that progetto-SNAPPS is hosting. ...->... as my running system has a 1600x1200 4:3 Display, it will obviously include for me the tasks of preparing/editing the lr-bezel and creating needed configs, but thats a no-brainer once I know that this chain of backdrop/overlay can be done (and then we/I may see whether the emulations speed is still ok (throttle enabled, so not going faster then original hardware, but also not dropping below it is what i hope for [edit: and at least on my pi4's asteroid with current mame and artwork is fine, whereas asteroid deluxe is a choppy nogo with artwork]). -
I looked at the file asteroids_acc_backdrop.png.
You can use it as an background overlay but you need to use some transparency in the config file just like I use for the handhelds (konamih, tigerh, etc) using lr-mess.The config roms/arcade/asteroids.zip.cfg would look like this :
input_overlay = /opt/retropie/configs/all/retroarch/overlay/asteroids.cfg input_overlay_enable = true input_overlay_opacity = 0.500000 input_overlay_scale = 1.000000
The config /opt/retropie/configs/all/retroarch/overlay/asteroids.cfg would look like this (placing the .png in the same directory):
overlays = 1 overlay0_overlay = asteroids_acc_backdrop.png overlay0_full_screen = false overlay0_descs = 0
That is one solution that should work.
-
@Folly Right, and for lr-mame that maybe should perform faster then using mame-artwork together/instead of lr-overlays. But the reason I wanted to try with backdrop -> quick comparison: mame artwork (Mr.Do's old mame artwork) backdrop vs. lr-overlay in lr-mame2003Plus (nowadays default vector settings) and using asteroid deluxe (as that backdrop is more obstrusive compared to my mentioned asteroid one and therefor better suited for the comparison) ... And IMHO by having a real backdrop (where the vectors are drawn on) it ain't competing/messing with the vector setup(s) as it is IMHO with an overlay (drawn over the vectors) ;)
So, here we go -> left is mame_artwork/backdrop, right is libretro-overlay with 0.5 opacity.
P.S.: The Backdrop/Overlay may slightly differ in their AspectRatio, as for that test I've taken the backdrop from the mame artwork, resized it to 4:3 vertical res of my display and added black borders for the horizontal res and then using your configs with it (And for the mame artwork, i omitted the bezel from the artfile, so that it is just the backdrop used by it).
-
Nice to see that you have got it working. (nice backdrop btw.)
Indeed, using RA-overlays has it limitations.
What about the speed ?I tried the artwork file astdelux.zip (renaming it asteroid.zip) on both mame (in roms/mame/artwork) and lr-mame (in BIOS/mame/artwork) on my pi4.
The file seems a bit different than yours but for the test that doesn't matter.
Speed on mame is 100%
Speed on lr-mame is 78% (and more if frameskipping is used)Altough the speed is lower on lr-mame it is still playable and it looks better than using an RA-overlay.
-
Hi Folly, for classich and Game&Watch games from Madrigal romset, I got an idea to autorun the games with the good emulator.
For all roms, by default it could be MAME or lr-Mess (doesn't matter). For madrigal, you could create a scritp with your list or the list on my tutorial thread to generate a execution path for each Madrigal roms in /opt/retropie/configs/all/emulators.cfg like classich_ExplorersofSpace = "lr-gw" . That way, the user doesn't have to know if it's a Madrigal rom or MAME rom.
What do you think about this approch.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.