Donkey Kong color palette for FBNeo hacked into mame2003-libretro
-
@barbudreadmon - its a good question.
I guess I've spent a while building a system that only uses mame2003-libretro and which in almost every other respect I like - the hack was easy enough and I didn't like being forced to use a different core for one game.
-
@capcob Please wrap code / logs in three backticks above and below. I have edited your post. See http://commonmark.org/help/ for more information on markdown.
-
@BuZz Sure and thanks for correcting my post.
-
@capcob Hmmmm ok, it seems kinda extreme though, especially since more recent emulators offer improvements that aren't limited to dkong's colors.
On a sidenote, i believe your code is incomplete, and instructions might have been useful.
-
@barbudreadmon - I have .git patch available should any other 'extremists' want it š
-
@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
-
@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.
-
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.
-
@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
-
@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
-
@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!
-
@capcob - Also they are still tweaking, improving and adding games to m3plus so I would add +1 as interested.
-
@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. -
@barbudreadmon I would only add it as an option to toggle to support both ways for that very reason.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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/f086d1e85bc693703bf92ae8af1b0993ce02acf6A 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
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.