Donkey Kong color palette for FBNeo hacked into mame2003-libretro

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.

Ashpool

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

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

Ok, this is getting way off-topic ... but here my 2ct on that one:

Does it? For pure mame it is the good ol' (youngest) history dat/xml to check, but finding out what fixes/updates and to what extend a vintage lr-mame port may or may not have received such updates/back-ports and where a particular rom (+lr-core used) may plot into the official mame-history always had a PITA/Lost Case feeling for me. In this example of dkong I simply would have no idea how to document/changelog/datfile this in a easy-for-the-average/casual-user case that dkong in lr-mame2003 look differently to the very same rom used in standalone mame 0.78.
Maybe with an easy to understand readme /diff (not changelog) listing the relevant/observable (from a users POV) differences between those two cores (lr-mame .version to mame .version) - but even then it ain't trivial for a user to predict which lr-vintage core may incorporate features/fixes a younger one (compared by year/version alone) does not include.

P.S.: Simply put, from a users-pov, I would assume that mame-feature and behaviour wise lr- and standalone cores of a given version behave the same and updates/usability/added features are to be found on the libretro/retroarch functionality of the lr-core only (may even be including switches/options to alter the mame core behaviour from there, but so that they are transparent towards the user). But as I see now, even such a simple assumption seem to be somewhat naive.

mahoneyt944

@Ashpool I'm not sure what other type of document is needed, there's already multiple levels to cover an array of situations. These are to name a few,

For example, mame2003-plus:

the actual commit with details, for example the latest commit https://github.com/libretro/mame2003-plus-libretro/commit/dc90a6ad071a8a28edfc0154f42c0d7f8c129e00
a changelog details for most changes in more detail https://github.com/libretro/mame2003-plus-libretro/blob/master/CHANGELOG.md
a constantly updated compatibility table, detailing individual games https://buildbot.libretro.com/compatibility_lists/cores/mame2003-plus/mame2003-plus.html
and as a last resort, the repository has an place for issues to be answered by DEVs https://github.com/libretro/mame2003-plus-libretro/issues

Ashpool

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

For example, mame2003-plus:

