Donkey Kong color palette for FBNeo hacked into mame2003-libretro

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.

barbudreadmon

@mahoneyt944 Thanks for the clarification, my bad for assuming the backports were limited to mame2003-plus. I suppose there is really no easy way to know with certainty the status of a specific game in those ports without trying it then.

Riverstorm

@barbudreadmon - Wouldn't it be useful to link the changelogs on the Libretro page. I might have missed them somewhere? I apologize if so as I usually look on the Github page for core stuff.

For the 3rd time, we do if asked...

Sorry, I see many posts that say we (being you or is it FBNeo?) don't do requests. I might have misread that somewhere but this is good news. I guess I would ask for a core option or dip switch setting to switch between the old and new colors in FBNeo for Donkey Kong, please. I haven't updated in a while and maybe it's already there, if so thanks in advance.

Whew, the [bold type] was super effective for conveying your point! ;) Anyway, I'm glad we are in agreement that backporting it to mame2003+ was good. The new colors look great! I guess we can finally put this to bed and move on.

mahoneyt944

@barbudreadmon this just isn't a realistic expectation. The fact is that games like dkong in mame.078 were considered correct at that time and therefore labeled as such. By proxy, lr-mame2003 is subject to this same issue since it derives from mame.078. When you felt you wanted to label the colors as imperfect, I merged your submissions and updated the dat files to reflect this correction. As I agreed it was imperfect. Likewise after the colors were corrected, I updated the dats to show them as corrected.

I'm not sure where your argument stands here? Why isn't emulation perfect? Because it's emulation. Likewise, documents reported on imperfect emulation maybe also be imperfect. We do the best we can, offering updates as we come across things and I feel we have done a fair job at trying to do so.

arcadez2003

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

@barbudreadmon this just isn't a realistic expectation. The fact is that games like dkong in mame.078 were considered correct at that time and therefore labeled as such. By proxy, lr-mame2003 is subject to this same issue since it derives from mame.078. When you felt you wanted to label the colors as imperfect, I merged your submissions and updated the dat files to reflect this correction. As I agreed it was imperfect. Likewise after the colors were corrected, I updated the dats to show them as corrected.

I'm not sure where your argument stands here? Why isn't emulation perfect? Because it's emulation. Likewise, documents reported on imperfect emulation maybe also be imperfect. We do the best we can, offering updates as we come across things and I feel we have done a fair job at trying to do so.

Well you can remove that GAME_IMPERFECT_COLOURS flag now from Donkey Kong at least :)

Oh well looks we're gonna be busy importing all the information from the arcade database into our core documentation files to make sure every game with emulation issues is reported as such at least it'll mean those with an agenda to talk down our core at every turn wont need to now as all the imperfections will be listed in plain sight for all to see.

Not that anyone really reads the docs right.??

Riverstorm

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

@mahoneyt944 Thanks for the clarification, my bad for assuming the backports were limited to mame2003-plus. I suppose there is really no easy way to know with certainty the status of a specific game in those ports without trying it then.

I don't believe there is a way. mame2003, as it was, before any of the updates were ported was a real clunker to say the least. The ghost inputs were a pain. If you used it back then you would have no questions really.

Anyway, after 2003+ had run the changes for a while and were proven stable they were ported over to mame2003.

If you saw how it was before the 100s of changes were poured into it I don't think you would even wish to use it. I always thought 2003+ was vastly superior until all those changes were ported over.

So it kind of gets the best of both worlds. A stable consistent ROM set (that is everywhere), as well as, the more recent improvements and updates. That is unless you prefer the older incorrect colors.

I can live the wrong colors but when capcob offered an option, I think the general consensus was to move forward and implement the correct color change over the previously thought correct colors.

mahoneyt944

I'm going to dip out of this thread since it's far past the scope of the original post.... But I'll end by saying that I would be happy to aid anyone who wants to improve on mame2003 or mame2003+ through it's code and/or documentation of. I just ask that whomever wants to, creates specific and focused issues in there respective repos with feasible expectation and reasonable propositions for correction.

Thanks

Riverstorm

@mahoneyt944 - I agree, I think everything that could be said has been said. I guess it boils down to two camps. Those that wish to keep the older incorrect colors and those that wish to play with the newer correct colors.

I just don't feel a need to "toggle" between the two. It's almost comical if you think about it. Arguing over a red-ish color vs. a pink-ish/purple-ish color. If anyone notices the color change while playing as a guest in my home I'll be sure to let you know! ;)

Riverstorm

Oooops...a slight adjustment to saturation on my monitor and it's off again...Happy Holidays fellas!

barbudreadmon

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

Sorry, I see many posts that say we (being you or is it FBNeo?) don't do requests. I might have misread that somewhere but this is good news.

We don't accept new machine requests.

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

I guess I would ask for a core option or dip switch setting to switch between the old and new colors in FBNeo for Donkey Kong, please. I haven't updated in a while and maybe it's already there, if so thanks in advance.

We'd have implemented it if someone had made the request, but the consensus for those players until now was to use mame2003.

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

I just don't feel a need to "toggle" between the two. It's almost comical if you think about it.

What's not comical is people being extremely narrow-minded about nostalgy while talking about retrogaming.

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

Oh well looks we're gonna be busy importing all the information from the arcade database into our core documentation files to make sure every game with emulation issues is reported as such at least it'll mean those with an agenda to talk down our core at every turn wont need to now as all the imperfections will be listed in plain sight for all to see.

I never talked down mame2003-plus, on the contrary i have been recommending it, did you read the libretro arcade documentation since i rewrote most of it ?

arcadez2003

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

I never talked down mame2003-plus, on the contrary i have been recommending it, did you read the libretro arcade documentation since i rewrote most of it ?

Did i explicitly mention your name nope, anyway i've better things to be doin than argue the toss on here im off to code now.