mame backdrop with retroarch overlay/bezel (asteroid; use case scenario)

Ashpool

Recently, I wanted to try out some of nowadays options for vector arcade games available within retropie to see what may be is/could be suited to be used on my wall mounted pseudo-cabinet and whilst I was at it, I decided that I also wanted to play/experiment with mame backdrops used in conjungtion with libretro overlays. In the "Development of module-script generator for lr-mess, lr-mame and mame standalone"-thread I had said that I am eventually making a showcase-thread about this, so here it is.

As AFAIK this forum still lacks the markup option for folded paragraphs (though it is cabable of folding quoted parts (sigh)), I will split my "opening post" into multiple ones. In this post I will cover the basic setup and sources used. It will be followed by some (brief) reports/presentations about a few observations made so far and finally, in my last post (for now), I will elaborate a bit on my experience gained and formulate some questions that arose during this venture.

So lets start with the basics.

Testenvironment:
Raspberry 4B 4GB (early rev., 1.5MHz, not benefiting from arm_boost 1)
fresh install of retropie 4.8.3, hdmi-group 1, hdmi-mode 16 (1080p) set in config.txt
emulators used: mame/lr-mame (0.251), lr-mame2016, lr-mame2003-plus, advmame, FBNeo (core version v1.0.0.03 72b9d1e)

To avoid messed up configurations due to too much *interfering leftovers" from my tinkering, two base images where created as fallback solutions. First one a fresh retropie install via Raspberry Pi Imager updated (including OS) and configured (config.txt, static ip for eth0, diabled wifi/bluetooth, enabled ssh, etc.) and the second one added the emulators (installed from binary) to it.

roms used: asteroid.7z, asteroid2.7z (Rev.4, Rev.2) for newer Cores, asteroid.zip (Rev.2) for older ones [FYI: Rev.4 was added in mame 0.132u2].
artwork used: From Mr.Do's Arcade side both asteroid.zip from a) the current In-Game Arcade Artwork and b) the Old Mame Artwork page.

References for the artwork formats:

specs for the modern layfile format over at mamedev
old artfile format documented in lr-mame2003-plus source code over at git.

files created for my trials:

simple layfile with a drawn rectangle (AR 4:3) covering the gamescreen and a 1280x960 backdrop image of uniform colour.
from the current mames artwork package, i've used "asteroids_internal.png" as a source for my bezel and "asteroids_backdrop" for the backdrop. Two "sets" where created, a) one bezel + backdrop for the modern layfile format and b) another one for the old artfile one (see images at the end of this 1st post).
from above one a merged image of the bezel (opaque) layed over the backdrop (transparency set to 50%).
some other (helper) images/files mentioned in the text.

