lr-mame2003 driver improvement and backport

markwkidd

@gamez-fan said

It would require some dev's with a bit of free time on their hands and a fairly large team of testers to put this right.

If you can help write a description of the work in the github issues, that would allow bounties to be raised for a bigger project.

darknior

https://github.com/libretro/mame2003-libretro/pull/218
https://github.com/libretro/mame2003-libretro/pull/219

@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.

Code via BritneysPAIRS

@gamez-fan Breath a sigh of relief it's my final commit .

darknior

Speedup hack for Street Fighter : https://github.com/libretro/mame2003-libretro/pull/221

@gamez-fan Code is via iq_132 and gives a large speedup and reduction in the overall memory requirements
when loading the graphical Roms for Street Fighter, this works very nicely on the Xbox im sure it'll
be likewise for all the platforms that use this MAME core.

Ok this is defo my last commit!! i simply forgot about this code which im sure you'll
agree was worth porting across.

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",
};