Nice that you used the exception from the expectation of (what i assume to be) an average-user reading the docs ;) Ok, my fault I should have included/mentioned that core in my previous reply: As a start mame2003-plus is here in the docs listed with Romset 0.78-0.188 and as you pointed out it is pretty good documented, but by giving a range for the romset it takes itself out of the context of what I tried to express in my previous post. Which, now I try to focus on it, is that fixing a driver from an older core by version is a nice move and in benefit of most users, but it is not predictable/obvious/self-explanatory that a core using a .givenversion romset is emulating/dealing with it in a way that deviates from the corresponding stand-alone mame. Or in other words, even if the columns title is "required ROM Set version", at least I for myself (and I can't be the only one) ever read it as "this core corresponds to mame version" - In fact, this Topic here is the first time I became aware of it, that it is static romset, not static core (mame2k3+ as the noted and well explained/documented exception).

Riverstorm

@barbudreadmon - For the sake of argument we'll assume. I would add that I don't believe he wasn't aware there are "twin" cores until you pointed out to him in the thread.

How many thousands of games are broken in some fashion for years and when a proper fix is presented the devs implement the correction. If I understand you correctly you want to make a dipswitch or core option to revert to the older incorrect coding/colors?

AFTER FBNeo corrected the colors why did you decide to submit a PR to 2003+ stating it has the wrong colors? You had no interest in 2003+ DK colors until AFTER FBNeo corrected it.

Does FBNeo provide all the documentation you expect of 2003+? I can't find it. Can you point me to those links?

Does FBNeo create a dipswitch or core option to rollback/play every correction it makes to the core as you expect of 2003+? I can't seem to find those in the core either?

Shouldn't FBNeo be accommodating it's users with those options? Isn't that what emulation is about you said yourself.

If you had a core or dipswitch rollback for every change it would be a dizzying size list of options that simply aren't needed.

Why do you continue to try to control the 2003+ narrative and marginalize Mahoney's points of view. He gave you a clear and concise description, why not use that one?

Why not link all the documentation links he provides? Instead you keep changing it to what you want and not what the core devs are stating is more proper.

Why don't you allow Mahoney & Arcadez to make the decisions? They fix the core regularly and are around most days to answer question if need be.

They aren't required to accommodate all your needs and demands of the core. If you want the change they should do it because, well...you want it?

If you want the option why not submit the PR yourself to get it implemented? If you don't want to do it, then allow the core team team to make decisions of what to implement.

Emulation isn't about accommodating 100s of unusual settings/preferences for the .01% user base. If the userbase is happy, for the most part, then that should be good enough. "For the most part we had a good day" is great way to end the day. I think most users are happy with the core and they are improving it all the time.

More importantly at least let the core team that puts in the blood, sweat and tears into 2003+ make those decisions.

This has become a silly conversation. It's more stressful defending the core. Libretro locked the discussion thread because you keep pressing the issue. You were the ONLY opposition in the thread.

If they get 100s of requests for the old wrong colors then maybe they could try and accommodate users. Right now it's one, it's you only, and I have yet to hear you prefer the old colors? Do you?

Are you saying you're representing the 100s of users who use 2003+ and want the old colors? WAIT, there hasn't been a single request for the older wrong colors here, on the official thread or on Github.

I think you need to trust the 2003+ team can handle the core development. Allow them to make the decisions they feel is relevant to the core.

WAIT, it's to late, they already implemented the change, can't you respect their decision and move on. It's done, it's over. The decision has been made. Please extend the same courtesy to 2003+. It's time to move on now to the next update.

barbudreadmon

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

It seems pretty predictable to me

The predictable behavior is having more recent versions of the emulators being more accurate. Let's take the example of the contra fix, i doubt that game was mentioned as having incomplete emulation in any of your compatibility lists prior to that fix, meaning they aren't exactly reliable, and if i understand well, the game is fixed in 2003, broken in 2010/2014/2015/2016 (?), fixed in current. I find this hardly predictable.

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

was there any other information that you were confused about?

None, i was simply wrong about the arcade database being reliable when checking the status of a game for a specific vintage of (non-plus) MAME.

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

AFTER FBNeo corrected the colors why did you decide to submit a PR to 2003+ stating it has the wrong colors? You had no interest in 2003+ DK colors until AFTER FBNeo corrected it.

For the 3rd time, i opened an issue on mame2003-plus to fix this back in 2018, with links to the related changes in FBAlpha, so they could backport it, it was only 4 years later, since nobody seemed intent to backport those changes, that i finally decided to submit a PR to correctly document this as a fallback solution.

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

Does FBNeo provide all the documentation you expect of 2003+? I can't find it. Can you point me to those links?

Our highly detailled changelogs can be found at https://neo-source.com/index.php?topic=980.0 , https://neo-source.com/index.php?topic=2487.0 and https://neo-source.com/index.php?topic=3656.0

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

Does FBNeo create a dipswitch or core option to rollback/play every correction it makes to the core as you expect of 2003+? I can't seem to find those in the core either?

Shouldn't FBNeo be accommodating it's users with those options? Isn't that what emulation is about you said yourself.

For the 3rd time, we do if asked, and i gave a specific example.

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

If you had a core or dipswitch rollback for every change it would be a dizzying size list of options that simply aren't needed.

It doesn't since they are game-specific settings in dipswitches

For the remainder, please stop saying i was against backporting this to mame2003+, this is a lie and it is really getting on my nerves now.

mahoneyt944

@Ashpool I feel a lot of confusion and possibly even false assumptions are out there for these cores. Some of that results from the fact these are not RetroPie cores or historical mame captures. Mame already has historical references of their legacy code, which is available to anyone who desires to use it. Any document not issued by libretro directly should be considered 2nd hand information, mindful that this is not implying that 2nd hand documents are not useful. Plenty of users read these and for the most part are reliable just the same. Be mindful that RetroArch and it's cores are already their own entity outside of RetroPie.

The big issue here, is that once one of these legacy versions of mame gets modified for use in RetroArch (in this case mame.078)....It's no longer "original". So then how much change is acceptable or not, does it even matter? Well this very argument is the entire reason mame2003-plus was spawned from mame2003 which in itself is a spawn from historical mame.078.

So what's the difference? When these changes began happening in mame2003, Users were upset that after updating their mame cores, games which were compatible before were no longer compatible due to romset updates meaning it forced users to update their roms anytime they updated the core. Well to over simplify an otherwise lengthy debate, It was determined that mame2003 would maintain a static romset for easy of setup on the user, and therefore would not receive updates which altered the romset. So if you have a romset for mame2003, you're good, now and always.

mame2003-plus however is different, it receives all updates to get as many games compatible as possible even if that means updating romsets. This of course means mame2003-plus is a hybrid and requires a "one off" romset that isn't tied directly to any one version but will have improvements in many ways over mame2003.

I guess the issue left to navigate is should libretro create transparency on every alterations made to it's cores from the projects they branch from. Well in my opinion, I feel they do their best to do this as you can see in some of the link references in my previous post, however I can't see why they would be required to.

If a person is a die hard mame.078 fan, the only way they can truly use that version is to use the unaltered historical standalone version, period. Any and all cores from libretro will have alterations from the original source.

But nothing to fret here because libretro can have as many cores as it's likes. So anyone has the ability to create a dedicated mame2003-historical reference core with only the most minimal alterations to fit into RetroArch architecture. Likewise, RetroPie has the ability to downgrade any core to a previous version if they feel they don't want their user base using the current version.