Why is it wrong when we publish a run which uses an emulator bug from one of our emulators? And before you jump to answer that, bear in mind that some companies are reselling their old console games as PC games, making use of some of our emulators, bugs and all. Should we be publishing the results of relying on emulator bugs?
It's not that we know better. I'm sure Nintendo is aware of most of these bugs as well, and they just don't care about preserving the original game play. It's about the fact we are able to differentiate between the game itself, and other software. We know when a bug is part of the game itself or not.
Why exactly banning one of the options (the one where the resulting gameplay looks different enough) makes things better?
Yes, it's an official release. But it's an official derivative release in a buggier form. If we can extract and play it in its original platform, I think that's what we should do. That same "unique gameplay" might even be possible in emulators that we non-Nintendo employees make, but we reject those because it's not true to the original. Sure these new Wii emulators are officially sanctioned by Nintendo's greed, but they're still not true to the original game. We're intelligent enough to differentiate a pure game release, and a game release that's really supposed to be for a different platform.
So we plan for many games to just duplicate publish the exact same thing because we can relabel it Wii? Unless there's some significant in-game distinction, I don't see the point in us allowing this.
That seems awful to me. We're going to obsolete original games on their original platform because there's a poor emulator that makes it run faster?
Those features, not that I know of. But SGB games have other improvements like better sound via the SNES. I think we may have had a run or two which did that, but I could be mistaken. Donkey Kong on an SGB has the game adjusting the color throughout, and AFAIK, does this better than a CGB, and has better sound, it baffles me the game was submitted using CGB.
We're doing that now?
It includes similar logic to what the CGB includes to auto color games, but it also has extensive controls to edit the palette while the game is running. SGB even allows you to draw on the screen, like your own map, or hide the boss you're fighting, or other stuff.
If the game itself was designed for SGB it usually looks good. Although we had a discussion several years back where we noticed some SGB games were designed for the television aspect ratio, and other SGB games were designed for the DMG aspect ratio. It seems some companies/studios/teams preferred things one way, and others another. So playing it on the correct system you'd get perfect squares and circles and the other would give you rectangles and ovals.
The CGB firmware includes a list of somewhat popular DMG games to auto set their palette.
In some games though, if you don't manually select anything, it will indeed not look sensible. And as I said before, since it auto colors sprites different from background, in games where it was intended to blend together, that blend is now broken.
For these reasons, I'd like to pick this chance to reiterate my proposal: since the GBinGBC mode may make some games potentially uglier to look than GB, I think it should be allowed only for Moons & Stars.
Yeah, I was holding out hope that this problem would go away once the dev team better understood when STOP is bugged. But whatever it is, not working on console is pretty conclusive. :/ That doesn't mean this branch is doomed, because I DID find a way to avoid executing a STOP at all. If I activate the glitch while standing at course 5, Wario's Y position will be the start of a 3-byte instruction, which reaches just far enough to get past the STOP. Unfortunately that instruction is [LD SP,1054], which is a pretty awful one to have to work around. It also seems to be the only option, at least as far as standing at different courses goes. I haven't figured out a setup that'll fix SP on top of activating the debug mode, but I've got a few ideas. This isn't over yet.
imo the argument that the factory flashed FFs to carts is probably bullshit. Considering that you have to assemble the carts before you could do that and the process of writing FFs to SRAM is not exactly efficient to do at that point. It's fairly likely SRAM was just whatever "pattern" is left behind when it isn't powered (said patterns that Alyosha is referring to).
The use of the display mechanism for "Absolute Zero" and "Invisible Emulation" seems to be targeting different places within the bizhawk application. 1. It appears that "client.invisibleEmulation" is not tied to the DisplayConfig.cs. Is InvisibleEmulation a lower level access to cut of more updates to get faster speeds? 2. Absolute Zero is in fact tied to DisplayConfig.cs, but I don't have any way to access via lua. I would like to have this feature added for use with lua. My reason for bring this up is due to an "crash" that I receive when using client.invisibleemulation(true). So, instead...I have been manually selecting Absolute Zero to turn on/off the emulator display. I have looked at the lua examples in bizhawk and I don't see anything special about its use. When I use client.invisibleemulation, am I experiencing a bug or misuse? Also, does this in fact have a lower level of control on updates? I like this feature, as it would solve a problem that I'm trying to automate. Any information on this would be greatly appreciated.
But is it a legitimate demand? I see the demand mostly coming from people who are probably younger than a DMG, they probably never played these games on a DMG, they don't get how it subtly different.
Yet I don't see how that's a reasonable reason to use a platform the game was not originally designed for in our TASs.
Unlike elsewhere, we place high stock on original legitimacy, at least we did till now. We know things aren't perfect, but haven't we always preferred playing things in the most accurate and legitimate fashion?
Satisfy the audience's expectations.
Since when has TASVideos kowtowed to how some other site handled things? TASVideos has also never been about how easy or difficult it is to capture something. The nature of most early devices are going to be hard to capture, unless you directly wire them up to something. It is possibly to modify the original Gameboy to do stuff with it, and there actually is a large community now around modifying Gameboys and adding on all sorts of new features to them or swapping out various components.