For ease of use, the mame_artwork-files where placed as a folder (instead of an archive) in the approptiate artwork path (e.g. ~/RetroPie/roms/mame/artwork/asteroid/*).

(modified) defaults used:

RA video defaults: integer scaling (IS): on, aspect ratio (AR): core provided
(lr-mame) core defaults: read confic (RC): enabled, alternate rendere (ALT): off, resolution set to 1920x1080
+ (lr-mame2003+) core : vector - resolution: 1280x960

mame ini files (located in /opt/retropie/configs/mame and ~/RetroPie/BIOS/mame)
(for *configs/mame/mame.ini lines 1-17 (17: samplerate 44100) where kept; for *BIOS/mame/ini/mame.ini video entries where omitted).
mame.ini :

##video accel
video bgfx
##video opengl
keepaspect     1
unevenstretch  0
##intscalex      1
##Brightness     1.5

vector.ini:

beam_width_min            1.50
beam_width_max            2.50
beam_intensity_weight     0.75
beam_dot_size             1.50
flicker                   0.20

advmame.rc (diff):

display_artwork_bezel   yes
display_artwork_crop    no
display_artwork_magnify 1
display_beam    1.2
display_expand  1.0
display_flicker 15

test layfile - rectangle

<mamelayout version="2">
   <element name="box">
   	<rect>
   		<color red="0.3" green="0.6" blue="0.5" />
   	</rect>
   </element>
   <view name="gamescreen_area">
   	<screen index="0">
   		<bounds x="0" y="0" right="4" bottom="3" />
   	</screen>
   	<element ref="box" blend="add" />
   </view>
</mamelayout>

mame default.lay

<mamelayout version="2">
   <element name="playfield">
   	<image file="backdrop.png" />
   </element>
   <element name="bezel">
   	<image file="bezel.png" />
   </element>
   	<view name="backdrop">
   	<backdrop element="playfield">
   		<bounds x="0" y="0" width="1280" height="960" />
   	</backdrop>
   	<screen index="0" blend="add">
   		<bounds x="0" y="0" width="1280" height="960" />
   	</screen> 
   </view>
   <view name="bezel_backdrop">
   	<backdrop element="playfield">
   		<bounds x="320" y="74" width="1280" height="960" />
   	</backdrop>
   	<screen index="0" blend="add">
   		<bounds x="320" y="74" width="1280" height="960" />
   	</screen> 
   	<bezel element="bezel">
   		<bounds x="0" y="0" width="1920" height="1080" />
   	</bezel>
   </view>
</mamelayout>

mame asteroid.art

// gamescreen position is TL: 320/74, 1280x960 (bezel is TL 0/0, 1920x1080)

backdrop:
// file		= backdrop1080.png
   file		= backdrop960.png
   layer	= backdrop
   priority	= -1
   visible	= 1
   brightness	= 1
// position	= -0.02734375,-0.0770833,1.02734375,1.04791667
   position	= 0,0,1,1

//overlay:
//	file		= 1280x960.png
//	layer		= overlay
//	priority	= 1
//	visible		= 1
//	brightness	= 1
//	position	= 0,0,1,1

//bezel:
//	file		= bezel.png
//	layer		= bezel
//	priority	= 2
//	visible		= 1
//	position	= -0.25,-0.0770833,1.25,1.047917

libretro overlay
RA Bezel to be used with the 1280x960 mame backdrop

#  23 = Custom Viewport
aspect_ratio_index = "23"
video_scale_integer = false

# these two define the pixel size of the emulated screen
custom_viewport_width = "1280"
custom_viewport_height = "960"
# the following two decide how far from the left and top the game screen is shown
custom_viewport_x = "320"
custom_viewport_y = "74"

input_overlay = "/opt/retropie/configs/all/retroarch/overlay/asteroid.cfg"
input_overlay_enable = "true"
input_overlay_opacity = "1.000000"
input_overlay_scale = "1.000000"

RA Bezel to be used with the 1350x1080 mame backdrop

#  22 = Core Provided
aspect_ratio_index = "22"
video_scale_integer = false

input_overlay = "/opt/retropie/configs/all/retroarch/overlay/asteroid.cfg"
input_overlay_enable = "true"
input_overlay_opacity = "1.000000"
input_overlay_scale = "1.000000"

/opt/retropie/configs/all/retroarch/overlay/asteroid.cfg

overlays = 1
overlay0_overlay = "asteroid.png"
##overlay0_overlay = "asteroid_artfile.png"
##overlay0_overlay = "asteroid_fps.png"
##overlay0_overlay = "asteroid_tBD.png"
##overlay0_overlay = "asteroid_tBD_FPS.png"
overlay0_rect = "0.0,0.0,1.0,1.0"
overlay0_full_screen = true
overlay0_descs = 0

<customized artwork>

left: bezel with 1280x960 backdrop, right: Bezel + 1350x1080 backdrop

bezel with transparent backdrop area

["helper"-files are omitted from the presentation]

Ashpool

Starting with mame and lr-mame, i compared various settings in conjunction with the two basic layfiles and their impact on the gamescreen.

used artwork : simple layfile with drawn rectangle

mame
  projects defaults : 1280x960
  .ini modified(*)  : 640x480  (intscalex 1)
lr-mame
  project defaults  : 960x960
  as above (*)      : 1289x960 (RAs menu frame, background game screen 1280x960)
  .ini modified(*)  : 960x960  (intscalex 1)
  use ALT ......... : 1280x960
  as above (*)      : 1289x960 (RAs menu frame, background game screen 960x960)
  use ALT + .ini(*) : 640x480  (intscalex 1)

used artwork : 1280x960 Backdrop of uniform colour

mame
 projects default  : 1280x960
 .ini modified(*)  : 640x480  (intscalex 1)
lr-mame
 projects default  : 1280x960
 .ini modified(*)  : 1280x960 (intscalex 1)
 use ALT           : 1280x960
 use ALT + .ini(*) : 640x480  (intscalex 1)
 use ALT, RES* ... : 640x480  (core option: resolution set to any 4:3 format below 1280x960)
 use ALT, RES* ... : 1536x864 (core option: resolution set to 1600x1200)

Note: using the alternate render method lr-mame (0.251) ain't placing the (F11) FPS information on TR of the gamescreen as defined within the layfile, but on the TR position of the core options dimensions set as resolution).

And now playing around with the customized mame artwork and retroarch overlay and this time observing the framerate (on asteroids title screen, via mame hotkey F11 (just a few secondss of observation)).

a) artwork used: Mr. Do's asteroid, view: upright_artwork

mame
  unevenstretch 0: skip 0/10 49% (game screen: 640x480 (4:3))
  unevenstretch 1: skip 0/10 49% (game screen: 916x687 (4:3))
mame (mame.ini: change video from accel to bgfx)
  unevenstretch 0: skip 0/10 49-98% (game screen: 640x480 (4:3))
  unevenstretch 1: skip 0/10 49%, (game screen: 916x687 (4:3))
lr-mame 
  video intscale on  : skip 0/10 52% (game screen: 640x480 (4:3))
  video intscale off : skip 0/10 52% (game screen: 916x687 (4:3))
lr-mame (core: alt renderer on)
  video intscale on  : skip 0/10 ~39% (game screen: 640x480 (4:3))
  video intscale off : skip 0/10 ~39% (game screen: 640x480 (4:3))

b) artwork used: projects mameart, view: backdrop

mame
  video accel : skip 0/10 42-58%
  video bgfx  : skip 0/10 78-98%
lr-mame (intscale on)
  AR off      : skip 0/10 96-100%
  AR on       : skip 0/10 ~31%
lr-mame (intscale on, core option: resolution set to 1280x960)
  AR off      : skip 0/10 96-100%
  AR on       : skip 0/10 ~34-35%
lr-mame (intscale off)
  AR off      : skip 0/10 96-100%, game screen: 1440x1080 (with rgui menu open: 1280x960)
  AR on       : skip 0/10 ~30-32%, (game screen: 1280x960)
  AR on  **   : skip 0/10 ~34-35%, (game screen: 1440x1080), (*core option: resolution set to 1280x960)

Here is an image comparing the displayed vectors (on an unicoloured backdrop)

upper row: mame_video_accel, lrmame_AR_off, lrmame2016_AR_off
lower row: mame video_bgfx, lrmame_AR_on, lrmame2016_AR_on

c) artwork used: projects mameart, view: bezel_backdrop

mame
  video accel : skip 0/10 26-49%
  video bgfx  : skip 0/10 47-69%/49%
lr-mame (intscale on)
  AR off      : skip 0/10 70%
  AR on       : skip 0/10 20%
lr-mame (intscale off)
  AR off      : skip 0/10 71%
  AR on       : skip 0/10 19%

d) artwork used: projects mameart, view: backdrop and retroarch overlay (bezel)

lr-mame (intscale on)
  AR off      : !<game screen: 1280x960 and centered on display, offset from RAs Bezel.cfg not honoured>
  AR on       : !<game screen: 854x854>
  AR on **    : see AR off[*mame.ini: keepaspect 0, unevenstretch 1]
lr-mame (intscale off)
  AR off      : skip 0/10 96-100%
  AR on       : !<game screen: 854x854>
  AR on **    : skip 0/10 22% [*mame.ini: keepaspect 0, unevenstretch 1]

e) artwork used: retroarch overlay (bezel with transparent backdrop)

lr-mame
  AR off      : skip 0/10 98-100%
  AR on **    : skip 0/10 91-100% [*mame.ini: keepaspect 0, unevenstretch 1]
lr-mame2016
  AR off      : skip 0/10 97-98%
  AR on       : skip 0/10 97-100%

Compare of mame mameart view: bezel_backdrop (left) vs. lr-mame mameart view: backdrop together with the RA Bezel (right), followed by a shrinked (and inverted) difference view of both overlayed.

Ashpool

Now to the old artwork format (used here with lr-mame2003-plus and advmame).

Back in its time, the How to make vector arcade games look their best-guide from @caver01 inspired me to use advmame for vectors, later lr-mame2003(-plus) and fbneo did well in expanding their vector capabilities and somehow, until nowadays daycycles, I never really played any vector games since then. So I am a bit of a loss now with advmame, as it turned out to be a nogo here.

Starting asteroid.zip with a fresh and unmodified install, advmames video mode reported 1536x1080x32 and with the modified rc file (see 1st. post) 1920x1080x32. So far I was unable to get a usable gamescreen from advmame (see images below) and i am pretty sure that this wasn't true around +-2017AD. For the projects artwork the reported mode is 1440x809x32 and for Mr. Do's legacy artwork it is 1856x1042x32.
(note about performance: in all advmame cases tried, F11 reported auto <starting with 100%, then continuosly cycling from ~60% up to 100%>)

lr-mame2003(-plus) also shows some quirks, but here i think the problem is just the good ol' blame it on floats-one due to the fractional coords used in the artfile (note: the main reason for the 1350x1080 backdrop was, that the 1280x960 one doesn't aligned properly with the bezel for it in (fractional) coordinate system [Edit: this was for bezel + backdrop used within mames artwork, not for mame BD + RA Bezel]).

Using Mr. Do's old mameartwork for asteroid, the "gamescreen" (screenshot, borders removed) for advmame: is 1488x1080, borders: left 219 px, right 213 px and for lr-mame2003-plus it is 1490x1079, borders: left 214 px, right 216 px and bottom 1 px.
With the projects customized mame artwork it is for advmame a 1912x1076 gamescreen with borders left 5 px, right 3 px, top 1 px and bottom 3 px and for lr-mame2003-plus one of 1920x1079 with a border of 1 px at the bottom.
With lr-mame2003-plus, removing the bezel from the artfile,leaving just the 1350x1080 backdrop image gets us a 1348x1080 gamescreen with borders: left 285 px and right 287 px and adding to this an overlay of size 1280x960 (uniform colour) with a position of 0,0,1,1 results in that overlay beeing displayed as 1278x960 (floats, i hate 'em). Using the 1280x960 backdrop, we're getting a 1280x960 gamescreen which works well with the RA Overlay.

vectors from advmame and lr-mame2003-plus compared

TL: advmame OOB, TR: advmame modified RC
BL: m2k3+ BD1080, BR: m2k3+ BD960
notice how lr-mame2003-plus vectors sufffer from the badly sized playfield when using the 1350x1080 backdrop.

Mr. Do's artwork with lr-mame2003-plus (left) and advmame (right)

notice how advmame squezes the screen on the vertical axis and the vectors are missing the "burn in" effect of the backdrop art!

And here the same for the projects customized mameart. lr-mame2003-plus using the 1280x960 backdrop together with the RA overlay (left) and advmame with the 1350x1080 backdrop and bezel via mame artwork (right).

On the tv-screen i've used, the black borders for advmame aren't really noticable, but in the comparison here, they are IMHO pretty obvious.

Ashpool

Observing the image from older mame cores next to the ones from the latest younger cores, there is a noticable break in "layout" of the gamescreen. In Mame .108 and earlier the "Score/Coin/Copyright"-Vectors where placed with a wider spacing towards the top/bottom-gamescreens edge in comparison to .109 onward.

...
And now (onward) to the last core considered here: FBNeo (as that core doesn't provide native means for artwork, it can only be used with the RA Overlay (Bezel over transparent Backdrop)).

FBNeo asteroid vectors compared - left: HiRes Mode in 1080p, middle: HiRes within the defined 1280x960 RA overlay screen, right: as middle, but HiRes unset (480p upscaled to 1280x960).

The HiRes Mode in its native resolution looks (IMHO) pretty nice, but downscaled to the size defined by the overlay the vectors are looking somewhat chewed upon and those bitten out parts "seem to flicker"/"vary" from frame to frame and are IMHO irritating to look at (this cannot be grasped from the still-image, and the 480p ones upscaled aren't suffering from a similar effect).

Left HD, Right SD

And even if both variants where already shown in other screenshots, here is a direct comparison between (current) mame using the projects mameart (view: bezel_backdrop) and FBNeo (480p) with its RA overlay (50% transparent backdrop area) [480p may sound a bit unfair for the comparison, but the FBNeo HiRes variant glitches due to the downscaling are (IMHO) tolerable in a screenshot, but not in their animated form].

mame left, fbn right

Ashpool

Before I conclude now, a quick comparison (mostly an again) of the displayed vectors from the various cores.

Upper Row: mame (bgfx), lrmame2003+, mame (windows, preset vector-mono.ini, HLSL enabled), FBNeo HiRes
Lower Row: lrmame AR, lrmame2016 AR, advmame (custom rc), FBNeo (no Hires, upscaled)

So, that's it so far. Have I gained anything from those tests? Well, of course lots of questions together with some experience, but it wasn't really helping me in deciding which route I shall take for my CP2020 (see 1st post) utilizing a pi4. On systems capable of running current mame, that would be my #1 choice (Windows OS, as until the time bgfx/glsl effects are that easily configurable as it is with d3d/hlsl on windows, *nix is somewhat just second choice/class here). The libretro variant (RA bezel, mame backdrop) with the alternate render method could be an option, though there are some question that should be resolved before really considering it and, besides or maybe due to the fact that it doesn't cooperate well with the retroarch api (e.g. the problem with vertical games rotated internaly and handed over to RA as beeing horizontal), I've got a hunch that the lr-mame core (including the 20## ones) may include other pitfalls (I am unaware of at the moment) as well. And FBNeo doesn't have its own artwork system, so if a "real" backdrop is desired, that one cannot be used. With lr-mame2k3+ using a legacy version of the rom, that core somewhat/-how is also a compromise, but one with native backdrop cababilities. So it depends on what's more important for one self, the backdrop or the current rom+~drivers~/state_of_emulation for it.

But back on topic again: Are there any real benefits on libretro mame cores by using a backdrop from within mame? I am really unsure here, as on the one hand using an RA overlay (thinking bezel here) instead of mame artwork, eases the burden of the core, then on the other an RA overlay cannot replace a cores own artwork capabilities in the case of real backdrops and/or functional artwork elements (Lamps/LEDs/etc.). Then it is also to be considered, that by using mameart the usability of libretro shaders is somewhat limited, i.e. any intrinsic "screen"-effect (apperture-grille/shadow-mask, scannline-gap, curvature, blooming, whatsoever) should be projected upon the backdrop and not being applied to it (which boils down of either applying the wanted effects via mame itself or to do without them). Substituting the mame backdrop with an transparent retroarch overlay, could be a working compromise, at least for monochrome vector games, as the dimishing effect it has on the vectors is somewhat comparable to lowering the gama value from within mame (mames preset vector-mono.ini is setting gamma to 0.50). But then, there are games like Boot Hill, where such a proceeding would simply look out of place and the use of mame artwork alone or the combination of mame backdrop with a RA bezel is IMHO the only option (I can think of) to go (IMHO Boot Hill without the backdrop ain't the real McCoy). Dark Planet could have been another example, but as long as there is no way of achiving the "3d/Layer-Effect", that one is a lost case of its own accord.
So it is, as always, a case to case decision and depends upon wether one is willing to spend the time on it for a particular rom (as RA overlay and mame artwork had to be tailored to the system/display in question) or not.

Coming to an end, i will now simply list some of the questions which are still gnawing inside me in regards to all this.

core option: alternate render method, what exactly is it about?
Why is using it or nor making a real difference in current lr-mame, but is not really noticable in lr-mame2016?
what options in mames .ini-files are honoured by lr-mame, or better way around to ask, which are not?
(in general:) Is it possible to reproduce/achieve, even if the raspi hasn't got enough horsepower for it, mames hlsl (directx/windows only) effects with bgfx/glsl?
(in particular:) Are there any bgfx/glsl use cases on a raspi?
anyone any idea whats up with either advance mame and/or my setup in regards to it? And why is it, that "display_expand" has an impact on the display of asteroid (AR 4:3, horizontal), or what is the setting intented for? I am not linking to the advance mame projects page (as it include (indirect google-search) links to torrents for a complete romset), but just citing from the doc-page:

8.5.1 display_expand
Enlarges the screen area used by the vertical games on horizontal monitors (and horizontal games in vertical monitors)

I must confess, I am unable to grasp the meaning of that sentence and have no idea what the setting really is about :/.

old mameart format; any chance to work around the normalized/fractional/relativ coordinate system (providing pixel-exact coordinates)?

Ashpool

reserved/WIP (just in case),please proceed!