Space Invaders backdrop resolution (mame2003-plus)

Ashpool

@WeirdH I fear that's the quality the source is offering, the modern/updated mame artwork (layfile format) may be of a better quality - don't have the time to look at it atm, but maybe a less jaggy backdrop could be created for the old artwork format from it (would need some blending/merging of the various layer (moon/backdrop/?) into a single backdrop image). If I find the time, I will give it a try this evening.

@Clyde Nope, lr-FBNeo relies on RA overlays, it never had (AFAIK) it's own artwork cababilities.

P.S.: It would be really great if RA would come up with it's own backdrop support in addition to overlays!

WeirdH

@Ashpool said in Space Invaders backdrop resolution (mame2003-plus):

@WeirdH I fear that's the quality the source is offering, the modern/updated mame artwork (layfile format) may be of a better quality

That's what I thought too, but here is a screenshot with a backdrop with a 2236x2981 resolution, sourced from Clyde's earlier post. That should be plenty to alleviate some jagginess, right?

But it still does the same thing all backdrops did for me so far. I figured it had to be something I'm doing wrong in the invaders.art file.

Ashpool

@WeirdH Yup, that's what happens if the machines screen is projected/positioned upon the (fractional) resized artwork and the whole 'vertical' mame-display is then rotated (for mame2k3+ that would be via retroarch AFAIK and not by mame itself) and most possible further "squeezed" by that process. I have an idea and will try to create an old artwork format backdrop aimed at your display/resolution -> Source Resolution: Oops... that changed during it's mame-history the resolution in Mame0.125u2 and onward is listed as 260×224@59.541985 Hz, previously it was 224×240@60 Hz ↺90° (sometimes 270 for the rotation). Nevertheless, according to the artwork definitions, the gamescreen is smaller then the backdrop area and considering that for crts the number of scanlines (vertical, or in this case (rotated monitor) horizontal) is known, width of scanlines depends on frequency/and|or whatsoever, personally i would prefer an integer scaling of the "reference"-axis -> so for 1280x960 and a DAR of 0.75, the "invader" screen would be 672x896 (Edit: (now) verified from within mame with a unicoloured backdrop positioned 0,0,1,1 and RA-menu integer scaling set). But from your screenshot it appears, that you are prefering the gamescreen to be 720x960. Mh... well, I think I make both variants now (work-draft or however you may call it) and we may see how they turn out.

P.S.: Real Backdrops shouldn't be part of the shader (they won't be curved, aren't build up by scannlines (so no gaps on 'em), etc.), that's why in such cases RA/libretro shaders are messing it up (and also thats why RA is in need of its own backdrop capability) and it would be better to use mame's own shaders (for mameecores able to do so, that would still be a nogo on the raspi (performance wise)). Citing from Wikipedia: Space Invaders

In the upright cabinets, the game graphics are generated on a hidden CRT monitor and reflected toward the player using a semi-transparent mirror,
 behind which is mounted a plastic cutout of a moon bolted against a painted starry background.
The backdrop is visible through the mirror and thus appears "behind" the graphics.

Edit: Damned, old artwork format - fractional coordinates, problems I encountered in my linked thread above (asteroid mameart/RA overlay) ... Backdrop Area=Game Screen is less troublesome for now (if the backdrop shall be larger, the workaround of incorporating the "outer" part of the backdrop into an RA Overlay would be easier to do).

For completeness sake -> here is a croped screenshot from current mame (WIN) with HLSL effects enabled (scannline gaps only on the projected game screen, not on the backdrop/bezel)

Ashpool

@WeirdH Well, I fear that without an backdrop image that eventually is better suited for this, it won't get any better (even if some prefiltering/bluring will be applied to the image). Based on the backdrop starfield & moon from Mr.Do's current ingame artwork file, composed by layering both in complience to the positions given within the .lay file and then the merged backdrop grafix croped to the game-screen (DAR honoured) ending in 2016x1512 (| resized to 960x720) -> this is the result from this quick mashup:

I think one factor to be considered here is, that with the fully fledged mame artwork files, mame is actually rendering the gamefield in a really small area within a much larger artwork dimension based on the bezel(/+control pannel) and what we are seeing here is the enlarged/zoomed into pure gamefield proportion of that.

jamrom2

@Ashpool question... Have you tried using another version of Mame? Mame2003+ is not only old, but is a "best fit" for RetroPie. You can try other versions like 2010, 2015, 2016. You just need to check the rom versions. For Space Invaders it might work. If not Google is your friend for the proper version. See if that works. Just dump the artwork in the same folder after you finish loading the version into RetroPie. You don't have to change the ini file either. Just point runcommand at the new version.

I've been super busy around the house with Memorial Day weekend plans. Sorry I haven't answered much.

Ashpool

@jamrom2 said in Space Invaders backdrop resolution (mame2003-plus):

Have you tried using another version of Mame?

