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

Soxbrother

@Folly Got it working, thanks !!!
Only need a way to maybe zoom in or make it larger or maybe fullscreen.
Would be great if you could make it larger but still see the handheld, instead of fullscreen and only see the playfield.

Folly

@Soxbrother

Depending on which emulator you use you can zoom in with all.

With lr-mess we don't use artwork but retroarch overlays for the background.
If installed/created with my script then they will show up with the game in fullscreen.

With mame/lr-mess you can use the "tab" key to open the mame-ui then select video options -> screen#0 -> your choice.

With lr-gw you can use "right-shift" and press until you see zoom then press "enter".

Btw.
The combination mame and lr-gw is not ideal in my script.
It works but I want to change it in the future to something better if I get a good idea.

Soxbrother

@Folly Thanks !!!

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.
The few games I saw with that message for now, were :
climber ( only displayed the gamefield, no other graphics ), game worked
black jack, worked ,
bomb sweeper worked
cgrab didn't display graphics, only playfield, game worked, it complained about not having the graphics.
Is it true that there are titles that have known problems then ?
or has it something to do with the roms itself ? (usinf 0.251 roms)

Greetings,
Soxbrother

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