mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support

UDb23

@Riverstorm First of all merry Christmas!
Concerning the coordinates I followed the .art instructions. As you said maybe SI due to mirror and rotation needs swapped x/y.
Armor Attack is my next test. Recreating a good res backdrop (actually an overlay) as the image from Mame artwork (also w newer LAY format) is quite bad.
Will let you know how coords will work (this time with vectors).
With my Xmas family visits started it may take a couple of days ;-)

Riverstorm

@UDb23 - Merry Christmas to you and your family too! Definitely take your time and enjoy. We have a full day plus some planned but I want to test the rotation and see if it effects the numbers in the next few days. When you test it just use the string straight from the spreadsheet. Barring the rotation plays a part in the calculation errors it's just a simple transpose error.

UDb23

@Riverstorm Did additional testing with Armor Attack (vector) and Frogs.
The coordinates that the calc sheet generates are correct and work fine (these are both "not rotated" games).

The reason for SI being different is that the screen is physically rotated; so in the calc the input data are:
Backdrop: 1080 x 1920 (WxH)
Game Area: 1080 x 810 (or 960x720)
That gives you the correct coordinates for SI to be used in the .art.

UDb23

Frogs backdrop is ready and available.
Made a pull request to be included in lr-mame2003plus. SI is already merged.
Edit: added screeshot

grant2258

@UDb23 dont think anyone has enabled the artwork on lr-mame2003 hopefully someone will start updating it a bit.

UDb23

@grant2258 Sorry I meant 2003plus of course, and that's where pull request was made. Edited previous post.

Riverstorm

@UDb23 - Thanks for testing. Now all the calculations make sense on what was happening and why they needed transposed.

Thanks for the new backdrops they look great. I pulled out the Pi late afternoon yesterday and it was a big hit. Way more interest than I thought it would have. It took me a few minutes to figure out I had to force the HDMI audio to the TV but after that it was smooth sailing. I always bring along a small wireless keyboard just for those types of situations.

I need to figure another hotkey for player 2 start on controller 1. For single stick games they had to press player 2 start for 2 players on the second controller and then pass only the first controller back and forth to play. They kind of frowned upon it since they needed to reach over to it every time to start a game so it was good to have others "testing" to see how intuitive it is for new players.

UDb23

@Riverstorm said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:

player 2 start on controller 1

I usually remap left and right analog "buttons" on player 1 gamepad to "coin 2" and "start 2".
Think few console games require pushing the analog sticks as buttons anyway.

Riverstorm

@UDb23 said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:

I usually remap left and right analog "buttons" on player 1 gamepad to "coin 2" and "start 2".
Think few console games require pushing the analog sticks as buttons anyway.

I think that was the only thing that seemed "clunky" so to speak when playing 2 player games. I will give that setup a try. When I am at home I have a controller and keyboard in front of me. I don't get 2 players to often as the wife only likes a few arcade games. Her wheelhouse is Mario Bros. games on NES/SNES. Then she starts talking smack.

Riverstorm

@UDb23 - Do you have any idea how multiple submissions are handled? If say someone else wants to refine or there's an alternate background for an arcade game someone wants to share. They need to named the sames as the ROM correct? How is that handled on on pull request since it's automatically pulled down to your artwork directory when updating from source.

Clyde

@Riverstorm said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:

@Clyde - I would be curious if you do test SI would you be willing to post a screenshot when you have it all loaded? I struggle with what a 16:9 backdrop image will look like on a 3:4 or 5:4 display. Will it be squished on the y axis, clipped/zoomed on the sides or look correct. I only have standard 16:9 displays at home so a 16:9 backdrop fits perfectly.

I think it would help to understand if people using different displays will need custom backdrops or if one size fits all.

I finally got around trying @UDB23's invaders.zip on my 1600x1200 display. Alas, it won't fill the screen, but display as a 1600x901 picture:

alt text

The areas above and below the image are displayed plain black on the 1600x1200 screen.

I then tried to resize the backdrop picture to 1200x1600 and change the position in invaders.art to -0.214286,0,1.214286,1, calculated by @UDb23's spreadsheet for a backdrop of 1600x1200 and a game area of 1120x1200 (upscaled SA's original resolution of 224x240), but the backdrop isn't displayed then.

What am I doing wrong?

UDb23

@Clyde For SI, as the CRT was physically rotated in the cabinet you need to use the following as input in the sheet to calculate the coords to place in the.ART file:
backdrop: 1200x1600
game area: 1200x1120

For the game area please check first in the RGUI what is the resolution with your monitor (without any artwork enabled). Then use that as reference for calc (transposing X/Y in the case of SI as explained before).

Riverstorm

@Clyde - Ok that make sense and is good to know. The backdrop is going to attempt to scale for different ratios. If you fill the screen horizontally (1600) to keep the same ratio of the original backdrop it would be 1600 x 0.5626 = 900. So 1600 x 900 would be the best ratio possible (of the original artwork) without clipping. If you attempt to fill it vertically to 1200 and calculate the numbers it would go beyond the edges horizontally (beyond 1600).

Why 901? I am not sure but it should be 900. It's the same on HD displays it shows as 1918 x 1080 which is two pixels off (it should be 1920 x 1080). I don't know if it's the calculations or the core doing these minor miscalculations.

I have a little bit of black on the border of HD TV's naturally but I believe the backdrop and game area align at the same level. My RA screenshots definitely show a black bar that doesn't exist in game play but at 900 you probably have some hefty black bars.

When you resized the backdrop your numbers are backward so maybe that's why it doesn't display at all. You need to reverse your numbers so try them as below and your numbers should come out to 0,-0.214286,1,1.214286.

Backdrop image:
x (width) = 1200
y (height) = 1600

Game area:
x (width) = 1200
y (height) = 1120

UDb23

@Riverstorm said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:

Do you have any idea how multiple submissions are handled?

Currently lr-mame2003plus is supposed to simply copy the artwork files during installation from the github folder. That means no way to select multiple. Maybe @markwkidd can implement a system that requests monitor aspect during installation and copies artwork from specific github folder.
Otherwise I can keep multiple versions in the Overlay repo and we could kindly ask @meleu if he can "upgrade" his script to manage also backdrops as we do for multiple overlays.

UDb23

@Clyde if you are going to resize the backdrop to fit your display it's better you use a higher res image source for the backdrop (as you have more pixels on vertical than 1080).
High Res Taito moon image here.

I would suggest we create a separate thread to discuss about backdrops to avoid "cluttering" this thread. ;-)

Riverstorm

@UDb23 - Ok, yeah from what Clyde is showing it seems different displays will need different sizes or it might be possible to use negative positioning but would have a side effect of clipping. Basically filling the y axis (1200) and clip what goes beyond 1600. I don't even know if it's possible just a guess.

Yeah I was thinking if a game had 2 backdrops. Let's say you submit one named invaders.zip and "John" comes along and submits an alternate "invaders.zip" you can't sumbit that in a pull request correct? One would overwrite the other?

Riverstorm

@UDb23 said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:

I would suggest we create a separate thread to discuss about backdrops to avoid "cluttering" this thread. ;-)

Sounds good.

UDb23

@Riverstorm said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:

One would overwrite the other?

yes

Clyde

@Riverstorm said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:

@UDb23 said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:

I would suggest we create a separate thread to discuss about backdrops to avoid "cluttering" this thread. ;-)

Sounds good.

Okay, I will do that. Stay tuned while I am testing your suggestions.

Clyde

Done. :)