lr-mame2003 driver improvement and backport

darknior

Big performance boost for Midway V-Unit : https://github.com/libretro/mame2003-libretro/pull/222

@gamez-fan 0.94u5: Aaron Giles turned off debugging code in the hotspots, giving a huge speed improvement to the V-unit games.
To play these games you need to map a button for "Enter" as this is used as you go through some setup configs on first boot after that these are saved for every time you start the games thereafter.

markwkidd

@darknior said in lr-mame2003 driver improvement and backport:

To play these games you need to map a button for "Enter" as this is used as you go through some setup configs on first boot after that these are saved for every time you start the games thereafter.

Would you be willing to log a github issue for this? It should be possible to set up a default key for Enter. I don't have time this month but I may be able to take care of that eventually.

darknior

Attempt to fix some reported performance drops : https://github.com/libretro/mame2003-libretro/pull/224

@gamez-fan Add in the V-blank changes which were coded at the same time as the video changes happened for the FixEight bootleg i assumed maybe wrongly they were not needed, with a bit of luck this will sort the performance hit in batrider which has been reported on the forums.

Also since i was at it i added support for Knuckle Bash 2 which is just a bootleg of Knuckle Bash but
unlike that game this one does have full sound.

BuZz

Please can you clarify what is going on with this core? It looks like a lot of untested changes are being submitted, and a lot of reverts for many of them. There are people reporting new issues with the core, and I am considering forking and rolling back this core due to this.

eg

https://github.com/libretro/mame2003-libretro/pull/204

Revert because it broke all the games ? Why was a change submitted in the first place that had so many problems ?

BuZz

also - https://github.com/libretro/mame2003-libretro/issues/227

darknior

If we can choose what MAME core we want to use in the ES-SETUP ... why not, it's a good idea.
But it is not important for the common users. Nobody is using MAME core from source, it take time to compile, users are using BINary version.
Only testers are trying the source version to try games and compatibility.
If you only make a build when all is done, like you do for ES, it will be enough.

BuZz

@darknior

In regards to retropie that is not true. Binaries are updated all the time and I cannot be expected to just know when things are "unstable" - master branch should not be used for experimental and untested changes imho. Also for many platforms retropie is source only. From X86 to ODroid c2/xu3/tinkerboard and RPI on ubuntu etc.

For EmulationStation we have a stable branch - which I specifically manage so that's not comparable.

I'm not going to have a conversation in two places with you so please just reply here.

darknior

@buzz Yes for sure, if you update BIN all the time it is a problem.
Adding a DEV branch like we have some on ES can help.
Maybe you can add the dev branch to RP-SETUP like you add the emulationstation-dev last month.

arcadez2003

@buzz said in lr-mame2003 driver improvement and backport:

Please can you clarify what is going on with this core? It looks like a lot of untested changes are being submitted, and a lot of reverts for many of them. There are people reporting new issues with the core, and I am considering forking and rolling back this core due to this.

What issues exactly..?? as far as i can tell there were "two" one was infact a problem with a users build rather than my code changes per say,
the other problem was related to the Williams sound core which has now been fixed and BTW i have tested all the code personally.

@buzz said in lr-mame2003 driver improvement and backport:

Revert because it broke all the games ? Why was a change submitted in the first place that had so many problems ?

This happens all the time in MAME

arcadez2003

@buzz said in lr-mame2003 driver improvement and backport:

also - https://github.com/libretro/mame2003-libretro/issues/227

Again more general comments around "issues" what issues exactly

BuZz

@gamez-fan sample and performance issues mentioned on this forum. Plus the various issues that you yourself have put in revert comments. There have been a large amount of reverts. Stuff has been broken - good if the problems introduced have been fixed, but it seems a little experimental to me and I worry about further regressions.

BuZz

Regarding the revert I mentioned - from my perspective many of your changes do look untested, and backporting something that breaks lots of things can not really be compared to "this happens all the time in mame". Backporting changes in a way that breaks stuff that used to work is not a good idea imho.

I'm not currently convinced anyway, and even if upstream keep it as is, I may create another module and keep our existing mame2003 as it was before (or the other way around).

arcadez2003

As i explained in the other thread i have now tested every code change i have made and the games concerned and they seem fine, any major problems
that have cropped up have been reverted and fixed but if you want to roll the whole core back to before my first commit to be on the safe side then
feel free.

BuZz

@gamez-fan Glad you are testing the changes. I will rebuild binaries now and wait and see if there are new reports, but I still think if there is the possibility of newly introduced issues, it might be a good idea to have both the mostly vanilla core + the core with the backported code.

arcadez2003

@buzz said in lr-mame2003 driver improvement and backport:

@gamez-fan Glad you are testing the changes. I will rebuild binaries now and wait and see if there are new reports, but I still think if there is the possibility of newly introduced issues, it might be a good idea to have both the mostly vanilla core + the core with the backported code.

The build should be stable in it's currant form if there are issues im 100% sure if they are on the MAME side i can fix them.

Riverstorm

@darknior said in lr-mame2003 driver improvement and backport:

@gamez-fan The games will sound way better now, but folks will need new samples which are quite
easy to obtain via Twistys site FBA for example uses the same ones.

0.86u3: Donkey Kong sample improvements [Peter Rittwage, Derrick Renaud]. Added samples (run01, run02, run03, jump and dkstomp.wav).
0.86u3: Peter Rittwage and Derrick Renaud replaced the old climb and walk sample with three different samples. Replaced climb- and walk.wav with climb0, climb1 and climb2.wav and walk0, walk1 and walk2.wav.

