Donkey Kong color palette for FBNeo hacked into mame2003-libretro

capcob

@barbudreadmon - I have .git patch available should any other 'extremists' want it 😂

barbudreadmon

@capcob said in Donkey Kong color palette for FBNeo hacked into mame2003-libretro:

I have .git patch available

it might have been a good idea to just post a link to that patch then

capcob

@barbudreadmon - it's something I wanted to share info about, given that mame2003 has not been patched for so long, but like you say maybe not something for which there is much demand.

If anyone requests the patch here I'll share it with them.

capcob

Having said that it should be a trivial exercise for any C developer to substitute the palette values shown above, for those currently calculated in mame 2003.

barbudreadmon

@capcob said in Donkey Kong color palette for FBNeo hacked into mame2003-libretro:

mame2003 has not been patched for so long

Vintaged cores are meant to be that way

mahoneyt944

@capcob this is an interesting solution to the issue, as a current maintainer of mame2003-plus, and I suppose mame2003 by proxy, this could certainly be added as an option. Ideally I'd like to backport the proper code making this obsolete but this is a nice way of getting it closer without digging too deep into the code base.

I went ahead and posted this in the repository directly, feel free to post your patch there for reference. https://github.com/libretro/mame2003-plus-libretro/issues/1494

Riverstorm

@capcob - Any improvements to the old cores are a nice addition. I still use m3plus as one of my staple cores so thanks for this hack, pretty clever idea!

Riverstorm

@capcob - Also they are still tweaking, improving and adding games to m3plus so I would add +1 as interested.

barbudreadmon

@mahoneyt944 I kinda remember some users mentioning they were using mame2003 because they had a preference for the reddish color, so leaving that core as-is would probably be for the best tbh.
As for mame2003-plus, i opened an issue about that several years ago, with possibly some links that might help backporting this.

mahoneyt944

@barbudreadmon I would only add it as an option to toggle to support both ways for that very reason.

barbudreadmon

@Riverstorm i'm assuming you are wilstorm from github :

I've always considered you knowledge and suggestions very sound (I still do). I think FBNeo is a fantastic core by all accounts. I'm trying to be objective as I can but I just don't quite understand why the particular stance on this update. Especially a toggle feels a bit over the top but kind of a cool idea for the nostalgic.

I've heard you ask on the RP forums once why would anyone want to use mame2003-plus Donkey Kong when FBNeo has accurate colors. Now mame2003-plus can have those same accurate colors. Ding!? Wouldn't that be a great reason to support your fellow core. Some of the comments through the years on the RP forums you seem to steer folks away from mame2003-plus. To me this and FBNeo are the two best cores for low spec hardware so I support both and use both.

Since the discussion was abruptly locked i'll answer here again : i have always been in favor of mame2003-plus having this fix and even opened an issue about it back in 2018.

On the other side, i still don't think it's right for mame2003, whose incentive is "MAME as it was in 2003", to emulate things differently from how they were back in 2003 without providing a mean to revert to the older behavior, especially since i remember some users giving feedback about prefering the older colors, it should be trivial to turn this into a dipswitch.

Anyway, it was a good lesson, and i won't involve myself anymore with the development of cores that aren't FBNeo.

Riverstorm

@barbudreadmon - Looking at the post I believe the Github pull was meant for mame2003-plus and not mame2003.

I think it has been implemented in the more contemporary 2003+ which has lot of updates and left out of vanilla 2003. The best of both worlds…one new core and one old.

“MAME as it was in 2003”… Is that of core slogan or something?

I think Arcadez split the core [years ago] so as to leave vanilla MAME as is…”as it was in 2003”…because of concerns from other members posted in another thread.

barbudreadmon

@Riverstorm said in Donkey Kong color palette for FBNeo hacked into mame2003-libretro:

Looking at the post I believe the Github pull was meant for mame2003-plus and not mame2003.

This is a PR on mame2003 repo, so it's not about mame2003-plus. I was the one suggesting in this PR that mame2003-plus would be a better candidate for those kind of changes. Again, i was always in favor of this fix being applied to mame2003-plus, and you seem to have a big misunderstanding about that.

@Riverstorm said in Donkey Kong color palette for FBNeo hacked into mame2003-libretro:

“MAME as it was in 2003”… Is that of core slogan or something?

It's mame2003's current description.

