lr-mame2003 driver improvement and backport

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

caver01

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

with regards to bugs eg Bally Midway games which Xenophobe is one being plain broken in this core when they should be perfectly playable. . .
. . . i'll be moving on soon to find another Arcade project to work on.

This is sad to hear. Although I have not taken advantage of recent updates that enable more obscure titles, I have been hopeful that the Bally Midway stuff might in your sights as these are definitely a gap.

arcadez2003

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

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

with regards to bugs eg Bally Midway games which Xenophobe is one being plain broken in this core when they should be perfectly playable. . .
. . . i'll be moving on soon to find another Arcade project to work on.

This is sad to hear. Although I have not taken advantage of recent updates that enable more obscure titles, I have been hopeful that the Bally Midway stuff might in your sights as these are definitely a gap.

Well the problem with alotta the "bigname game" fixes and improvements from later MAME is the code is in no way compatable with this older core, if it was say
Libretro MAME79 then a hell of a lot more code could have been backported but i get the feeling there's a lotta people who would rather the core was left alone.

With regards to the Bally Midway and some Atari games i suspect the problem is not on the MAME side but more to do with Libretro specific changes that were
made to the core input code which break the service and dip handling in those games hence why they dont work, it would be fraught with danger to
touch that code so i'll leave it to those more experienced than me to tackle.

darknior

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

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.

Seriously?
DO NOT base your decision on three guys who are not happy while 1000 others say nothing and count on you to update MAME and run more games. Your work is excellent ! We love it ! Nobody never do it before !!!
Please continue, your MAME2003 is also use on many other platform with light processor, not only PI users ... and it's the most important.

darknior

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

there's a lotta people who would rather the core was left alone.

No, a little people ...

arcadez2003

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

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

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.

Seriously?
DO NOT base your decision on three guys who are not happy while 1000 others say nothing and count on you to update MAME and run more games. Your work is excellent ! We love it ! Nobody never do it before !!!
Please continue, your MAME2003 is also use on many other platform with light processor, not only PI users ... and it's the most important.

Well it's partly due to that the main reason however is i've just ran outta things that can be backported that dont require a full time commitment to work on ;)

darknior

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

i've just ran outta things that can be backported that dont require a full time commitment to work on

Arg, yes i understand ... but you can take your time to do it ... nobody work on MAME like you :(

arcadez2003

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

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

i've just ran outta things that can be backported that dont require a full time commitment to work on

Arg, yes i understand ... but you can take your time to do it ... nobody work on MAME like you :(

No there is another dev working away on something good :) i have a feeling a MAME build is coming that will blow everything supported on this platform outta the water

arcadez2003

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

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.

No great hardship or exactly a laborious task to create a new Rom and samples pack for 2017, we've done things like that on the Xbox for years!!!
but well i guess this is a different scene with a different outlook at the end of the day it's up to you guys to decide how you want this MAME core
to be released.

Riverstorm

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

No, a little people ...

Love that quote!

I have to ditto what you're doing is incredible. Code based vs ROM based changes. That's just a win-win for RetroPie and MAME 0.78. Better gaming on the same ROM set.

There's always resistance/challenges to change and new ideas when introduced, it's just human nature. We're creatures of habit. It would be a loss of a tremendous asset to see you move along! >:( I think there's one more thing...here...that needs fixed! Oh and one more here and here and here...

I can't help to think what @markwkidd said...what you're doing is important to the community and as @darknior pointed out it's not just one platform benefiting.

No there is another dev working away on something good :) i have a feeling a MAME build is coming that will blow everything supported on this platform outta the water

That sounds very interesting! Is there a place to follow this development?

i've just ran outta things that can be backported that dont require a full time commitment to work on ;)

Life outside of MAME! Never...ok...maybe...maybe once in a while I walk outside and take a look at the big burning orange ball. I think they call it the sun. Then I am good for a few weeks.

arcadez2003

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

That sounds very interesting! Is there a place to follow this development?

