mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support
-
well im seeing this in the docs.
http://dragonking.arcadecontrols.com/static.php?page=mhsniping
i does appear you do need to configure it perhaps there is pre configured files for know games. This info here makes sense from what ive seen in the code
-
"Here's warrior for example:"
I've just set up my first RPI gaming machine, and this was one of the games I was thinking it would be cool to find, but could not remember what it was called. Thank You!!!
-
Big update to the MAME 2003-Plus docs: https://docs.libretro.com/library/mame2003_plus/
@grant2258 I will migrate your diagrams to the
libretro/docsrepository next time I get a chance. The docs generator doesn't like pulling them from another repository it seems :) -
Im really put off the idea of fixing this. People want to copy fba which basically let an arcade panel map to a gamepad so its a quick fix to work on both.
Which takes the point of having and arcade panel away. Anyway short story is ill leave it as is because the user can just pick classic as default and just pick the panel for the 6 button games I dont want my panel mapping like a gamepad for one
-
@grant2258 said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:
Which takes the point of having and arcade panel away.
Not really. I for example have an upright arcade cabinet with the typical 6-button layout for players 1 and 2. But I also have two wireless Wii U Pro controllers for players 3 and 4. (I can mirror the cabinet's picture to my video projector if it gets too crowdy at the cabinet.)
For my desktop mini pc, I have two wired arcade joysticks with 8 buttons, and I can also use the two Wii U Pro controllers mentioned above with it, depending on the games I wish to play and with whom I play them.
Thus, having presets for 6 and 8-button arcade-style controllers as well as for typical gamepads to change the setup on the fly without re-mapping the single keys seems very useful to me.
-
@Clyde said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:
with whom I play them
Whom is a great word! It has been on the decline since the 1800's according to Googles Ngram Viewer. It looks like it had a brief resurgence around 1826.
-
@Riverstorm said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:
@Clyde said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:
with whom I play them
Whom is a great word! It has been on the decline since the 1800's according to Googles Ngram Viewer. It looks like it had a brief resurgence around 1826.
Use Whom regularly. I try to correct people as often as I can in a Ross Geller style.
-
@Clyde no one is stopping anyone doing this it would need to be an option not everyone wants a gamepad layout like you.
Personally I cant stand my arcade panel mapped as a gamepad. Some 3 button games work others dont like double dragon 2 which it sided so are many others and a very much unplayable in as
34 12formation imho this is a lazy and hackish way to do things but thats just my opinion everyone is entitled to one. This hack is easy to implement the only thing that would need fixed is the way the ra input needles are handled.
All that work to map like gamepad is waste of time for me when the user can just pick classic and set the few 5/6 player games to panel of there choice.
ill do some code for mark to look at at some point(not a high priority for me) but it will just do the mapping not the not the ra needles.
I personally will never use this option even if it is wanted by mark so it would need to be an option toggle so people can choose the panel the way they choose to instead of gamepad formation.
-
I started using backdrops in Plus and along with overlays. With the new backdrops they cover the entire HD area (1920 x 1080) so I have to set the opacity of the overlay to 100% so the backdrop doesn't show through. When the overlay is set to 100% or maybe it's the backdrop (but it's at 50%) but regardless you loose the RGUI overlay information in the lower left corner.
Basically I can't see any messages like loading overrides, when I increment a save slot, screenshot, pause, etc. but everything does work correctly.
I am on RetroPie 4.4.4 and RA 1.7.5 on a Pi 3 using Plus commit 8ff5a43.
@UDb23 - I just wanted to tag you on this so you know what it's doing. I usually set my overlay opacity to 0.5 as I don't like full brightness but when using BD's I need to set it to 1.0 to avoid backdrop bleed through.
-
@Riverstorm said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:
I usually set my overlay opacity to 0.5 as I don't like full brightness but when using BD's I need to set it to 1.0 to avoid backdrop bleed through.
I could lower the brightness of the original overlay image so you don't need to change opacity (that would be a "backdrop specific" overlay image).
-
@UDb23 - Thanks, that's ok, you probably don't want a bunch of variations floating around. I am ok with setting it 1.0 as it looks good. It was just an FYI because anything less than 1.0 will start to show bleed through at various levels which leaves no brightness setting basically. That scenario didn't dawn on me at all until I actually started the game but I have no idea how a person would handle it and still allow user brightness options.
-
@Riverstorm The other option is to create a "cropped" backdrop (cropped by the boundaries of the game windows of the bezel). But also this is not ideal; would not be good for people wanting to use just the backdrop.
Mmm.
One more option: full screen backdrop (as current) with a (separate and optional) black overlay (black mask) on top, with the exact layout of the bezel. In other words the RA bezel would have a black "underlay" so you can change the opacity without bleeding.
Having the .art system managing 2 images (bd+black mask) probably could be taxing in terms of performance on Pi. -
@UDb23 - I did test a cropped BD and it does work fine. I just used Photoshop and cropped the canvas width vs any image resizing so it kept the full 1080 height but I think that overlay uses integer scaling so I would need to get the correct dimensions as the height would need to be adjusted a little too.
I like the second option but not sure quite how to make a black overlay to test performance but if you think that's pushing the performance boundary maybe just going with the first option is better.
Right now I have Omega Race and Space Invaders that use BD's but I have a total of around 100 overlays from all the repositories but mainly from yours.
-
@Riverstorm said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:
how to make a black overlay to test performance
I can easily make it.. just a matter of finding the time..
you could then do the testing... -
@UDb23 - Thanks and take you time.
I was checking out Gorf. Now that's some hard positioning. The art in the zip looks clear and crisp but in game it's blurry. I think it has something to do with positioning coordinates. I messed with it a bit but not sure how it works to make the overlays clear. They use negative (under 0%) for the left panel and positive (over 100%) for the right panel.
It looks like they make an "all on" panel and an "all off" panel and then just use a black overlay mask with holes for what button is lit which is neat.
-
@Riverstorm said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:
Basically I can't see any messages like loading overrides, when I increment a save slot, screenshot, pause, etc. but everything does work correctly.
I am on RetroPie 4.4.4 and RA 1.7.5 on a Pi 3 using Plus commit 8ff5a43.You can also adjust the font size, colors and the position of the RGUI messages in RetroArch, so you can move them inside the game area instead of the default position and therefore the overlay won't occlude them. This way you don't need to change the overlay opacity.
Check the relevant options for
retroarch.cfghere:
https://github.com/libretro/RetroArch/blob/master/retroarch.cfg#L250-L270Because is RA's config, you can do this on a per-core/system basis too of course :)
Btw, great job you are doing with the backdrops guys! Looks amazing.
-
@hhromic said in mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support:
You can also adjust the font size, colors and the position of the RGUI messages in RetroArch, so you can move them inside the game area instead of the default position and therefore the overlay won't occlude them. This way you don't need to change the overlay opacity.
Thanks for the reply. It's actually inside the game area now and is working properly.
If you set the opacity to 50% I see the text faint but clear. Once you set the opacity to 100% it covers the on-screen display (OSD). Basically it looks like the OSD is a "layer" below overlays but above backdrops.
Normally I set my overlays to 50% but with the backdrops filling the screen I set them to 100% opacity to cover the portions of the screen that are covered with overlay to avoid bleed through.
I like that backdrops can fill the screen if you're not using an overlay. I think UDb23 is going to create a mask for testing performance. With updates Nayslayer did a while back there's some games with artwork masks that seem to work fine and performance is good I've tested yesterday/today. Gorf, Lunar Lander & Turbo all seem to work with multiple masking layers to give the effect of informational lighted overlays that look incredibly neat.
I wasn't able to get high enough to see Gorf or Lunar Lander change my mission/rank lighted panel from the starter light but Turbo has a speedometer with actual red "clock" style numbers and a green bar speed gauge that is probably a great example of what's possible with LED style overlays.
-
Here's a pic of what's happening as it probably shows it better. This is an overlay set to 50%. If set to 100% it's completely covered.
-
@Riverstorm yes that's exactly what I thought is happening :) No confusions :)
What I suggested in my previous post is to re-position the OSD messages further up and right, so they are not covered by the overlay/bezel. Instead the OSD messages can be positioned in the transparent "game area" window of the bezel.
I haven't tried it myself (no access to an RPI right now) but these options mentioned allow to position the OSD messages wherever you want in the screen.
I hope it's clearer :)
-
@hhromic - Ah ok, I see what you're saying.
That would put messages floating in the middle of the game area for some larger games. It would basically require me finding the overlay with the highest bottom right corner edge so the OSD is visible in all games with overlays.
I guess I prefer it down in the lower left corner of the screen for all games if possible as only about 1/3 of the games I run (around 100) have overlays. I think it would only require a change in layer order. I think OSD's should always be on top but maybe there's a situation where you don't want messages on top. Anyway I opened an issue on the RetroArch Github page.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.