Donkey Kong Spooky Remix in Retropie?

[mitu]

@SpudsMcToole said in Donkey Kong Spooky Remix in Retropie?:

What does that actually MEAN? Retropie's docs are scattered all over the place, that could mean any of a hundred files.

There's a link at top of the Forum - Docs. This is where the RetroPie documentation resides.

[SpudsMcToole]

@mitu I know where they are. They're a massive multi-level multi-branching nest and just saying "it's in the docs, dummy" is not a helpful response. Particularly when the answer to the question "Does anyone know why DK Christmas Remix just stopped working?" is not going to be in there anyway.

Jeez, it's not like I went up to this guy personally and DEMANDED he fix my problem RIGHT THIS MINUTE because I'm ENTITLED. I asked - on a general help forum designed for that exact purpose - if anyone knew why a game that worked 48 hours ago had stopped working, because I'd already spent hours trying to solve the problem without success, and I detailed some of the (entirely rational and logical) steps I'd tried, to save people time suggesting things that had already not worked.

I'm not sure that really merited such a prickly yelling-at.

[SpudsMcToole]

PS From those docs:

"Note: the process of verifying and rebuilding ROMs is complex and requires a substantial investment of time and effort in order to master. If your goal is to have working ROMs, it is almost always simpler to download a full ROM collection that has already been verified to match the emulator you chose."

Couldn't agree more. In the case of FB, it appears that the "correct" ROMs change on literally a daily basis, and it's already hard to figure out what they're meant to be. According to the all-knowing docs, they're "FB Neo v0.2.97.44". I've been involved in emulation, both personally and professionally, for 25 years. I know my way around. But I have not the slightest idea what ROMset that actually is or where it might be found. No file under that name exists in any of the numerous places I know of where these things usually are.

It really is asking quite a lot of people to keep on top of this stuff at the same time as being hyper-prissy about refusing to actually direct people to ROMs.

I try to contribute back as well as taking. I wrote an extensive normal-person-language guide to setting up obscure systems in MESS and posted it here. I've done a lot of graphics stuff - bezels, box art etc - because that's something I can do even though I'm hopeless at coding. I try to answer other people's questions if I can. And I know from many years of personal experience that when you make stuff for free, people can still be really dickish about it and it's easy to get pissed off and snap at them. I just don't think that was very fair in this case.

[mitu]

@SpudsMcToole said in Donkey Kong Spooky Remix in Retropie?:

Couldn't agree more. In the case of FB, it appears that the "correct" ROMs change on literally a daily basis, and it's already hard to figure out what they're meant to be. According to the all-knowing docs, they're "FB Neo v0.2.97.44". I've been involved in emulation, both personally and professionally, for 25 years. I know my way around. But I have not the slightest idea what ROMset that actually is or where it might be found. No file under that name exists in any of the numerous places I know of where these things usually are.

It changes often because new things are added and that's a good thing. As for where you can find that ROMset, I can assure that I've seen it a few times. For FBNeo, you can rebuild the ROMset using a complete MAME ROMset archive and the .dat file from the project's page.

And I know from many years of personal experience that when you make stuff for free, people can still be really dickish about it and it's easy to get pissed off and snap at them. I just don't think that was very fair in this case.

You've done that exact same thing with lr-fbneo, where @barbudreadmon is the main developer.

[barbudreadmon]

@SpudsMcToole i spent time answering to your "capsed" questions in https://retropie.org.uk/forum/post/200689 :