It's all underground just now but trust me when it drops you'll know about it!!

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

Life outside of MAME! Never...ok...maybe...maybe once in a while I walk outside and take a look at the big burning orange ball. I think they call it the sun. Then I am good for a few weeks.

Oh i have other FBA based projects that are keeping me busy just now ;)

Riverstorm

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

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

@gamez-fan Do you have a list of changed ROMs for the updates you implemented by chance? I think you said it wasn't many. I can update the DAT if you do. I updated the main DAT so it rebuilds with the correct Donkey Kong and Donkey Kong Jr. samples and has the correct merge information for clones, bootlegs, etc.

The other sets like "mame2003-lr-working-no-clones" look they used RomLister and all the merge information has been stripped. It also seems more games were removed than should be. It doesn't contain games like Donkey Kong and Donkey Kong Jr. for example which I believe are Nintendo.

Donkey Kong:
1 Parent
6 Clones

Donkey Kong Jr:
1 Parent
6 Clones

markwkidd

If you do update the DAT, could you please start with the official MAME 2003 DAT? If you don't already have it, you can download it here: https://github.com/libretro/mame2003-libretro/tree/master/metadata

In the long term I'm interested in either merging the new DAT info into the existing XML DAT, or creating a secondary "hacks" DAT that only incorporates the changes. Anything you can do will be welcome progress though! I don't expect to have time to work on this personally until next month.

Riverstorm

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

If you do update the DAT, could you please start with the official MAME 2003 DAT? If you don't already have it, you can download it here:

Thanks Mark I grabbed the one from the RetroPie docs but I'll grab the one posted in the repository due to the off chance they are different.

Samples are pretty straight forward (name and sampleof) but to update the ROM information I would need the name, size (in bytes), CRC hash & SHA1 hash. It looks like the merge tags are correct so converting between say ClrMamePro and ROMVault should work fine, as well as, parent/clone relationships. I do have the current MAME and rollback romset so really I just need to know which files are changing or like an existing file that's being renamed, shared, etc.

Riverstorm

@markwkidd - I merged the new samples for Donkey Kong & Donkey Kong Jr and added 'hack' to the end of the file name. You have a place to upload it?

I don't know if there's any value to knowing exactly which sets are using the samples. but possibly to check for any errors. Such as Radar Scope uses the same samples as Donkey Kong or Street Heat - Cardinal Amusements uses the same sample set as Donkey Kong Jr.

If the update didn't take these "other" games into account they will break or I can just update the samples for the changed games if there's a more specific list of exact games/clones updated. Leaving the existing samples intact for the "other" games.

For example if Radar Scope is looking for effect00.wav (a file in the original dkong.zip
sample) it will not work as Radar scope's parent for samples is dkong and it's been completely removed from all sets with the new samples.

Unless of course all clone games have incorporated the new sample changes. Which some of the "other" games might not even use the new samples. The two examples mentioned above are actually parent games using samples from other parent/clone games. Hopefully that makes sense.

darknior

https://github.com/libretro/mame2003-libretro/pull/228
https://github.com/libretro/mame2003-libretro/pull/229

0.88u7: BUT added sample support to Sasuke' (hit.wav, boss_start.wav, shot.wav, boss_attack.wav).
0.88u7: BUT added speech sample support to Fantasy' (ft_voi-0 - ft_voi-b.wav).
0.88u7: BUT added speech sample support to Vanguard' (vg_voi-0 to vg_voi-f.wav).
0.88u7: MAME32 Improved sample support for Rockola driver HD38880 speech by samples.
0.81u5: Curt Coder added Vanguard SHOTB sound effect.
0.81u4: Curt Coder hooked up SN76477 sound in Fantasy, Nibbler, Pioneer Balloon, Sasuke and Vanguard

@gamez-fan Fully tested no Roms have changed but to take advantage of the full range of
sound improvements new samples are needed for Fantasy, Sasuke and Vanguard
these are easily obtained from the old samples folder on Twistys site.