rgbds

rgbds copied to clipboard

Adds a --analogue option which uses the Analogue logo instead of the Nintendo logo when fixing the logo.

I'm personally much against this.

For starters, since the .pocket format has deliberate (and undocumented) differences with GB ROMs, essentially any project building a .pocket file will already have a litany of IF (ANALOGUE) in their code. The logo should be one more of those. So an option to RGBFIX wouldn't be a good solution to this problem in the first place.

But beyond that, there is the moral/philosophical aspect of the option. If this option is supported, what stops fantasy console maker XYZ from making a new clone that has another slight set of differences that now have to be supported by RGBDS? Where does this stop? And if the answer to that question is "well, they're not as popular as the Analogue Pocket", then this constitutes official endorsement of the Pocket (as better supported than any alternatives), and that's something I definitely wouldn't want to see of any community-run tools.

If Analogue were themselves developing an open device, documenting all their finds about the original console (as far as I know, there are still internal aspects of the GB that Analogue emulates and hasn't disclosed), making development documentation available (e.g., for their .pocket format), not artificially restricting their emulator to not play GB ROMs, and so on; in other words, if they were actually making a community contribution; then maybe it would make more sense for community projects to support them. As it stands, it would just be a community project endorsing a commercial endeavor for no real reason.

Given that there are not currently multiple nonstandard fantasy consoles out there, I wouldn't mind supporting the big-name one that people commonly use. But, I think this is too much of a change for too little additional support. As ax6 pointed out, there are still conditional changes you would have to manually make in your code (e.g. the rLCDC and rSTAT values), so one more for the logo wouldn't hurt. And then you can just pass -f hg instead of -v to RGBFIX to not disturb the manually-placed logo.

As discussed here and on Discord, we'd rather go with arbitrary user-supplied logos. Issue #1398 covers that.

Given that there are not currently multiple nonstandard fantasy consoles out there, I wouldn't mind supporting the big-name one that people commonly use.

As fate would have it, there now are!

From the linked page:

Join us in continuing this timeless journey. Reach out and be a part of something extraordinary—simple, engaging, and unforgettable.

From the page linked from "Reach out":

Developer Contact Have a game that you’re looking to get published? Fill out the form below, and one of our representatives will contact you directly.

No form appears below. (I use Firefox 127.0 on Linux.) The error console in Firefox says something about a CORS request to shop.app that did not succeed.

They claim "Compatible with Game Boy®, Game Boy Color®, and Chromatic cartridges" and "perfect compatibility with every known Game Boy® title" (using "FPGA-based emulation"). I'm sure there are some bugs, but this does sound like the ModRetro is compatible with actual cartridges, which have the default Nintendo logo. Is there a video of their boot screen showing something else?

Pino: The form loads correctly for me (Firefox 127 on Linux with Ublock Origin), maybe an add-on is blocking it?

Rangi: ModRetro's site lists every game they sell as compatible with real Game Boy hardware except for Tetris, which is listed as Chromatic only (likely due to the terms of their licensing contract with The Tetris Company). The question then becomes how the Chromatic only mode is implemented (you'd either have to reach out to ModRetro for further information or wait for the Chromatic to ship), and whether using RGBDS to make Chromatic-only games is something you'd be willing to support.

Oh, it does say their custom cartridges are "Compatible With: Chromatic, Game Boy Color®", so I still doubt the logo has changed (nor other hardware.inc details like Analogue did), but yeah, we don't know 100% without testing.

The question then becomes [...] whether using RGBDS to make Chromatic-only games is something you'd be willing to support.

The tl;dr of that last point is that yes, we are willing to make it usable for the Chromatic; but we do not want to add specific support for it either, due to that bordering closer to implicit endorsement than we feel comfortable with.

(We can get away with this option more, because RGBDS is not batteries-included. The distinction above boils down to us being willing to enable battery-swapping where required, but not providing them ourselves. If that makes sense?)

There's also the last-resort option of someone forking RGBDS into a Chromatic-compatible version, much as forks suck. We'll see how things pan out.