@Riverstorm said in Donkey Kong color palette for FBNeo hacked into mame2003-libretro:

I think Arcadez split the core [years ago] so as to leave vanilla MAME as is…”as it was in 2003”…because of concerns from other members posted in another thread.

It was originally meant that way, but apparently that's not the case anymore. The situation with the different mame cores right now seems extremely confusing to me, with mame2003 getting backported fixes that aren't even available in mame2010. Well, i'll update the libretro documentation one last time to make mention of this.

mahoneyt944

@barbudreadmon i don't understand this notion that mame2003 can't receive updates. This just isn't true. In mame2003, there are restrictions on updates however, updates should not change the romset as to keep the romset static. So a user who has a complete set today will have a set that will always works with mame2003. This still allows for updates which do not effect the rom base. For example, bootstraps to improve game startups, or overflow fixes as to not let the core crash, or in this case a color correction. None in which change the rom base required by the core.

Mame2003-plus however is not static it gets any and all updates in the goal of "making it work". Which means romsets also change.

Riverstorm

@barbudreadmon - Here's the conversation in question in it's entirety. It's an interesting read for sure and was locked by the Libretro guys above you.

I don't think @capcob stated if he meant it for mame2003 or 2003+. It was posted in both repo's. We probably shouldn't assume we know where he wanted initially unless we ask him.

With @capcob being a new contributor I feel like you kind of came out of the gate criticizing and challenging him. He seems a bit upset in the thread too if you read it.

I don't quite understand why you seem upset. You shared how you think it should be implemented. I think the 2003+ guys heard you but they chose to implement differently. They didn't want toggles or dip switches. Is that the reason for being upset?

I saw in the thread you stated there was no change log. I think they do have a change log and most of the major changes are recorded there. Mahoney pointed out that not all changes are recorded because some contributors wish to remain anonymous and don't want the recognition.

I think Mahoney has shown he his capable and dedicated to making the core as good as it could possibly be. It seems Libretro likes the work he's doing as he continues to spearhead the core.

No where in the thread, that I could find, did anyone ask you to not share your opinion or collaborate with them. You said you're not going to poke your nose in other cores and as far as I can tell it's due to the fact it wasn't implemented as you'd like to see it done.

People are entitled to change their minds. Maybe at the time in '03 they thought they had it right. I don't know but I can't find anyone else that agrees with you to keep the old wrong colors. Even if you find a few folks that agree I would guess a majority prefer the correct DK colors. It seems you're the only person that has concerns with the color change. The colors were changed to properly reflect the original arcade cab and that's a great thing.

The cores aren't in competition they are meant to compliment one another and now both cores have the proper colors for Donkey Kong.

I would also give a big thanks to @capcob for being so kind to share the color correction with one or both cores depending on how the core devs decide to implement it.

arcadez2003

@barbudreadmon said in Donkey Kong color palette for FBNeo hacked into mame2003-libretro:

It was originally meant that way, but apparently that's not the case anymore. The situation with the different mame cores right now seems extremely confusing to me, with mame2003 getting backported fixes that aren't even available in mame2010. Well, i'll update the libretro documentation one last time to make mention of this.

With regards to MAME2003 the general consensus is that romsets and or samples are not updated nor are games added which were not
supported originally in MAME78, this helps to keep things simple and non changing for the userbase...

But as it has been explained this does not mean that fixes and improvements cannot be ported across from the MAME2003+ project as long
as the rules as laid out above are adhered to, i've not been as active as some of the other devs in this area my last commit was 18 months back
https://github.com/libretro/mame2003-libretro/commit/f086d1e85bc693703bf92ae8af1b0993ce02acf6

A simple fix for a classic game which had no sprites and was missing the road layer previously, it made no sense to leave it in that state seeing
as we had the fix in MAME2003+ and since nothing but code was changed the only a difference a user would spot is the game now worked
instead of being totally unplayable.

But yes i take your point the both changelog and the core documentation should have been updated to reflect this

arcadez2003

Anyway it's good to see this fixed even if the colours being wrong ever so slightly in Donkey kong didn't bother me one iota

As let's be honest here due to the workload required to sort this eg updating the MAME2003 resnet graphical code and then
every driver and video file in the core connected with it before we even get to dkong was always going to be a nonstarter unless
someone had a mountain of free time on their hands and the will to actually attempt it.

This was never as it has been suggested more than once on here a simple case of backporting a small gfx fix from the latest
MAME or FBNeo cores.

