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.
But how do we ensure heavy glitches aren't used in a given run? That sounds like something impossible to really check, because there could be glitches we don't even know about, not obvious, but affecting important stuff. Also limiting something in the rules to "slight glitches only" feels kinda arbitrary.
Or maybe someone could say, the only glitches that are possible in this mode are insignificant and unimportant? I'm not a GB expert for such a call. As I said, it would be much better if we had examples of glitches that obviously break things.
It does not explain how a judge allowed this to be published this way.
Ganon has a variety of attacks, and the fight is just picking a random one every time (much like in Missingno.) When Solgryn tested a particular attack, he just made a button to start that attack immediately, so he doesn't have to wait for it to show up randomly. He forgot to remove it before the release: every time you press 1 you'll put Ganon in "your face will die" attack. By "main board" I mean "not numpad". This glitch is also allowed in RTA runs. I agree that it can be interpreted as a debug code, but in TAS the same result can be achieved just by getting a good attack, like "join me and be the greatest": he stays in place for long enough.
Playing a single episode or individual game to completion, or all episodes or games, is considered game completion. Playing multiple, but not all, episodes or games is not considered completion.