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

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

Clyde

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

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.

That it didn't display in my previous attempt may have been a problem with the format of my zip files. My file manager Krusader for Linux/KDE uses the compression method "Deflate". Mame2003-plus can't read this compression, apparently (runcommand.log):

[libretro ERROR] [MAME 2003+] Error in zipfile invaders.zip
The format of this zipfile is not supported, please recompress it
[libretro ERROR] [MAME 2003+] Error in zipfile invaders.zip: OS not supported

So I had to manually choose "Copy" as compression method, all other methods I can choose – namely Bzip2, Deflate64, LZMA, and PPMd – result in a different error, Compression method unsupported.

So mame2003-plus can only read zip files with "Copy" compression?

Riverstorm

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

So mame2003-plus can only read zip files with "Copy" compression?

That's definitely a question for the core guys. I use a program named RAR with maximum zip only compression set and haven't had any issues. Copy to me implies zero compression, basically stored in a zip file.

Clyde

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

Copy to me implies zero compression, basically stored in a zip file.

That's what I thought, too. Besides, the error "OS not supported" seems very strange to me for opening an archive file, especially since both the pc which created the file and the Pi who received it run Linux, although x86-64 and ARM variants.

And all other methods get the "method not supported" error, only Deflate gets the "OS not supported" one. 😒

But you're right, that is more a topic for libretro (I guess). I just wanted to note that the image not displaying was most probably not a result of the positioning in the .art file.

Riverstorm

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

But you're right, that is more a topic for libretro (I guess)

Maybe @markwkidd or @grant2258 would know the answer.

Clyde

@Riverstorm Again, that's what I thought, too. I'm off to offline things like supper now, anyway. Have a nice evening or whatever time of the day is at your place. o/

UDb23

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

So mame2003-plus can only read zip files with "Copy" compression?

FYI
I used 7 zip under windows and 7zip's counterpart on Mac; both with default compression: no issues.

grant2258

use the legacy .zip format not. zipx

http://kb.winzip.com/kb/entry/36/

mame does support deflate its the default format for zip universally. winzip and 7zip use it by default your zip compression util must be setting it to something else.

Ive never had any issues in linux using zip or unzip at the command line either or with winrar/winzip/7zip.

https://en.wikipedia.org/wiki/Zip_(file_format)

Clyde

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

use the legacy .zip format not. zipx

I had to look up zipx because I never heard of it before. According to https://en.wikipedia.org/wiki/Zip_(file_format), it's the name only Winzip uses for zip files "that use compression methods newer than DEFLATE; specifically, methods BZip, LZMA, PPMd, Jpeg and Wavpack". But my zip files that mame2003-plus rejects do use Deflate according to KDE's standard archiver Ark, so they aren't zipx files either. :(

mame does support deflate its the default format for zip universally. winzip and 7zip use it by default your zip compression util must be setting it to something else.

Strangely, even zip files that I create with 7z a invaders.zip * in the directory which contains my PNG and ART files are rejected by mame2003-plus with the "OS not supported" error. I'm using 7-Zip [64] 16.02 from Kubuntu 18.04.1's official repositories.

But files created with the standard zip tool Zip 3.0 (July 5th 2008), also from Kubuntu's repos, can be read by mame2003-plus! Again, I used no other options than zip invaders.zip *.

Very strange … as is the error "OS not supported". But I don't want to hijack this thread with this, I'm just extremely puzzled about it. And using the ziptool, I now have the means to create deflated files that mame2003-plus will recognize. \o/

grant2258

it the way your creating your zips send a link to a zip thats not working ill look at whats getting set. Its another flag thats getting set somewhere would need a zip to see what flag is being set cant really help beyond that

grant2258

run zipinfo -v you will see the problem is in the header compare 7z and zip created archives. I believe from a quick look at the source the problem is with with

minimum file system compatibility required:     Unix

this is causing the os error

A Former User

Where are you guys putting your roms, for Mame 2003 Plus ?
I've tried here

/home/pi/RetroPie/roms/arcade/mame2003-plus/roms

And here

/home/pi/RetroPie/roms/mame-libretro/mame2003-plus/roms

And Mame 2003 Plus just doesn't see them. It runs a few roms, so it must be reading them from the arcade roms folder.
Here is what I've done so far.
Compile the latest Mame-2003-Plus source.
Run a game that works, bring up the menu and export a xml dat file
Using clrmamepro, and the guide on these forums, I made a rom set from a 0.78 set + 0.139 set, non-merged sets.
This worked great, the missing roms text reported
"You are missing 20 of 4875 known mame2003-plus sets (+ BIOS sets)"
So that went well. So it's not the roms, just where they are uploaded to.

One other thing, when I managed to get a rom to work, the Mame menu was just a few entries,

Dip Switches
Bookkeeping Info
Game Info
Game history
Cheat
Generate XML DAT
Return to Game

there was no input menu - so I couldn't make custom inputs per-game.

Clyde

@grant2258 That's it! Krusader and 7z add Unix file system as minimum requirement. I never stumbled upon this because I normally only create zip files for my own use on Linux. I guess I could configure 7z to another minimum, but alas, Krusader don't have any such options (the usual disadvantage of GUI tools).

Here's the output for three test files. Their file names tell which program I used:

$ zipinfo -v krusader_zip.zip | grep minimum
  minimum file system compatibility required:     Unix
  minimum software version required to extract:   2.0
  minimum file system compatibility required:     Unix
  minimum software version required to extract:   2.0
$ zipinfo -v 7z.zip | grep minimum
  minimum file system compatibility required:     Unix
  minimum software version required to extract:   2.0
  minimum file system compatibility required:     Unix
  minimum software version required to extract:   2.0
$ zipinfo -v zip.zip | grep minimum
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0

Thanks for pointing me in the right direction. It's only 10 in the morning and I already learned something important. 😊

One last question in this matter: Do you know if the requirements of a zip file can be changed after its creation?

edit: But … shouldn't mame2003-plus or libretro be able to open such zip files on a *nix system? It's a rare case, but an incorrect behaviour nonetheless.

@John_RM_70 I don't think you can place roms in subfolders of the actual roms folders. You can either put your mame2003-plus roms in $HOME/RetroPie/roms/arcade or in $HOME/RetroPie/roms/mame-libretro. The former has the advantage that you can mix roms for multiple arcade emulators.

edit: As for the controls, they're to be managed in RetroArch's RGUI/XMB menu, not in MAME itself anymore. You can change that in RA's GUI under Quick Menu > Options > Input interface.