arcadez2003

@Riverstorm said in Donkey Kong color palette for FBNeo hacked into mame2003-libretro:

I saw in the thread you stated there was no change log. I think they do have a change log and most of the major changes are recorded there. Mahoney pointed out that not all changes are recorded because some contributors wish to remain anonymous and don't want the recognition.

Sure if changes are minimal they're not worth typing up personally i always tend to add em if for no other reason than it helps to inform
the users of new game additions or emulation improvements to the games we already support, promotion more or less which also has the
added benefit of helping to dispel the myths peddled by some with an "agenda" to talk down MAME2003+

That it's always better to use the newer cores in all instances due to all the fixes and improvements even if said games would then become
unplayable on many devices of choice as a result, MAME2003 was all about performance MAME2003+ is the same allbeit this core also has
a good whack of the same fixes and improvements mentioned as per the latest cores as the dev team have backported them.

Best of both worlds performance + emulation improvements a winning combo and the main reason MAME2003+ endures much to the
annoyance of some i mean if the games played as bad as they like to make out if they were as broken and busted as they suggest then
this core would have died out years back but here we are 2022 and the core is still going ever so strong.

But ya know the more they whine the more they complain the more i want to keep on going just to put their noses out of joint :)

barbudreadmon

@Riverstorm said in Donkey Kong color palette for FBNeo hacked into mame2003-libretro:

I don't think @capcob stated if he meant it for mame2003 or 2003+. It was posted in both repo's. We probably shouldn't assume we know where he wanted initially unless we ask him.

The intent of the OP was very clear though, he sent the PR to the non-plus repo, and @mahoneyt944 was the one who decided to backport it to plus.

@Riverstorm said in Donkey Kong color palette for FBNeo hacked into mame2003-libretro:

With @capcob being a new contributor I feel like you kind of came out of the gate criticizing and challenging him. He seems a bit upset in the thread too if you read it.

I became aware that some players actually do prefer the "bad" redish colors because i have been troubleshooting thousands of arcade players over the years on forums, reddit and discord. This was something i already mentioned in a previous discussion. There is nothing very surprising about that nostalgy tbh, for 13 years they were the only colors available when emulating dkong arcade, and even after mame fixed it many users kept using emulators with the older colors. There is also the nostalgy coming from the nes port, nes palette is heavily dependent on your tv, and with some models you were playing donkey kong at home with the same "bad" red color.

A few years ago i implemented sprite buffering in FBNeo's cps3 emulation (it's required to avoid a few gfx issues) but a user complained about this because it dabbled in input lag, so i ended up implementing a dipswitch to disable sprite buffering. All of this to say accommodating preferences, however unusual they seem, is also a part of emulation. Emulation is not only about being accurate, or you wouldn't have emulators cutting loading time, upscaling things, replacing sprites/textures, adding control hacks, just to name a few.

My only intent here was to improve the fix and provide the best of both worlds, sorry if it was perceived as criticism. I was not upset by that contributor or his change, it doesn't mean much for me since i wasn't asking this out of self-interest. I was kind of disappointed nobody seemed to understand that though, but i suppose it was impossible from the moment grant2258 shifted that discussion from "sharing opinion" to "me bullying a contributor".

@mahoneyt944 @arcadez2003 dully noted, i updated the libretro documentation accordingly, now for accuracy it says :

Theoretically, more recent version of the emulators should always be more accurate, which means the graphics, sound and gameplay of the games are more likely to be faithful to the original cabinet. In reality, for vintaged MAME cores, with fixes being backported to some vintages and not some others, the situation is not so predictable.

mahoneyt944

with fixes being backported to some vintages and not some others, the situation is not so predictable.

It seems pretty predictable to me, as it was explained twice in this thread.

Mame2003-plus can receive any update.
Mame2003 can receive any update that doesn't alter the rom base.

While I know that's enough to satisfy the majority of the user base, we also cater to those wanting to dig in a little deeper, including a changelog freely available to view, and for those looking to really split the 1s and 0s, the commit history details individual changes. We also allow users to ask and/ or request any additional information directly at their respective repositories.

We also offer compatibility tables which show a brief representation of game compatibility within each core. https://buildbot.libretro.com/compatibility_lists/

@barbudreadmon was there any other information that you were confused about? I'd be happy to help resolve any misunderstanding you're having.