• i explained why your previous replacement of dkongx11 with an unsupported rom wouldn't work anymore, in the simplest way possible.
• i explained what you need to have valid romsets, what's important in their content, in the simplest way possible.
• i told you i would add this hack next
• i pointed you to some guidelines on how you can port a hbmame driver to fbneo, in case you were interested (i thought you would be, considering your request for hacks support, you think you don't have what it takes, fair enough, i wasn't expecting anything about this, i'll be mentioning a fact though : until a few years ago when i started working on fbalpha, the most i could do with C/C++ was reading a documentation on how to print "hello world" in a terminal)

Your answer ? More caps and complaints about not understanding, especially not knowing anything about concepts clearly explained in the retropie documentation, while you claim you search documentation before posting anything. I think i was totally right to be pissed off by this.

@SpudsMcToole said in Donkey Kong Spooky Remix in Retropie?:

it appears that the "correct" ROMs change on literally a daily basis

Nope, a given romset for a specific game might change every few years at most, people who say maintaining romsets is time-consuming are wrong, for a given game to stop working in fbneo, since detection of files inside a romset is crc-based instead of name-based, it would mean someone in the world opened a cabinet and desoldered stuff on the pcb to dump it and the result of his dump was different (and more correct !) than known dumps, it doesn't happen everyday.

[Riverstorm]

@barbudreadmon - Nice, that's great to have CRC matching in FBNeo. I have been exploiting it for a few years now using it to merge 3 different Neo-Geo BIOS file sets. Those being mame2003, mame2003-plus and FBNeo. A single file to run them all. I would leave FBNeo with native names but rename mame2003 and mame2003-plus conflicts. Now I can name FBNeo files to whatever too! ;)

[SpudsMcToole]

@barbudreadmon "Nope, a given romset for a specific game might change every few years at most, people who say maintaining romsets is time-consuming are wrong"

Ah, so the docs you're so angry at me for supposedly not reading are in fact a load of rubbish?

[spud11]

@barbudreadmon Hi. I think I understand the changes to DK's .cpp file you've made for Spooky.

Two questions I have please: Is the 0x01000 (for example) a reference to the size of the bin file? If so, how do you calculate or find this from the bin file?

[grant2258]

@barbudreadmon said in Donkey Kong Spooky Remix in Retropie?:

@SpudsMcToole said in Donkey Kong Spooky Remix in Retropie?:

People say "there's a dat", as if we have a clue what that is, where it's located or what we're meant to do to what with it.

Which means you never read retropie's arcade documentation, neither forum rules that says to search documentation before asking stuff, should i congratulate you or something ? Or should i pity you ? "poor poor guy, he doesn't have a few minutes to spend reading a documentation people spent hours writing".

Are you serious there ?

no need to be little a user acting like your better because you think your a better coder it really in bad taste imho. The user was asking for help no need for insults it doesnt reflect well on the community. Pointing to a link to read would be more helpful in this case

[barbudreadmon]

@spud11 said in Donkey Kong Spooky Remix in Retropie?:

Two questions I have please: Is the 0x01000 (for example) a reference to the size of the bin file?

Exactly, to get the right value you just have to get the file size (4096 here) and convert it to hexadecimal (1000, which you then pad with 0x0 at the left, 0x is to tell C/C++ it's an hexadecimal, and the zeros are for driver cosmetics), but in this case you don't even need to do that, see https://github.com/Robbbert/hbmame/blob/0d44f5dfa936c820507bc1408c6c246ce513e238/src/hbmame/drivers/dkong.cpp#L306-L335 , the size are already in there (3rd argument in the ROM_LOAD calls).

Another example, for dkchrmx the fbneo driver will look like this :

// Donkey Kong Christmas Remix (Hack)

static struct BurnRomInfo dkchrmxRomDesc[] = {
	{ "c_5et_g.bin",	0x01000, 0xba70b88b, 1 }, //  0 maincpu
	{ "c_5ct_g.bin",	0x01000, 0x5ec461ec, 1 }, //  1
	{ "c_5bt_g.bin",	0x01000, 0x1c97d324, 1 }, //  2
	{ "c_5at_g.bin",	0x01000, 0xb9005ac0, 1 }, //  3

	{ "dkchrmx.bin",	0x10000, 0xe5273cee, 2 }, //  4 braze

	{ "s_3i_b.bin",		0x00800, 0x45a4ed06, 3 }, //  5 soundcpu
	{ "s_3j_b.bin",		0x00800, 0x4743fe92, 3 }, //  6

	{ "v_5h_b.ch",		0x00800, 0x0b92cc7a, 4 }, //  7 gfx1
	{ "v_3pt.ch",		0x00800, 0x6a04f93f, 4 }, //  8

	{ "l_4m_b.ch",		0x00800, 0xc6ddc85f, 5 }, //  9 gfx2
	{ "l_4n_b.ch",		0x00800, 0x2cd9cfdf, 5 }, // 10
	{ "l_4r_b.ch",		0x00800, 0xc1ea6688, 5 }, // 11
	{ "l_4s_b.ch",		0x00800, 0x9473d658, 5 }, // 12

	{ "c-2k.ch",		0x00100, 0xc6cee97e, 6 }, // 13 proms
	{ "c-2j.ch",		0x00100, 0x1f64ac3d, 6 }, // 14
	{ "v-5e.ch",		0x00100, 0x5a8ca805, 6 }, // 15

	{ "diag.bin",	0x1000, 0x00000000, 0 | BRF_OPT },
};

STD_ROM_PICK(dkchrmx)
STD_ROM_FN(dkchrmx)

struct BurnDriver BurnDrvDkchrmx = {
	"dkchrmx", "dkong", NULL, "dkong", "2017",
	"Donkey Kong Christmas Remix (Hack)\0", NULL, "Sock Master", "Miscellaneous",
	NULL, NULL, NULL, NULL,
	BDF_GAME_WORKING | BDF_CLONE | BDF_ORIENTATION_VERTICAL | BDF_ORIENTATION_FLIPPED | BDF_HISCORE_SUPPORTED, 2, HARDWARE_MISC_PRE90S, GBF_PLATFORM | GBF_ACTION, 0,
	NULL, dkchrmxRomInfo, dkchrmxRomName, NULL, NULL, DkongSampleInfo, DkongSampleName, DkongInputInfo, NULL,
	dkongxInit, DrvExit, DrvFrame, dkongDraw, DrvScan, &DrvRecalc, 0x100,
	224, 256, 3, 4
};

Just a copy/paste and replacing a few values.

@SpudsMcToole said in Donkey Kong Spooky Remix in Retropie?:

Ah, so the docs you're so angry at me for supposedly not reading are in fact a load of rubbish?

No, "Note: the process of verifying and rebuilding ROMs is complex and requires a substantial investment of time and effort in order to master. If your goal is to have working ROMs, it is almost always simpler to download a full ROM collection that has already been verified to match the emulator you chose." is certainly true (if you never did it), the only rubbish here is the fact you are using it as an excuse for not knowing anything from the arcade documentation, while you admitted above that you don't know where to get the "simpler to download full ROM collection" in the first place.

@grant2258 As i already said ignore me and i'll ignore you, i still hold you responsible for barry harris getting the easy way out after scamming the fbneo team.

[spud11]

@barbudreadmon Thank you so much. That's brilliant. Learnt something new today.

[barbudreadmon]

@spud11 No problem, and i just added dkchrmx to fbneo (sorry i was busy yesterday).

[grant2258]

@barbudreadmon

I dont even know barry harris i will agree to ignore you on this subject. Its nice to not be rude to people even ones learning the ropes :).

[spud11]

@barbudreadmon Thank you. I appreciate it.

[SpudsMcToole]

@mitu said in Donkey Kong Spooky Remix in Retropie?:

You've done that exact same thing with lr-fbneo, where @barbudreadmon is the main developer.

Wait, when? Is this all about a comedy caps line that was directed at a log file, not a person? Sheesh.

Anyway, I'm delighted that both games work now, so my sincere and genuine thanks to barbudreadmon, even if s/he is a grump.

[JimNeatface]

While we're talking about Kong variants, is kong2600 supported by fbneo or anything else?

[barbudreadmon]

@JimNeatface Not previously but using the same method i explained above, you would convert https://github.com/Robbbert/hbmame/blob/0d44f5dfa936c820507bc1408c6c246ce513e238/src/hbmame/drivers/dkong.cpp#L135-L161 to this :

// Donkey Kong (2600 graphics, hack)

static struct BurnRomInfo kong2600RomDesc[] = {
	{ "c_5et_g.bin",	0x1000, 0xba70b88b, 1 }, //  0 maincpu
	{ "c_5ct_g.bin",	0x1000, 0x5ec461ec, 1 }, //  1
	{ "c_5bt_g.bin",	0x1000, 0x1c97d324, 1 }, //  2
	{ "c_5at_g.bin",	0x1000, 0xb9005ac0, 1 }, //  3

	{ "s_3i_b.bin",		0x0800, 0x45a4ed06, 2 }, //  4 soundcpu
	{ "s_3j_b.bin",		0x0800, 0x4743fe92, 2 }, //  5

	{ "k2600.3n",		0x0800, 0x0e6a2a6d, 3 }, //  6 gfx1
	{ "k2600.3p",		0x0800, 0xca57e0f4, 3 }, //  7

	{ "k2600.7c",		0x0800, 0xcf450a43, 4 }, //  8 gfx2
	{ "k2600.7d",		0x0800, 0xd5046907, 4 }, //  9
	{ "k2600.7e",		0x0800, 0x1539fe2a, 4 }, // 10
	{ "k2600.7f",		0x0800, 0x77cc00ab, 4 }, // 11

	{ "k2600.2k",		0x0100, 0x1e82d375, 5 }, // 12 proms
	{ "k2600.2j",		0x0100, 0x2ab01dc8, 5 }, // 13
	{ "k2600.5f",		0x0100, 0x44988665, 5 }, // 14
};

STD_ROM_PICK(kong2600)
STD_ROM_FN(kong2600)

struct BurnDriver BurnDrvKong2600 = {
	"kong2600", "dkong", NULL, "dkong", "1999",
	"Donkey Kong (2600 graphics, hack)\0", NULL, "Vic Twenty George", "Miscellaneous",
	NULL, NULL, NULL, NULL,
	BDF_GAME_WORKING | BDF_CLONE | BDF_ORIENTATION_VERTICAL | BDF_ORIENTATION_FLIPPED | BDF_HISCORE_SUPPORTED, 2, HARDWARE_MISC_PRE90S, GBF_PLATFORM | GBF_ACTION, 0,
	NULL, kong2600RomInfo, kong2600RomName, NULL, NULL, DkongSampleInfo, DkongSampleName, DkongInputInfo, DkongfDIPInfo,
	dkongInit, DrvExit, DrvFrame, dkongDraw, DrvScan, &DrvRecalc, 0x100,
	224, 256, 3, 4
};

There is an additional trick here, see the dkongInit ? In the first 2 hacks we were using dkongxInit (because that's what dkongx11 is using, and those 2 hacks seem to run exactly the same way considering you are supposed to replace this romset), it is the function used to initialize the emulated hardware.

The reason we won't be using the same is actually quite simple, see https://github.com/Robbbert/hbmame/blob/0d44f5dfa936c820507bc1408c6c246ce513e238/src/hbmame/drivers/dkong.cpp#L518-L519, if you look at args 4 & 7 you'll notice they (dk_braze/init_dkongx) are different from this hack (dkong2b/empty_init), those are the initialization functions in hbmame (afaik mame/hbmame uses 2 args instead of 1 for modularity purpose).

In hbmame kong2600 uses the same initialization than dkrainbow (btw it is actually the same initialization than "standard" dkong hardware), dkrainbow is already supported by fbneo and uses dkongInit for initialization, so we'll also use this function for kong2600.

PS : kong2600 is now available in fbneo if you rebuild from sources.
PS2 : if someone else want another variant, i hope some people will try applying what i tried to explain, contributors are always welcome.

[JimNeatface]

@barbudreadmon Thanks very much! it runs perfectly.

I wanted to ask, why is the rivets screen on the spooky remix a differnt colour to HBmame? (HBmame on the left)

[spud11]

@barbudreadmon Thanks for including kong2600 too.

I noticed with hbmame it's got several other DK variants such as Donkey Kong Reverse. Adding the drivers doesn't look too difficult based on the excellent advice you've provided, so I'd like to try to add these variants to the drivers list and recompile, if possible.

I've successfully compiled FB Neo's source by downloading it from your github repository to my Pi , going to the FBNeo-master/src/burner/libretro folder and compiling it on my Pi with make -j5 -f Makefile platform=rpi3.

However, it takes some time to compile. I've had a look at deleting some of the drivers and so forth, but that looks quite challenging, and so I was wondering whether FBNeo has a SUBTARGET flag or, even better yet, an ability just to target one driver like d_dkong.cpp which I note is in the FBNeo-master/src/burn/drv/pre90s/ folder.

Thank you for any advice.

[barbudreadmon]

@JimNeatface Oops, you are right, it seems we overlooked the dkongx based clones when we fixed dkong's palette last year, it should be ok now.

@spud11 No, there is no parameter to build only subtargets in FBNeo.