Development of module-script generator for lr-mess, lr-mame and mame standalone

Ashpool

@Soxbrother said in Development of module-script generator for lr-mess, lr-mame and mame standalone:

I didn't test all of them, but for now a few games say that "there are known problems with this system" or something like that. But seems that they can be played, so I don't know what problems they have.

You can query 'em here in the Arcade Database, even if the datfile lists emulation/driver/etc. as good, I bet there are some rom-files marked as missing/bad dump/or_similar (at least for climber dr-802.melody and dr-802.program are marked as bad dump).

Soxbrother

@Ashpool I see, I've searched the games I mentioned and they all have bad dumps.
With all of them the melody files are bad dumps apparently.

So if my assumption is correct, the only thing wrong with them would be the sound/melody in the game ?

Ashpool

@Soxbrother said in Development of module-script generator for lr-mess, lr-mame and mame standalone:

So if my assumption is correct, the only thing wrong with them would be the sound/melody in the game ?

I'm really not sure, as sound is flaged as good, and whether that means that there is sound/music missing from the emulation due to the bad dump or not, I have no idea. Sometimes a look into the driver source can be helpfull, but in this case (at least for me) it is just further information (not answering the and what does it mean) -> citing from the drivers source (hh_sm510.cpp [accessed: 20230213]):

Currently there is no accurate way to dump the SM511/SM512 melody ROM
electronically. For the ones that weren't decapped, they were read by
playing back all melody data and reconstructing it to ROM. Visual(decap)
verification is wanted for: bassmate, gnw_bfightn, gnw_bjack, gnw_bsweep,
gnw_climbern, gnw_dkcirc, gnw_dkhockey, gnw_dkjrp, gnw_dkong3, gnw_gcliff,
gnw_mariocmt, gnw_mariocmta, gnw_mariotj, gnw_mbaway, gnw_mmousep,
gnw_pinball, gnw_popeyep, gnw_sbuster, gnw_snoopyp, gnw_zelda

DTEAM

@Folly

MAME 0.252 is now released
https://www.mamedev.org/releases/whatsnew_0252.txt

tsimquest and tmegaman3 are not included in this update.

Folly

@DTEAM

Yes, I read it.
Hopefully the improvements will help for the emulation-speed.

Sad to here that these handhelds aren't added yet.

Ashpool

@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.

Folly

@Ashpool

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.

Ashpool

@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).

Folly

@Ashpool

Ok, just for understanding it properly.
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 ?

Folly

@DTEAM

Did you notice that I have been working on a new work in progress wip-mamedev.sh module-script ?

Ashpool

@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/* (?).

Folly

@Ashpool

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.

Ashpool

@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).

Folly

@Ashpool

Let me know how it goes.

Ashpool

@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 :/

Folly

@Ashpool

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 ;-)

Ashpool

@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))

Folly

@Ashpool

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.

Ashpool

@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]).

Folly

@Ashpool

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.