This is nice! Should these sample sets have climb0.wav, climb1.wav, climb2.wav, walk0.wav, walk1.wav & walk2.wav?

Maybe a better question what is the sample file list used? I know MAME doesn't do a hash check on samples it only verifies the name.

Twisty's Older Samples:

dkstomp.wav
effect00.wav
effect01.wav
effect02.wav
jump.wav
run01.wav
run02.wav
run03.wav

Twisty's Unofficial Samples (Can be used for lower tone based on preference):

dkstomp.wav
jump.wav
run01.wav
run02.wav
run03.wav

arcadez2003

@riverstorm

As per the driver these are the samples you now need for Donkey Kong and Donkey Kong Jr.

static const char *dkong_sample_names[] =
{
"run01.wav",
"run02.wav",
"run03.wav",
"jump.wav",
"dkstomp.wav",
};

static const char *dkongjr_sample_names[] =
{
"jump.wav",
"land.wav",
"roar.wav",
"climb0.wav",
"climb1.wav",
"climb2.wav",
"death.wav",
"drop.wav",
"walk0.wav",
"walk1.wav",
"walk2.wav",
"snapjaw.wav",
};

Riverstorm

@gamez-fan said in lr-mame2003 driver improvement and backport:

As per the driver these are the samples you now need for Donkey Kong and Donkey Kong Jr.

Thanks @gamez-fan for the update. To take advantage of the new sound samples just download from source?

Thinking about this I can manually update these sample archives but without a new DAT isn't their going to be issues for the average user? The issue is with these new changes when creating a DAT from the official MAME executable or using the RetroPie supplied one will not produce a proper set of ROMs that work correctly. So games that have changed ROMs will be broken all of a sudden or you'll have to manually update each game archive (if you know about the change).

You need an updated DAT or at least a list of changed ROM's. Which may be tricky if done manually depending on the set types. I'm thinking split, merged, non-merged and where to place them. Such as in the parent in a split set (depending if it's common), directly in the game archive for non-merged and all-in-one if merged, etc. That can get messy for the average user pretty quickly.

Samples need to exist with the proper name regardless of hash to work and are interchangeable in these old versions depending on preference like Donkey Kong samples with high/low tone (depending on the machine you played on and aged hardware changing those tones). On the other hand I always believed ROM file hashing is necessary to know you have the correct ROMs to run a game properly.

For example if you need the ROM file c_4at_g.bin to run a game. It needs that specific code from that ROM chip to run properly or it will crash or do something unexpected. If you have a sample that's slightly different/off because it can't be properly emulated yet, it isn't going to crash the game, it will just play a sound that isn't correct or close.

Some old games (like Journey) will probably always have samples due to using a cassette/player in the cabinet.

Maybe branching is the answer but you would still need an updated DAT for people to take advantage of the changes being made. Two or three years down the road there could potentially be 100's of ROM changes branched from the original source. With back-porting and proper ROM dumps from newer versions some might even be easy fixes.

That's what works so well for MAME but against something like this is each version is completely standalone with an exact hash and name for each ROM file minus sample hashing but that still requires a properly named file.

I love what you're doing and hope you keep doing it as it fixes and improves games from an older version of MAME that works so well on a Pi! Your work is incredible! Now if you could get Xemophobe running so I can move it over from AdvMAME! ;)

maxbeanz

I really think this should be a separate build. If there are new ROMs added or changed then its not really lr-mame2003 anymore. It will undo peoples work of putting together a MAME 2003 set and they won't be able to copy there ROMs across in future to a fresh Pi build because some will need new ROMs and samples etc. Maybe this should be called lr-mame2003 EX or something so people have a choice of regular Mame2003 which works the same on all systems or this new Extra build.

arcadez2003

@riverstorm said in lr-mame2003 driver improvement and backport:

Thanks @gamez-fan for the update. To take advantage of the new sound samples just download from source?

If you know how to compile your own source then just grab the latest from the github, with regards to your other point around Rom
compatability most of my changes were to either add support for games that were not playable in MAME78 or to fix games that
did not work in MAME78, my other focus was to add sound to certains games that did not have it previously most of those
changes were codebased rather than Rombased per say but defo two games Fire Shark and Vimana would require a
new sound Rom.

So basically 99.9% of the working games that were supported in MAME78 the Roms have not changed and remain the same ones
as they always did i do plan to help and create a datfile along with markwkidd "if he still wants to do that" and we'll
get a good clean dat with which you guys can build your romsets.

@riverstorm said in lr-mame2003 driver improvement and backport:

I love what you're doing and hope you keep doing it as it fixes and improves games from an older version of MAME that works so well on a Pi! Your work is incredible! Now if you could get Xemophobe running so I can move it over from AdvMAME! ;)

Well i've kinda lost the love for this platform as im used to working with standalone Arcade Emulators rather than cores which are then stuffed into frontends
and can be more problamatic with regards to bugs eg Bally Midway games which Xenophobe is one being plain broken in this core when they should be perfectly
playable, im also kinda sick of certain ones on here who keep blaming my changes everytime a user reports a problem so i'll be moving on soon to find another
Arcade project to work on.

But i have one last update sitting on my desktop just now which will be worth backporting some sound improvements for the SNK6502 games some real classic in that driver