So far just on windows to see how Mr.Do's current artwork looks, but if @WeirdH wants to use any libretro shaders with it, newer (counting m2k3+ among old here) mame cores are a nogo due to the way they are dealing with the screens rotation (rotation done in mame and reporting the game as beeing horizontal towards RA).
Edit: But I haven't taken a look (was unaware of it) into issue #360: Use libretro screen rotation so far, so maybe that ain't such a problem anymore (?).

WeirdH

@Ashpool said in Space Invaders backdrop resolution (mame2003-plus):

@WeirdH -> this is the result from this quick mashup:

Ah, so it's not just me. Still, isn't it weird that a hi-res image gets pixelated like that? What causes that? Like I said, I initially thought it had to be something in the .art-file that I was messing up, but it seems not. Is it the core? Is it Retroarch? Something in the artwork? Or all of the above?

And even then, regardless of the cause, why does it seem to work correctly for Clyde in this thread (see post #5)?

I think one factor to be considered here is, that with the fully fledged mame artwork files, mame is actually rendering the gamefield in a really small area within a much larger artwork dimension based on the bezel(/+control pannel)

Yeah, I had also considered that, but even images that are easily four times the resolution of my entire screen get like this. I don't think the gamefields in fully bezeled configurations are actually over four times smaller than fullscreen, right? Maybe I'm wrong, but it just doesn't make a lot of sense to me. Then again, I'm by no means an expert, so feel free to take all of my assumptions with multiple grains of salt. ;)

Ashpool

@WeirdH said in Space Invaders backdrop resolution (mame2003-plus):

And even then, regardless of the cause, why does it seem to work correctly for Clyde in this thread (see post #5)?

I am not sure that it does, but before i come to that some further thought about the basics ;p

even if the souce images are highres, that doesn't mean they aren't jagged or pixelated and the taito_moon clyde used is somewhat better in this regards then it is with the midway one.
furthermore, clyde squeezed the left/right boundaries of that backdrop. Here is a (top/bottom black borders croped) screenshot (on a 1280x960 display) from current lr-mame with everything removed from the layfiles view but the backdrop and screen, together with the brightness raised within mame (to highlight the actual gamescreen):

Screen_over_Backdrop_(mame254).jpg

Compare that to the backdrop clyde used and you see that the moons width was squeezed by him to fit his 1600x1200 display. Next is a comparission of 3 settings used on my next mashup using that taito moon (also squeezed in width, though not to the extent clyde had used):
Top: crt-pi-vertical shader, no bilinear filtering; Middle: Bilinear Filtering enabled in RA menu; Bottom: pure backdrop [mame2k3+]

.

The screenshot @Clyde used was also with a scanline(gap)-filter, and IMHO that one is pretty much masking the pixelation/jagginess - so, my guess would be that his backdrop would also turn out pixelated without the shader used ;] Edit: Oops, actually the shader is only used on one of his images. You can try his artwork - just use the 1200x1600 image he posted together with the artfile definition mentioned in that thread (or to be sure, resize it to 960x1280 and use the backdrop definition from my mashup below) ;)

P.S.: that backdrop/artfile i've used above is aimed at 1280x960 (outer boundaries for the artfile calculation/coordinates) and bloody floats, again the resulting gamearea is 671x892 instead of 672x892 (which is the screen resolution the coordinates where calculated from), the backdrop image itself is 2016x2688 (3:4).

backdrop:
	file            = moon_squeezed.png
	layer		= backdrop
	priority	= -2
	visible		= 1
	position	= -0.017857,-0.452361,1.053571,1.452381

Ashpool

@WeirdH said in Space Invaders backdrop resolution (mame2003-plus):

I don't think the gamefields in fully bezeled configurations are actually over four times smaller than fullscreen, right?

Wouldn't bet on it... here is a resized screenshot (windowed mode, resized to 65%) from current mame on my win PC (monitor: 1920x1200), the actual game screen is somewhat around ~+- 340x450 on that (windowed), ~360x470 (Fullscreen) [Edit: so x4 resolution (x2 on 2 axes) would be ~720x940], resolution/artwork file is from Mr.Do's. (so the Bezel is 4000x4133, the control pannel 3999x1151, starfield 4000x1828 and moon 3420x1279). I guess that is clearly to be used in tate mode with a rotated display :] Don't know what mame is using as filtering method for up/downsizing (assuming that m2k3+ is offering bilinear as an option i would guess that the base resize is nearest neighbour), but welcome to the world of things like nearest neighbour/bilinear/bicubic/lanczos/etc. and the problem how to squeeze n-base pixels into m(<n)-target pixel or how to enlarge n--base px into m(>n)-target px ;>

WeirdH

Man, that is a lot to process ;) I do appreciate you taking the time to mess around with it and explain in such detail. Some of the calculations go over my head (not a calculations guy, really), but it all makes sense at least, thank you.

@Ashpool said in Space Invaders backdrop resolution (mame2003-plus):

