Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
We could also limit this to just VC, at least for now.
First of all, we can't even know if they used any of the emulators available on the internet, or made their own.
I've spoke to other emu authors about this. We don't think Nintendo used any of our emulators wholesale, although we do think they may have taken some bits and pieces here and there due to the occasional quirk that exactly matches a particular emulator. In the case of releases by other companies though, we know for a fact that a bunch of them are using our emulators, and often we even know exactly which version.
feos wrote:
Since randomly substituting games in the VC layer doesn't always result in a playable game, those could be either barebones emulators targeting only specific games, or not even emulators in the usual sense, but running some game programs on actual hardware. Nintendo said about VC SMB that “emulation program in question was created by Nintendo internally”, and I couldn't find evidence disproving that.
I imagine Nintendo has more of an emulator library that they made in general, and they compile it with whatever components they find is necessary for the game in question. Therefore it's a bit hit or miss whether some other game will work. In some cases, they also needed to make some minor tweaks to the game to get it to work. Those tweaks won't necessarily break the game on the original platform, but at the same time, other games would need similar tweaks to run on their emulator.
Based on my discussions with other emu authors, Nintendo has developed its own software internally for this purpose. If they took anything from us, it was something minor.
There can also be games that seem emulated, but it's more of a mix, as when the game reaches certain points, it knows to run some code (typically to play audio/video) for the primary system, not the emulated system. In these cases I would agree it's meant for the more modern system, and it's using some pseudo-emulation for only part of it.
feos wrote:
Second, I feel strongly against requiring people to fiddle with officially shipped game images. We've only ever allowed it in cases when the game would've been simply unTASable otherwise, and now outright require it unless the extracted image itself doesn't work?
Requiring people to fiddle is a broad concept. In some cases you just pop the medium the game came on into your computer, and copy some files. In some cases you might need to use a decompression or extraction tool. In the worst case you might need to sit down and manually pull some pieces of out it by hand, but that's generally rare when considering all the cases one game is wrapped up into another or is part of some kind of bundle.
When we talk about tampering with the game, what is the game? If you consider the emulator part of the game, then yes you're tampering with it. If you consider the actual game the part you're extracting from the rest of it, then you're not tampering with anything.
feos wrote:
That breaks the authentic connection between the game image and the environment it was made for
We can agree exactly on this point, but use it differently.
I consider the game image and the environment it was made for is the original console it was created for, not the new package on a more modern system being shipped with an emulator.
feos wrote:
Third, if we require extracting those games, we should ensure that it comes from the actual VC release, and that it was extracted cleanly, without additional edits.
Well, the judge and publisher would need to get their copy of the game from somewhere, just like we do for everything else. We should not just be accepting something from the submitter saying this is the game.
feos wrote:
This will have to be verified by the judge, by reproducing the extraction process and comparing the results to what was used in the movie, or by comparing what was used in the movie to some "known good" database. Does such a database exist, like we have redump for example?
Funny you should mention this. As far as I know, I was the first person to extract a game from some bundle, at least in a public fashion. ~20 years back, a movement was starting online to build a database of different games. I worked on some of these databases. I extracted a bunch of games from within others that I had on standard mediums and added them to these databases. At first people were surprised as to where these came from, but when I said I just copied them off this CD or that floppy or extracted from that zip file, and they did the same and found they had matching games.
For the more modern systems doing this, I admit I don't know what the database situation is like these days. However if the people handling those databases are competent, they should be keeping track of extracted games as well.
As to "known good", that's highly arguable. I found many things that were labeled as "known good" in various databases to be flawed. As just one example, I'm responsible for practically eliminating the over-dump situation with SNES games. Prior to that, you had hundreds of over-dumps floating around that were considered perfect dumps, but they weren't.
feos wrote:
Finally, are we sure extracting games in this manner is perfectly legal?
Yes, absolutely.
feos wrote:
We don't want emulators to be illegally used in such bundles of course, and we don't want bootleg bundles. But we can't suspect VC releases in any of that so far.
AFAIK, all the VC releases should be 100% legal. My point was I feel the situation of accepting emulated releases to be problematic, and opens the door to a lot of problems. Legality is also a concept that depends on where you live, and we do have Chinese TASers for example. I'd prefer if we stuck to something that doesn't come back to bite us later. At the same time we can have what I consider a more authentic game experience, and not something slapped together with little care just to make more money.
To share an example from a different situation, Nintendo changes their consoles through the lifetime of the console. Early SNES consoles had boards with multiple chips on them. Later SNES consoles used a system-on-chip, and ran a bit differently. Some early SNES games have various bugs using these later SNES consoles. SNES emulator authors (and clone console creaters) purposely have been targeting the inner workings of the earlier SNES consoles in order to avoid bugs.
Here's the words of another SNES emu author, emphasis mine:
yeah, nintendo's own soc was *****
i don't even consider it when i think snesglitches on the first line comes from cheap ***** that's unable to output this early despite the whole undisplayed line 0 to delay it
for the sound glitches, i'm guessing that nintendo didn't have the rights to integrate sony's spc700 in their clone
due to not exactly being in good terms at that time
so they probably used a cheap chinese knockoff
There's clearly a scale regarding what different people consider original, compatible, or designed for.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Well I get the impression that in your opinion, allowing people to TAS VC images as they are (even if the extracted game works properly) is absolutely fundamentally completely unacceptable and no one is allowed to ever question this, but I'm not seeing any examples of actual problems with the future of tasvideos if we still allow people to TAS VC images as they are, without extrapolating this to anything less known and common, like bundles where we know an existing emulator has been included.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Alyosha wrote:
I think it's also worth pointing out here that over the past couple of years, several of the examples of running GB games in GBC mode and making TASes of them, with the goal of console verification, has directly lead to significant advancement in emulation accuracy.
How do you know it's making it more accurate? Maybe it's making that particular mode more accurate, but it's not accurate to the original? Unless you're verifying it on an original DMG-01, I don't know on what grounds you can assume it's more accurate.
feos wrote:
I finally read the linked thread about problems in GBx games in later modes. They don't seem to even discuss all those "subtledifferences" only old DMG experts can spot. They talk about games that either don't run at all, or have obvious glitches in audio or graphics.
Have you been reading the same thread I have?
Sachen games are usually incompatible with anything newer than whatever was around when it was released. I have one of their mono 4 in 1s from the mid 90s which doesnt work on a GBC or up. And Beast Fighter, which is also a mono game - even though it was released in 2000 - does work on a GBC, but not a GBA.. unless you use a Game Genie, then it works maybe 1 out of 10 times. Sachen is weird.
Sounds like some randomness difference, which Alyosha mentioned earlier, so that's not obvious glitches in audio or graphics is it?
Burai Fighter (the original monochrome one) doesn't work right on the GBA, and possibly the GBC. You die almost instantly as soon as the first boss appears.
Doesn't sound like obvious glitches in audio or graphics, does it?
I don't know why, but for some reason most of the replies in this thread again and again keep missing the main point. It's not about the A/V issues, those we can easily see. It's the differences we cannot easily see. If reading back from the output is being used, or something that relies on specific timings or something else, the CGB will act different from the DMG. There's ample evidence of this, the cause behind this is known. I don't get why you keep ignoring this. From the two comments I just quoted, you see it goes deeper than just what is being output.
feos wrote:
Why are the rules being modified unilaterally? Judges are not supposed to modify the rules, only clarify them.
In the past 5 years, we've had many discussions between admins and judges regarding changes to the rules. We had various threads about them, discussion in the staff channel, some changes we announced publicly. We asked admins and judges if they like the new wording or not. I don't recall seeing any discussion about anything Mothrayas did here, at least not in the usual staff places. So I don't think anything about those rule changes are legitimate.
feos wrote:
People that support GB-in-GBC are those who currently contribute to GBx emulator coding, to GBx console verification, and to GBx TASing. If that doesn't make the demand legitimate, I don't know what does.
If they're using a CGB or AGB to benchmark what a DMG is supposed to be doing, then I don't see how it's even remotely legitimate.
feos wrote:
In addition to those, staff members also agreed (here and on discord) that unless there are obvious problems with newer modes, console verification is a good enough reason to allow those modes.
Why are important staff discussions taking place on Discord? When I said let's make the Discord channel official and put it on the site so anyone can find it, I also said it's not to be used for official business that requires our senior staff.
Regarding console verification, all I see is you verifying with some other platform, which is similar yes, but not the same. So I don't really see you verifying anything.
feos wrote:
Suggested rule.
[*]If glitches that are caused by newer mode hinder gameplay, we don't want that mode.
[*]If glitches that are caused by newer mode are obvious to unarmed eye/ear in normal viewing conditions, we don't want that mode.
Agreed.
feos wrote:
[*]If glitches that are caused by newer mode can't be easily noticed and don't hinder gameplay, the newer mode is allowed for the sake of console verification.
Disagree. What does hinder even mean?
feos wrote:
[*]If newer mode doesn't cause any glitches at all, it's allowed.
What's considered a glitch here? Although if we know some game in particular runs identically down to the last detail on either platform, then I would agree we can run it on either platform.
feos wrote:
Categorization seems to need that publications of DMG games are labeled as GB, but how do we automate that in the parser?
Does the file format include what system the game is supposed to be for?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Well I get the impression that in your opinion, allowing people to TAS VC images as they are (even if the extracted game works properly) is absolutely fundamentally completely unacceptable and no one is allowed to ever question this
Why not just TAS the game on the original system?
Why are we publishing nearly identical runs for the same game twice?
If you're just looking to exploit bugs in the emulator, then what are you even doing? Then why not exploit bugs in any emulator? It's how people remember the game because more people have an emulator than the original.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I finally read the linked thread about problems in GBx games in later modes. They don't seem to even discuss all those "subtledifferences" only old DMG experts can spot. They talk about games that either don't run at all, or have obvious glitches in audio or graphics.
Have you been reading the same thread I have?
Sachen games are usually incompatible with anything newer than whatever was around when it was released. I have one of their mono 4 in 1s from the mid 90s which doesnt work on a GBC or up. And Beast Fighter, which is also a mono game - even though it was released in 2000 - does work on a GBC, but not a GBA.. unless you use a Game Genie, then it works maybe 1 out of 10 times. Sachen is weird.
Sounds like some randomness difference, which Alyosha mentioned earlier, so that's not obvious glitches in audio or graphics is it?
No, it's saying that the game "doesnt work on a GBC or up", does not work on a GBA, or "works maybe 1 out of 10 times".
Nach wrote:
Burai Fighter (the original monochrome one) doesn't work right on the GBA, and possibly the GBC. You die almost instantly as soon as the first boss appears.
Doesn't sound like obvious glitches in audio or graphics, does it?
No, it talks about the game not working, you die where you shouldn't be dying, and therefore you can't even complete the game.
Nach wrote:
I don't know why, but for some reason most of the replies in this thread again and again keep missing the main point. It's not about the A/V issues, those we can easily see. It's the differences we cannot easily see. If reading back from the output is being used, or something that relies on specific timings or something else, the CGB will act different from the DMG. There's ample evidence of this, the cause behind this is known. I don't get why you keep ignoring this. From the two comments I just quoted, you see it goes deeper than just what is being output.
If you can't play the game and complete it, it's not even remotely a "subtle difference we cannot easily see". It's an obvious problem.
Nach wrote:
feos wrote:
[*]If glitches that are caused by newer mode can't be easily noticed and don't hinder gameplay, the newer mode is allowed for the sake of console verification.
Disagree. What does hinder even mean?
It means the bug is getting in the way of normal gameplay in some way.
Nach wrote:
feos wrote:
[*]If newer mode doesn't cause any glitches at all, it's allowed.
What's considered a glitch here? Although if we know some game in particular runs identically down to the last detail on either platform, then I would agree we can run it on either platform.
Any bug in how a given mode replicates the other one
Nach wrote:
Does the file format include what system the game is supposed to be for?
It has the ROM name that the author used, but it can vary, and one has to match the hash (also contained in the header) against some list of games, and determine the intended mode from that.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
it's saying that the game "doesnt work on a GBC or up", does not work on a GBA, or "works maybe 1 out of 10 times".
Yes, exactly.
feos wrote:
Nach wrote:
Burai Fighter (the original monochrome one) doesn't work right on the GBA, and possibly the GBC. You die almost instantly as soon as the first boss appears.
Doesn't sound like obvious glitches in audio or graphics, does it?
No, it talks about the game not working, you die where you shouldn't be dying, and therefore you can't even complete the game.
Great. Now tell me why it's happening?
feos wrote:
If you can't play the game and complete it, it's not even remotely a "subtle difference we cannot easily see". It's an obvious problem.
Again, you're missing the point. I don't know how many ways I can explain this. There is a subtle difference causing the obvious problem here. This subtle difference will exist in many games, even when it's not obvious.
feos wrote:
It means the bug is getting in the way of normal gameplay in some way.
How do you define normal gameplay?
feos wrote:
Any bug in how a given mode replicates the other one
Terrific. Therefore you cannot consider "verification" made with only the new system to necessarily replicate the other one. You won't know if there's a bug or not until you do proper verification.
feos wrote:
Nach wrote:
Does the file format include what system the game is supposed to be for?
It has the ROM name that the author used, but it can vary, and one has to match the hash (also contained in the header) against some list of games, and determine the intended mode from that.
ROM image file name is meaningless.
It'd be better if the file format would include some information copied from the game's header.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
No one is suggesting to ban TASing it on the original system.
Nach wrote:
Why are we publishing nearly identical runs for the same game twice?
If they're nearly identical, we can prefer some version we agree about.
Nach wrote:
If you're just looking to exploit bugs in the emulator, then what are you even doing?
Even you admit that VC is not simply emulation. It's some kind of a virtualization+expansion layer on top of the original games, tweaked or not, developed specifically for those games, packaged as an integral game image for Wii, and officially distributed by the copyright holder.
Nach wrote:
Then why not exploit bugs in any emulator? It's how people remember the game because more people have an emulator than the original.
VC releases have huge player base, it's how they remember those games that they have legally purchased from the creator of Wii and the copyright holder of those games. If other publishers release their IP bundled with emulators they haven't created or contributed to, and the player base is small, we don't need to support those "releases".
Oh and I still see no "examples of actual problems with the future of tasvideos if we still allow people to TAS VC images as they are, without extrapolating this to anything less known and common, like bundles where we know an existing emulator has been included" in your replies.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Nach wrote:
Why are we publishing nearly identical runs for the same game twice?
If they're nearly identical, we can prefer some version we agree about.
I'm not talking about nearly identical game versions, I'm talking nearly identical runs. I don't need to see HappyLee's SMB in under 5 minutes published on every Nintendo console, with a frame added here or there to account for minute timing differences.
feos wrote:
Nach wrote:
If you're just looking to exploit bugs in the emulator, then what are you even doing?
Even you admit that VC is not simply emulation. It's some kind of a virtualization+expansion layer on top of the original games, tweaked or not, developed specifically for those games, packaged as an integral game image for Wii, and officially distributed by the copyright holder.
I admit that it's not always simple emulation. But in most cases, it is just simple emulation. I have no problem where the VC is doing more than simple emulation and somehow enhancing the game beyond what you'd get if you tried it on the original console.
feos wrote:
Nach wrote:
Then why not exploit bugs in any emulator? It's how people remember the game because more people have an emulator than the original.
VC releases have huge player base, it's how they remember those games that they have legally purchased from the creator of Wii and the copyright holder of those games.
In China, Snes9x/Mednafen/VBA/whatever have a huge player base. It's how they remember those games that they have legally purchased in China from the creator of the Chinese ARM-based console, and are considered the copyright holder of that creation in China.
As an aside, I'm pretty sure some of the early NES games have outsold themselves on the NES compared to whatever sales the VC is currently doing for them.
feos wrote:
Oh and I still see no "examples of actual problems with the future of tasvideos if we still allow people to TAS VC images as they are, without extrapolating this to anything less known and common, like bundles where we know an existing emulator has been included" in your replies.
See what I said about HappyLee's SMB.
And despite not having offhand examples, I don't find it legitimate to exploit bugs in the emulator if there is such a thing.
If you want to allow using emulator bugs for the VC, then why shouldn't we extrapolate it to other things? And don't start calling other things less known just because some of us may be unfamiliar with what is going on in other countries with billions of people.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Again, you're missing the point. I don't know how many ways I can explain this. There is a subtle difference causing the obvious problem here. This subtle difference will exist in many games, even when it's not obvious.
How many times do I need to reply to this? If subtle differences don't cause problems in gameplay, audio, or graphics, then it's essentially the same superplay as on the original system, barring differences in randomness, which we've had zero problems with in our emulators. Yes, emulators also have subtle differences compared to actual consoles. Yes, it can affect randomness and other things that may not be obvious. And we only really ban bugs in emulators that aren't present on actual hardware if the emulator bug abuse is the only way to pull off some trick, fundamentally. If it can be easily resynced to work on console, it's not an emulator bug worth rejection, just slight inaccuracy. And if there are obvious problems, exactly as described in that thread, like games not working, not completing, or distracting audiovisual problems, we already have a rule against that:
http://tasvideos.org/MovieRules.html#PlayGamesThatAreEmulatedWell
So this is all in line with what we've been doing for years.
Nach wrote:
How do you define normal gameplay?
The way it works in the original mode.
Nach wrote:
Terrific. Therefore you cannot consider "verification" made with only the new system to necessarily replicate the other one. You won't know if there's a bug or not until you do proper verification.
With how I worded the rule suggestion, one doesn't have to verify things that aren't obvious glitches.
Nach wrote:
It'd be better if the file format would include some information copied from the game's header.
Is distributing parts of ROMs like that legal?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Nach wrote:
Again, you're missing the point. I don't know how many ways I can explain this. There is a subtle difference causing the obvious problem here. This subtle difference will exist in many games, even when it's not obvious.
How many times do I need to reply to this?
I keep seeing replies that appear to be missing the point I'm making.
feos wrote:
If subtle differences don't cause problems in gameplay, audio, or graphics, then it's essentially the same superplay as on the original system, barring differences in randomness, which we've had zero problems with in our emulators.
Just because you don't easily see the issue doesn't mean it's essentially the same. If enemy patterns change, then you're not playing exactly the same game.
I wouldn't say we've had zero problems in our emulators, from working on emulators I know we've had emulators where the enemy in the game acts differently than on an actual console.
feos wrote:
Yes, emulators also have subtle differences compared to actual consoles. Yes, it can affect randomness and other things that may not be obvious. And we only really ban bugs in emulators that aren't present on actual hardware if the emulator bug abuse is the only way to pull off some trick, fundamentally. If it can be easily resynced to work on console, it's not an emulator bug worth rejection, just slight inaccuracy.
We agree on this point.
feos wrote:
So this is all in line with what we've been doing for years.
Except it isn't, because suddenly I'm hearing the DMG is being redefined as the CGB or AGB, and that verification on those later consoles is considered true verification. You're not longer comparing emulator with a console, but comparing an emulator with some other console which does pseudo-emulation. From my perspective, you have all absolutely lost your minds.
feos wrote:
Nach wrote:
How do you define normal gameplay?
The way it works in the original mode.
And how do you know that if you're verifying it against a non-original mode?
feos wrote:
With how I worded the rule suggestion, one doesn't have to verify things that aren't obvious glitches.
So now I see a run, and I suspect something, and it would force one to have to console verify it?
feos wrote:
feos wrote:
It'd be better if the file format would include some information copied from the game's header.
Is distributing parts of ROMs like that legal?
If you're copying a single value describing something it should be legal.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I'm not talking about nearly identical game versions, I'm talking nearly identical runs. I don't need to see HappyLee's SMB in under 5 minutes published on every Nintendo console, with a frame added here or there to account for minute timing differences.
That's what I mean as well. Though logically, if you get nearly identical runs from different game versions, then you can consider the versions nearly identical. We already do this with game versions that result in nearly identical runs. Just in this case, they would complete across platforms.
Nach wrote:
In China, Snes9x/Mednafen/VBA/whatever have a huge player base. It's how they remember those games that they have legally purchased in China from the creator of the Chinese ARM-based console, and are considered the copyright holder of that creation in China.
As an aside, I'm pretty sure some of the early NES games have outsold themselves on the NES compared to whatever sales the VC is currently doing for them.
If other publishers release their IP bundled with emulators they haven't created or contributed to, we don't need to support those "releases".
Nach wrote:
And despite not having offhand examples, I don't find it legitimate to exploit bugs in the emulator if there is such a thing.
That means you consider VC illegitimate altogether.
It has an emulation layer of some sort, which is perfectly fine. That layer may enhance or otherwise tweak the games, also fine. If the game is separated from that layer, even if it loses those enhancements or tweaks, it's fine. If separation makes it unplayable, it's not fine to separate it. But guess what? If it can't be safely separated, one has to play the VC version, with all the emulator bugs, abusing them like a maniac.
If you ban abusing emulator bugs in VC only in some situations, then you're allowing them in others. In which case you're not being consistent. And from what I've been saying so far, arbitrarily so, because you decide for the company who owns the IP for all those games as well as the console, that it's not official enough for us to bother approving of whatever they release for it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Can I ask if playing a CGB game on the GBA game counts as "pseudo-emulation" and should that be disallowed for nearly all cases? For nearly all CGB enhanced games, there isn't any enhancements for the GBA, so by this logic nearly all CGB games should not be allowed to use GBA mode for the sake of console verification.
Also "pseudo-emulation" would really be closer to something like the Analogue Pocket, claiming the CGB has "pseudo-emulation" of the DMG is really like saying the SGB has "pseudo-emulation" of the DMG, or maybe saying the DS has "pseudo-emulation" of the GBA, or maybe even the Wii having "pseudo-emulation" of the Gamecube.
Just because you don't easily see the issue doesn't mean it's essentially the same. If enemy patterns change, then you're not playing exactly the same game.
I wouldn't say we've had zero problems in our emulators, from working on emulators I know we've had emulators where the enemy in the game acts differently than on an actual console.
Why exactly are you not arguing for absolute purism regarding emulator accuracy though? If an enemy behaves differently, then you're not verifying how it works on console, so it's not the same game anymore. Consistency please.
Nach wrote:
feos wrote:
So this is all in line with what we've been doing for years.
Except it isn't, because suddenly I'm hearing the DMG is being redefined as the CGB or AGB, and that verification on those later consoles is considered true verification. You're not longer comparing emulator with a console, but comparing an emulator with some other console which does pseudo-emulation.
What is being verified is how a game runs in GBC and then on console. If the differences between GB and GBC for a given game are subtle, then running it on actual GB would still fundamentally work after some resync. If the difference is significant, we prefer the original thing of course.
Nach wrote:
From my perspective, you have all absolutely lost your minds.
I won't tell you what people think about your posts from their perspective.
Nach wrote:
And how do you know that if you're verifying it against a non-original mode?
So now I see a run, and I suspect something, and it would force one to have to console verify it?
You ask the author to prove that whatever looks suspicious is also there in the original mode. If it's not there, and the difference is significant, reject.
Nach wrote:
If you're copying a single value describing something it should be legal.
Which value do we need here?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
That's what I mean as well. Though logically, if you get nearly identical runs from different game versions, then you can consider the versions nearly identical. We already do this with game versions that result in nearly identical runs. Just in this case, they would complete across platforms.
This is now taking my statement out of the original context. If you now deem the later emulated release as valid, you open it up to bugs and other kinds of new releases. The new releases we're talking about here isn't just the game, but all sorts of software added to the game. The point I was making is that we either have the exact same game (use the original), or it's not the same (is it then legitimate?).
When we came up with the concept of using the correct version, we were talking about remakes of NES games on the SNES or AGB, or arcade ports to consoles. Those were games natively copied to the other platform with some changes to better fit the other platform, and sometimes new additions in the later release.
With VC and other kind of emulation we're now talking about the original release - the same game, no changes or additions, just presented with a new potentially buggy shell. I'm not sure the same rules should apply.
feos wrote:
If other publishers release their IP bundled with emulators they haven't created or contributed to, we don't need to support those "releases".
Why not? If a company legally releases their IP bundled with an emulator, why shouldn't we support the release? What difference does it make their level of involvement?
feos wrote:
That means you consider VC illegitimate altogether.
Only if the game is (nearly) identical to the original or can otherwise be played fine on the original.
feos wrote:
It has an emulation layer of some sort, which is perfectly fine. That layer may enhance or otherwise tweak the games, also fine.
Agreed.
feos wrote:
If the game is separated from that layer, even if it loses those enhancements or tweaks, it's fine.
If you ban abusing emulator bugs in VC only in some situations, then you're allowing them in others. In which case you're not being consistent.
My criteria is simple:
Is it the original game (can easily be verified by comparison of the files) - play on original.
Is it close to the original game which also works on the original console (differences might be a harder gameplay mode or something, can check to see if it works on original) - play on original.
Game has enhanced features only present on VC - play on VC.
If it's the original game, but VC still somehow enhances it on the VC - play on either.
Close to original game, works on original console, and VC enhances it - play on VC.
feos wrote:
And from what I've been saying so far, arbitrarily so, because you decide for the company who owns the IP for all those games as well as the console, that it's not official enough for us to bother approving of whatever they release for it.
I don't think we need to consider every kind of release and combination legitimate or the correct version to play. You yourself agreed which should disregard potential use cases if it causes A/V bugs.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
CasualPokePlayer wrote:
Can I ask if playing a CGB game on the GBA game counts as "pseudo-emulation" and should that be disallowed for nearly all cases? For nearly all CGB enhanced games, there isn't any enhancements for the GBA, so by this logic nearly all CGB games should not be allowed to use GBA mode for the sake of console verification.
I'd agree with that. I believe the earlier thread I linked also talks about CGB issues on AGB as well.
CasualPokePlayer wrote:
Also "pseudo-emulation" would really be closer to something like the Analogue Pocket, claiming the CGB has "pseudo-emulation" of the DMG is really like saying the SGB has "pseudo-emulation" of the DMG, or maybe saying the DS has "pseudo-emulation" of the GBA, or maybe even the Wii having "pseudo-emulation" of the Gamecube.
I mentioned earlier that a colleague of mine considers later SNES consoles to be pseudo-emulation of earlier SNES consoles.
feos wrote:
Why exactly are you not arguing for absolute purism regarding emulator accuracy though? If an enemy behaves differently, then you're not verifying how it works on console, so it's not the same game anymore. Consistency please.
I have no problem where we say look we're using an emulator, it may have some differences from the original, but we try to avoid that.
I do have a problem where we say, nope it's perfect, because we compared it to something which is another emulator.
feos wrote:
What is being verified is how a game runs in GBC and then on console. If the differences between GB and GBC for a given game are subtle, then running it on actual GB would still fundamentally work after some resync. If the difference is significant, we prefer the original thing of course.
It may or may not work on the original. It's really hard to know how big the difference is until you check.
feos wrote:
Nach wrote:
From my perspective, you have all absolutely lost your minds.
I won't tell you what people think about your posts from their perspective.
You don't need to, I'm sure those of you living in reverse-world are thinking the same of me. That's how perspective work.
feos wrote:
You ask the author to prove that whatever looks suspicious is also there in the original mode. If it's not there, and the difference is significant, reject.
I agree with this. However, not all our judges are necessarily familiar with the game in the original mode to know if something even looks suspicious or not.
feos wrote:
Nach wrote:
If you're copying a single value describing something it should be legal.
Which value do we need here?
I have to double check my notes, I believe there's a value or set of values in DMG/SGB/CGB headers which describe the capabilities of the cartridge. I can look that up for you. That information should probably be copied to the movie file, along with information regarding which mode or capabilities were used to play it back. This way we can both identify the system and know how to run it.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
This is now taking my statement out of the original context. If you now deem the later emulated release as valid, you open it up to bugs and other kinds of new releases. The new releases we're talking about here isn't just the game, but all sorts of software added to the game. The point I was making is that we either have the exact same game (use the original), or it's not the same (is it then legitimate?).
I'm going to need your exhaustive definition of the word "legitimate", because it's becoming impossible to discuss anything without having the same questions asked over and over. You define it once and for all, and in the future I'll only refer to that definition when discussing anything "legitimate" with you.
Nach wrote:
feos wrote:
If other publishers release their IP bundled with emulators they haven't created or contributed to, we don't need to support those "releases".
Why not? If a company legally releases their IP bundled with an emulator, why shouldn't we support the release? What difference does it make their level of involvement?
VC is quite clearly unique compared to all those bundles. Limiting a unique rule to the unique situation means you don't need to extrapolate anymore (hooray).
Nach wrote:
feos wrote:
If the game is separated from that layer, even if it loses those enhancements or tweaks, it's fine.
I find this debatable.
You disagree with your own ruling?
Nach wrote:
My criteria is simple:
Is it the original game (can easily be verified by comparison of the files) - play on original.
Is it close to the original game which also works on the original console (differences might be a harder gameplay mode or something, can check to see if it works on original) - play on original.
Game has enhanced features only present on VC - play on VC.
If it's the original game, but VC still somehow enhances it on the VC - play on either.
Close to original game, works on original console, and VC enhances it - play on VC.
Except none of that helps with prejudice/inconsistency towards the platform itself.
Nach wrote:
I don't think we need to consider every kind of release and combination legitimate or the correct version to play. You yourself agreed which should disregard potential use cases if it causes A/V bugs.
VC games were explicitly re-released with this extra layer, I don't see any difference between them and non-VC games officially released for Wii. The point about AV bugs was about GB games that weren't explicitly re-released for newer modes, instead the console itself was tweaked to support them.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Ambassador, Moderator, Site Developer, Player
(120)
Joined: 3/17/2018
Posts: 348
Location: Holland, MI
Nach:
"I do have a problem where we say, nope it's perfect, because we compared it to something which is another emulator."
Ok so for VC and the like, this is a reasonable criticism assuming you allow no nuance with things like additional content exclusive to the VC release or VC exclusive bugs that are intentionally being TASed under the consideration of VC as the base platform. I think there's room for those nuances though.
When referring to the GB/GBC/GBA situation, this would be a bit strange since the systems all have a nearly identical SOC for playing GB games, each revision has its own bugs, and they're all official hardware from Nintendo with no software emulation involved. Some cases where GB games don't run on GBC are as much caused by bugs in the original GB hardware that the game accidentally relied on as they are caused by new bugs in the GBC. It's at the very least pedantic to consider the exact set of bugs present on the DMG to be the only legitimate TASing platform for games that were designed for it. It would be much more straightforward to only worry exactly which of these micro-revisions the game is being TASed on in the niche cases where it actually causes an incompatibility.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
I'm going to need your exhaustive definition of the word "legitimate", because it's becoming impossible to discuss anything without having the same questions asked over and over.
Everyone familiar with the situation finds it acceptable and valid way to play and consider it to be a reliable method for TASing purposes.
feos wrote:
VC is quite clearly unique compared to all those bundles. Limiting a unique rule to the unique situation means you don't need to extrapolate anymore (hooray).
As you know, we often clarify how to handle new situations on the basis of how we handled previous situations. So how would you define our allowance of VC in such a way that it doesn't open the door to anything that may come along later?
feos wrote:
Nach wrote:
feos wrote:
If the game is separated from that layer, even if it loses those enhancements or tweaks, it's fine.
I find this debatable.
You disagree with your own ruling?
I can argue either side and believe each has merits. We can have a long discussion about pros and cons.
Nach wrote:
Except none of that helps with prejudice/inconsistency towards the platform itself.
That's because the platform itself is inconsistent.
Nach wrote:
VC games were explicitly re-released with this extra layer, I don't see any difference between them and non-VC games officially released for Wii. The point about AV bugs was about GB games that weren't explicitly re-released for newer modes, instead the console itself was tweaked to support them.
Not all DMG games with issues got a black cartridge re-release for CGB. Also for some reason, some of these games only got a re-release in one region but not others, such as the game Alyosha referred to earlier.
It's not fully clear what criteria they used for the re-releases. Nearly every re-release is known to have its original version exhibiting some kind of problem, so that was certainly motivation for it, but not every problematic game or game/region got that treatment.
Later console changes didn't fix all the problematic games either.
You want to block DMG games on CGB when there's some noticeable issues, which I agree with. It's a combination Nintendo wants to support, but their success rate was not perfect. Same for VC, they want to support all these games they're bringing over, but their primary focus here is the $, not whether the game runs perfectly well or not. They're not extensively testing them like they would a brand new game. If there's AV issues in VC that aren't exhibited on the original platform, why should we support it?
TiKevin83 wrote:
Nach:
"I do have a problem where we say, nope it's perfect, because we compared it to something which is another emulator."
Ok so for VC and the like, this is a reasonable criticism assuming you allow no nuance with things like additional content exclusive to the VC release or VC exclusive bugs that are intentionally being TASed under the consideration of VC as the base platform. I think there's room for those nuances though.
I think there's room for nuance where VC adds on content.
However if it's really just the original game, I don't see why we should allow for this nuance anymore than we'd allow for making use of bugs in MAME.
TiKevin83 wrote:
When referring to the GB/GBC/GBA situation, this would be a bit strange since the systems all have a nearly identical SOC for playing GB games, each revision has its own bugs, and they're all official hardware from Nintendo with no software emulation involved.
Whether it's software or hardware really isn't relevant.
TiKevin83 wrote:
Some cases where GB games don't run on GBC are as much caused by bugs in the original GB hardware that the game accidentally relied on as they are caused by new bugs in the GBC.
That is indeed true. I spoke to a friend of mine over the weekend who is more familiar with some of these differences, and he told me the flickering in DMG Zelda on a CGB I mentioned earlier is due to the fact the game was made understanding the ghosting effects of the poor quality screen the DMG has. The CGB having a better screen without these ghosting effects has a flicker in several places. SGB or emulators with older televisions or computer screens had ghosting effects and also looked great, but playing them on a new higher quality screen has flickering issues unless you turn on some kind of frame blending or motion blur. The Zelda DX version fixed this by redoing some of the visual effects the game uses, and when necessary, draws these effects on more frames so it doesn't require the screen to exhibit ghosting issues to look right.
Although this differs to the situation when we talk about the randomness being different, and thus the enemies act differently, or somehow instantly kill you and become unbeatable. The game was made with a particular design in mind, and was tested that way.
TiKevin83 wrote:
It's at the very least pedantic to consider the exact set of bugs present on the DMG to be the only legitimate TASing platform for games that were designed for it. It would be much more straightforward to only worry exactly which of these micro-revisions the game is being TASed on in the niche cases where it actually causes an incompatibility.
Those DMG games that may have relied on some DMG bug did not envision that someday a new system would come out which was intended to be backwards compatible, but would fix the bug and thus break the game.
I find it more straight forward to just play each game on the platform it was designed for. If a game was designed for multiple platforms, then allow it on any of those. We then don't have to start worrying about whether something unusual is due to an incompatibility or not.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
Nach wrote:
Why are the rules being modified unilaterally? Judges are not supposed to modify the rules, only clarify them.
I was senior judge at the time, and senior judge had the final call on movie rules. This was well established at the time. Yes, other seniors and admins were usually involved in major rule change discussions, but never has it been required that every admin partake in the discussion, or each of them to sign off on it.
Nach wrote:
In the past 5 years, we've had many discussions between admins and judges regarding changes to the rules. We had various threads about them, discussion in the staff channel, some changes we announced publicly. We asked admins and judges if they like the new wording or not. I don't recall seeing any discussion about anything Mothrayas did here, at least not in the usual staff places. So I don't think anything about those rule changes are legitimate.
Each of these rule changes were discussed in the staff IRC channel at their respective dates. Especially the overall GB rule update (from 2018-01-01) had adelikat as an active contributor to the discussion (alongside other judging staff). You may not recall it as you in particular weren't (actively) involved in either, but that doesn't mean that no discussion happened between judges and admins in the proper channels, or that the rules were "being modified unilaterally" by "judges". The logs are right there. (For as good as IRC is at keeping them).
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Mothrayas wrote:
I was senior judge at the time, and senior judge had the final call on movie rules.
Senior judge has final call on interpreting the movie rules. Admin(s) are supposed to be involved when it comes to rule changes.
Mothrayas wrote:
Each of these rule changes were discussed in the staff IRC channel at their respective dates. Especially the overall GB rule update (from 2018-01-01) had adelikat as an active contributor to the discussion (alongside other judging staff).
According to my logs, I was not on IRC for the weekend prior to the New Year, so that explains why I wasn't there for what I assume was an important part of the conversation.
Now that I look there though I do some conversation around that time for which I was there about some SGB run in the queue (Rolan's Curse II), and whether we should accept, but nothing that I see regarding the larger discussion.
Mothrayas wrote:
You may not recall it as you in particular weren't (actively) involved in either, but that doesn't mean that no discussion happened between judges and admins in the proper channels, or that the rules were "being modified unilaterally" by "judges". The logs are right there. (For as good as IRC is at keeping them).
Okay you're right, just because I didn't see it and was not aware of it, doesn't mean it didn't happen.
In general though, important rule changes should try to involve as much of the senior staff as possible, and staff should try to be in the staff IRC channel as often as they can.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 10/12/2011
Posts: 6337
Location: The land down under.
Nach wrote:
Staff should try to be in the staff IRC channel as often as they can.
Despite the fact that the Discord version of Staff is more significant cause Discord logs the conversation for everyone.
Also this:
I'm not bringing anything to the table, but when there's a large significant agreeance with majority of Staff about this and one is making it difficult especially something that's been unofficially been in place for 2 years now you should get the realization why Staff won't ever agree with your stance Nach.
It's because Staff want to evolve whilst you don't.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Spikestuff wrote:
I'm not bringing anything to the table, but when there's a large significant agreeance with majority of Staff about this and one is making it difficult especially something that's been unofficially been in place for 2 years now you should get the realization why Staff won't ever agree with your stance Nach.
For me it hasn't been 2 years. Just 2 weeks.
Spikestuff wrote:
It's because Staff want to evolve whilst you don't.
Why are you assuming that?
I don't know what everyone knows and doesn't know on the topic. Most of the push back I've been getting on this thread appears to be about not understanding the situation. Why should I accept a differing viewpoint when I know the other viewpoint is missing information which I have?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
The CPU computation in a CGB is supposed to be the same as a DMG, the place where they differ is in the sound and video generation components. For a game that doesn't try to read that back, it should in theory play exactly the same, minus audio or visual differences. However if the game does read it back, or use it as part of timing, which in turn feeds into an RNG or for other computations, the game play is different. I've heard stories how bosses suddenly became much easier or harder. This is where the differences can be subtle.
We already allow any different revision of the same game, especially when one revision has specific bugs that allow to beat the game faster. We also already allow different hardware revisions, for example the different PSX BIOS versions, for which in some aspects may feature even deeper differences than GB vs GBC. You insist that GB games haven't been designed for the GBC platform, but that also applies for any other platform game that was developed before introducing hardware revisions. Is there any reason why we should treat the Game Boy differently?
feos wrote:
If glitches that are caused by newer mode can't be easily noticed and don't hinder gameplay, the newer mode is allowed for the sake of console verification.
It's not just for the sake of console verification. In my opinion, GB-in-GBC should be also considered as a stylistic choice for improving aesthetic of a movie, as well as be allowed to taking advantage of hardware differences that may allow for a more optimized movie (apart from the BIOS screen duration difference).
Everyone familiar with the situation finds it acceptable and valid way to play and consider it to be a reliable method for TASing purposes.
That definition has two fundamental problems:
Subjectivity. If I'm familiar with situations that are covered by our movie rules, and I stop considering some of them valid and acceptable, then the rule itself is not legitimate anymore?
Emergence. The more people you inform about the situation, the more variety of opinions you get. Those opinions may include notions that completely disprove your initial beliefs, leading to quality changes in the whole situation, which will then need to be reevaluated, and different questions will need to be asked. You may also opt to stick to just those few people that agree with you, but then that's called echo chamber.
Due to the above, I find this definition to be impossible: to use and rely on, and to even take seriously.
Nach wrote:
As you know, we often clarify how to handle new situations on the basis of how we handled previous situations. So how would you define our allowance of VC in such a way that it doesn't open the door to anything that may come along later?
You probably also know that over the years, the rules whose development I've been involved in, I've been trying to define in the most future-proof way we can pull off. And from having had tons of brainstorming sessions with staff members, I can say that 100% future-proof rules are impossible. We can't predict 100% of everything that happens in the future, and even if we could, accounting for it all would make the rules infinitely long, and coming up with perfect wording would also require infinite time. No one has resources for that at their disposal. So we limit this to what covers the most probable situations, however exotic they may be.
So as of right now, I don't think we need any extra rules that ban VC TASing in any form. All we might want to do is saying that if TASing the VC bundle results in similar gameplay as without it, we prefer without it, for the sake of originality. If TASing the VC bundle showcases gameplay as different from original as we require for Moons branches, be that features or glitches, we publish that separately. Some for differences that count as separate game modes (vaultable).
If some other company ever develops a comparable virtualization+enhancement layer from scratch, alloys it together with their previous game, and releases it as a uniform bundle for a certain console, similar to all other releases for that console, we can extrapolate this approach over and include that system in the VC rule.
Nach wrote:
That's because the platform itself is inconsistent.
Arbitrary purism may describe any platform as inconsistent.
Nach wrote:
You want to block DMG games on CGB when there's some noticeable issues, which I agree with. It's a combination Nintendo wants to support, but their success rate was not perfect. Same for VC, they want to support all these games they're bringing over, but their primary focus here is the $, not whether the game runs perfectly well or not. They're not extensively testing them like they would a brand new game. If there's AV issues in VC that aren't exhibited on the original platform, why should we support it?
Because I consider the VC layer a part of the game. The benefit being that we showcase two different things, and they have different superplay, not limiting creativity that can be applied to that newer platform, because that creativity would be unique: you can't replicate some of that stuff on just the original or extracted game. The original movie isn't hurt, and the movie on the extracted game isn't hurt.
With GBx, the new mode is not a part of the game that you buy from the publisher, and the enhancements aren't either, so the incompatibility bugs aren't inherent to the game image.
Nach wrote:
I spoke to a friend of mine over the weekend who is more familiar with some of these differences, and he told me the flickering in DMG Zelda on a CGB I mentioned earlier is due to the fact the game was made understanding the ghosting effects of the poor quality screen the DMG has. The CGB having a better screen without these ghosting effects has a flicker in several places. SGB or emulators with older televisions or computer screens had ghosting effects and also looked great, but playing them on a new higher quality screen has flickering issues unless you turn on some kind of frame blending or motion blur. The Zelda DX version fixed this by redoing some of the visual effects the game uses, and when necessary, draws these effects on more frames so it doesn't require the screen to exhibit ghosting issues to look right.
Although this differs to the situation when we talk about the randomness being different, and thus the enemies act differently, or somehow instantly kill you and become unbeatable. The game was made with a particular design in mind, and was tested that way.
We don't account for those "nuances" in how the games used to look when played on console. We don't apply NTSC artifacts to your video, we don't simulate luminophore glow, we don't put scanlines in our encodes. So in any encode of GB Zelda, you will see the same flickering when watching on your computer, regardless of the mode.
Nach wrote:
Most of the push back I've been getting on this thread appears to be about not understanding the situation. Why should I accept a differing viewpoint when I know the other viewpoint is missing information which I have?
How many people you want to come in and say "I'm fine with all those subtle differences" to finally understand that information you bring up is not being missed?
Nach wrote:
I have no problem where we say look we're using an emulator, it may have some differences from the original, but we try to avoid that.
I do have a problem where we say, nope it's perfect, because we compared it to something which is another emulator.
No one is saying GBx modes are perfect though. We're saying they're good enough, for the most part.
Nach wrote:
I agree with this. However, not all our judges are necessarily familiar with the game in the original mode to know if something even looks suspicious or not.
If it doesn't look suspicious for the judge who is looking closely, and for the audience who often knows the game, then it's not a significant difference.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
We also already allow different hardware revisions, for example the different PSX BIOS versions, for which in some aspects may feature even deeper differences than GB vs GBC. You insist that GB games haven't been designed for the GBC platform, but that also applies for any other platform game that was developed before introducing hardware revisions. Is there any reason why we should treat the Game Boy differently?
I generally feel the same, I don't see the fundamental difference between newer game modes and hardware revisions. Whatever we decide should benefit the TASers and the community, and the community have agreed with my suggestions. Our job is boiling down the logistical part of the rules to something we could use in the future, without contradicting existing rules. And I'm not seeing fundamental contradictions with the current rules either.
ThunderAxe31 wrote:
It's not just for the sake of console verification. In my opinion, GB-in-GBC should be also considered as a stylistic choice for improving aesthetic of a movie, as well as be allowed to taking advantage of hardware differences that may allow for a more optimized movie (apart from the BIOS screen duration difference).
If there are no glitches at all caused by the newer mode, then it's an artistic choice. If there are slight but noticeable glitches, we want them to be justified.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I'm not bringing anything to the table, but when there's a large significant agreeance with majority of Staff about this and one is making it difficult especially something that's been unofficially been in place for 2 years now you should get the realization why Staff won't ever agree with your stance Nach.
It's because Staff want to evolve whilst you don't.
