lr-mame2003 driver improvement and backport

maxbeanz

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

with regards to Altered Beast i just played the first two levels and didn't run into
any Gfx issues i used this version GAME( 1988, altbeast, 0, altbeast, altbeast, altbeast, ROT0, "Sega", "Altered Beast (Version 1)" )

Did you test this on Retropie/Retroarch ? I have the same issue, when you hit the enemies they freeze and you can walk through them. I think the game works fine on all systems except the Retroarch version. A lot of games in lr-mame2003 don't work properly whereas the original MAME 2003 versions work fine. Probably something wrong with the Libretro code.

arcadez2003

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

Did you test this on Retropie/Retroarch ?

No a MAME72 build on the Xbox, i just wanted to make sure folks weren't using the non working version 2 Romset.

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

I have the same issue, when you hit the enemies they freeze and you can walk through them. I think the game works fine on all systems except the Retroarch version. A lot of games in lr-mame2003 don't work properly whereas the original MAME 2003 versions work fine. Probably something wrong with the Libretro code.

Alotta the input and graphical code has been changed, i suppose so that it's endian safe for multiple platforms, problem is it might be these changes
which will likely be the cause of the Bally Midway games refusing to coin or locking into service mode on boot or the graphical problems your getting
with Altered Beast or as you say lots of games just plain not working all of which you dont get when using the original MAME78 build.

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.

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.