You can try his artwork - just use the 1200x1600 image he posted together with the artfile definition mentioned in that thread (or to be sure, resize it to 960x1280 and use the backdrop definition from my mashup below) ;)

I will toy around with this. If all else fails, my Space Invaders will just have a regular old black background with nothing in it and even less on it.

Ashpool

@WeirdH ~~Here is an archive of some of the files of my mashups using the taito moon: invaders_testfiles.7z.~~
For quick artwork tests in (lr-)mame: remember that the artwork don't need to be in an archive, instead of invaders.zip you can just create a folder "invaders" within the artwork-folder and put the artwork files in there.
files included: 2x. artwork.art files (one for fullscreen BD, the other one for the 720x960 ones), 2 images for a fullscreen backdrop (original moon, slightly squeezed moon) and another 2 for a backdrop area of (rotated on 4:3) 720x960 (same as above). For the second one, the calculated coordinates are resulting in a 672x896 gamescreen, so no pixels missing/added from that one ;]
Please report back and say that you either downloaded it, or aren't interested in it. I just created a (temporary) directory for it in a forked repo and want to remove it from there ~~again~~ asap (don't want that one to be included by my next pull request) ;>

Edit: What you may try, and I haven't tested so far, is to downscale the artwork png file in question to the actual dimension it would occupy on your display and by using a resize filter of your choice (1). As we can't even count on the WYSIWYG from an imager viewer/graphics_app_of_our_choice :/, but have to see what the (retropie)-core used is making of it, it could be worth to try to put in a source with exact targeted px-dimension.

1: (old school rule of thumbs was bicubic for upscaling, bilinear for downscaling - but that was in times before lanczos and other more modern resize filters came to be) - sadly due to the vertical into horizontal display rotation cannot be avoided, and by downscaling (in older legacy artwork this could also include upscaling), this would still mean that the artwork source image would be processed by mame and are not 1:1 identical to the source we put into it.

Ashpool

Another option would be to use a transparent RA-overlay and that would also work with FBNeo.
Drawbacks are mentioned in my asteroids/mame-backdrops/RA-overlays post(s), but there you are on a easy-peasy route to define the viewport and overlay it with a bezel or whatsoever. Otherwise, keep in mind that an within RA overlay definition the viewport part ain't mandatory (?AFAIK?) and you may have a fullscreen mame backdrop with a centered gamefield area together with an libretro/RA overlay on top of it (Mame screen covered by the RA overlay and not squeezed into a ViewPort area of it) though I am not sure on that one right now, but for me it is to late to check this one out.
But, at least for me, substituting backdrops with semi-transparent overlays, is much further apart from being the real McCoy then it is with mame backdrops. ... sigh.

roslof

@Ashpool said in Space Invaders backdrop resolution (mame2003-plus):

Another option would be to use a transparent RA-overlay and that would also work with FBNeo.

This is exactly what I'm using. Using an older "bezel" .png from @Orionsangel. Here's a link to his video w/download link in the YouTube description:

Used the PNG as a RA overlay for the background and the bezel/cabinet art. For my implementation, I zoomed in and set Overlay Opacity to 0.30 (30%) so the sprite visuals appear brighter than the machine/overlay itself. Can easily brighten to taste...

I'm also using lr-mame, which has a color overlay built-in -- so the greens and reds are vibrant. I think this works well.

FWIW: For Space Invaders Deluxe (or "Part II") I also used a modified .lay file -- only including the really nice rainbow/color gradient overlay that the arcade supports. The background/cabinet art are rendered with RA. Same basic technique, but since the sprites themselves needed color -- the .lay file was required + a more modern MAME.

Images above are from my Raspberry Pi 4B, but I'm fairly certain that a 3B+ can handle.

The RA .png backgrounds w/bezel/cabinet art are in HD resolution (1920x1080) so I wager if you only want the backgrounds and not the cabinet art, just ensure that they're at the same resolution and they should work fine, without pixelation and without influence from the shader.

WeirdH

@Ashpool said in Space Invaders backdrop resolution (mame2003-plus):

Please report back and say that you either downloaded it, or aren't interested in it. I just created a (temporary) directory for it in a forked repo and want to remove it from there ~~again~~ asap (don't want that one to be included by my next pull request) ;>

Done, thanks.

I don't know how much more time I'll spend on this, as I've been already been at it longer than I wanted to. Also, I'd rather play Return of the Invaders or Super Space Invaders 91. :)

@roslof said in Space Invaders backdrop resolution (mame2003-plus):

@Ashpool said in Space Invaders backdrop resolution (mame2003-plus):

Another option would be to use a transparent RA-overlay and that would also work with FBNeo.

This is exactly what I'm using. Using an older "bezel" .png from @Orionsangel.

Been thinking about this a well, but I'm kind of done tinkering with it by now.

Orionsangel

@roslof That looks awesome. I'm glad I could help and be part of it.