Submission Text Full Submission Page

1st Nesvideos Dream Team Contest Competition "Gaiden"

from 2006-01-06 to 2006-01-20 (2 weeks)
Contest organized by Brushy

Contest rules:

  • The game to TAS is Super Mario Land 2 (GB) (rom Super Mario Land 2 - 6 golden coins (V1.0) (UE) [!].gb) (information revealed only on contest start day 2006-01-06)
  • Normal difficulty
  • Movie must obey the rules of this site. No cheats and debugging and so on.
  • Everybody in the team must participate in movie making by recording something.
  • No outside help is allowed (but common knowledge is usable).
  • Movie must be submitted to the contest on 2006-01-20 (2 weeks after the start).

Game Boy - Super Mario Land 2 TAS by RED TEAM RULES

RED TEAM RULES IS:
  • BagOfMagicFood
  • FODA
  • Randil
  • Shinryuu

The movie

  • Abuses programming errors
  • No deaths
  • Manipulates luck
  • Aims for fastest completion
  • Takes damage to save time
emulator used: VBA-rerecording-17.1
NOTE: this is the very same video we submitted to the contest, not the planned improved version (which was never made).
This is the winning movie for the competition out of a total of 1 submitted movies (all teams). It's actually very precise and we think that it can't be improved by much, despite the apparently crazy routes.
Our team managed to work together very well, with FODA testing some routes and glitches, BagOfMagicFood doing research on tricks and optimizing the run, while Randil and Shinryuu experimented with the game's physics and did good optimization too. This was throughly a good experience although it was very time taking since we only had 2 weeks to do it!

The pipe glitch:

  • Found at David Wonn's site, this glitch enabled us to cut several minutes of our first route test run (32 minutes long) when used correctly. We've found a lot of bricks with unusual behavior, some would lead to secret exits, some would do damage, some would give several coins per second while some would reset the game and some would even give illegal opcodes which automatically closes the rom! This was very tricky and we started the final version only a couple of days from the end of the contest because of all the experimenting with this glitch and finding better ways to use it. The glitch consists of getting in a pipe and exiting the level so that mario is still going down when he leaves. This way, when you enter another level, mario will still be going down for 1 frame, enough to push him inside the floor. For some reason, there are blocks below on most levels and they even work for boss levels.

The 100 enemies starman:

  • This run kills 99 enemies before entering wario's castle to save a few frames on those ball bosses. We found that feature to be pretty neat :)

The "hit on a passing block rule":

  • If mario jumps just past a block above his head, he is pushed forward 1 extra pixel.

The movement rule:

  • Mario moves 1 pixel then 2 then 1 then 2 and so on while running.

The jump height rule:

  • Mario's jump can be higher if the "A" button isn't held past a certain point (26 frames). If the "A" button is kept on hold for 1 extra frame, the jump height is shortened considerably.

The fall off a ledge rule:

  • If mario is too fast, when he falls off a ledge he will do a little hop up and then start falling slowly. To avoid this, release "B" before the ledge to get low speed enough, so he falls at a considerably higher speed.

The horizontal speed while in the air rule:

  • When in the air, if mario goes below a certain speed, he can't achieve max speed again unless he reaches ground to get running speed.

Bisqwit: Removing Shinryuu from the author list (his own request).

adelikat: Turns out that the pipe glitch can be used to this extend only by using exploiting a bug in emulation rather than a bug in the game itself. This is in violation of the guidelines that state that the games must look like they were done on authentic hardware. As a result this submission must be rejected.
This may turn out to be a good thing since a correctly emulated version will use the glitch to a lesser extend which will probably make it more entertaining to the general audience.


adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Kyrsimys wrote:
The point is that the game must be unaltered. Who would for example enjoy a TAS of SMB3 if there was an emulator glitch that allowed the player to run just run through any wall? It wouldn't be the same game anymore.
Exactly. Also, if such things were allowsed to be published, why not patch emulators to perform other emulation bugs? Perhaps even ones that would be entertaining to watch? It sucks that vaulable work will be made invalid due to such a bug, but this can't be published. Kudos to dwedit for figuring this out. Sorry to FODA & team for having their time wasted :(
It's hard to look this good. My TAS projects
Joined: 4/29/2005
Posts: 1212
I don't say it's a shame. That bug makes the whole TAS a complete bore to watch. I voted no.
Dwedit
He/Him
Joined: 3/24/2006
Posts: 692
Location: Chicago
I haven't counted the number of levels which can be solved with the pipe bug in a correctly behaving emulator, but I'd estimate that still at least 33% of the levels that can be finished that way.
Joined: 5/17/2007
Posts: 393
Location: Sweden
Actually if it wasn't for this game it might have taken another year for the bug to get fixed
"No love for the game gear"
Player (206)
Joined: 5/29/2004
Posts: 5712
Well then uh, never mind what I said! Thanks for submitting this, Foda!
put yourself in my rocketpack if that poochie is one outrageous dude
Former player
Joined: 10/1/2006
Posts: 1102
Location: boot_camp
Wockes wrote:
Actually if it wasn't for Dwedit it might have taken another year for the bug to get fixed
'fixed I'm sure a few previous tases have inadvertently used this bug as well.
Borg Collective wrote:
Negotiation is irrelevant. Self-determination is irrelevant. You will be assimilated.
S@G
Joined: 9/7/2006
Posts: 81
Location: Luxemburg
The Pipe Glitch is a little bit annoying to watch, but thats not a reason to not vote yes. So I vote [yes]
I don't need a Signature
Joined: 5/2/2006
Posts: 1020
Location: Boulder, CO
S@G wrote:
The Pipe Glitch is a little bit annoying to watch, but thats not a reason to not vote yes. So I vote [yes]
It amazes me that people will vote yes after the last 2 pages of discussion. Do people not even read the thread before posting....?
Has never colored a dinosaur.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
FODA wrote:
Well, then all TAS must be redone from scratch using more perfect emulators? I'm sure none of them behave like the real games. The TAS is what it is. It uses the emulator version it was made on. It is NOT up to us to check if every stance of every movement and trick work on the real cartridge. I won't remake the TAS, it's final. If you want, do it yourself. But your new emulator isn't perfect either.
I honestly don't understand how you can compare a minor emulation imperfection (such as for example the emulator not producing all the lag frames as the original console) which do not really affect the game itself (even though some lag frames are not "emulated" correctly, the game may still work exactly as the original one, give or take a few frames of difference in speed) to a major emulator bug which affects the *contents* of the game, introducing graphical and even functional elements (such as additional level exits) which are inexistent when the game is played in the original console. What you are basically saying is: "Since some TASes are made with emulators which do not emulate the original console with 100% accuracy, then *any* emulation bug should be ok, no matter how much it affects the game from what it originally was in the original console." IMO if an emulator bug allows a major route change which is completely impossible to achieve in the original console, then it's not acceptable to exploit that bug. That's against both the letter and the spirit of the rules of TASing. It's basically equivalent to using gamegenie codes to cheat.
Joined: 1/21/2006
Posts: 117
It's actually probably in the best interests of the site to enforce the usage of accuracy-focused emulators, where possible. It's really kind of unexcusable for older systems where average PCs of today can emulate them to the cycle-exact accuracy even at faster speeds than real hardware. Most of us aren't using 100MHz machines anymore, so we don't really need a hacky Game Boy (or NES, or others) emulator just to run games at full speed on those slow machines. How far this logic would be applied is a bit questionable. Cycle-exact SNES: Maybe; my machine can run Super Mario World in bsnes at about 80% real speed, not too bad I say. If we're going to reach into the realm of Nintendo 64, I don't even know if anyone's tried attempting an accurate emulator (how painfully slow it would be, but it wouldn't really be aimed at causal gaming). Speaking of which, I seriously doubt HLEs like Mupen 64 are anywhere near accurate; they're designed for casual gamers to run their Mario 64 and Zelda 64 on machines at full speed with seemingly little difference to a real console, they're not designed for people studying how the console works and certainly not for people performing TASes to see what the game actually can do. I know it might sound over-played, but this submission is proof of why we should try to aim for accurate emulators while performing TASes. Using emulators that were designed to run games full speed on machines where true emulation would be completely impractical for casual use, is pretty stupid. They might serve as an intermediate step, but we shouldn't settle. I'm not saying that switching to a new, cycle-exact emulator necessarily obsoletes old runs, much in the same sense old Famtasia runs still exist on this site. When you think about it, it makes sense -- if the goal of TASes is to show what is possible on real hardware, we should use emulators that try to behave like real hardware as best as possible. All that said, does anyone know of a cycle-exact Game Boy (Color) emulator with source code (and the right to modify it...)? I haven't really looked around, but it probably would have similar system requirements to a cycle-exact NES emulator (eg, Nestopia).
nesrocks
He/Him
Player (246)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
I'm saying that there's no way to draw a line. - What if the character doesn't move 1 2 1 2 1 2 pixels, but 1 1 2 2 1 1 2 2 when walking? Is that forgivable? - What if the screen fades 2x faster on the emulator between each level? - What if the character jumps 1 pixel higher on the emulator?
Joined: 1/21/2006
Posts: 117
All of those scenarios describe situations that will affect gameplay, which is simply unacceptable. How are you going to tell someone about TASes aiming to show what's possible on a real console, and then go "oh by the way, we exploit emulator bugs X, Y, and Z in order to be faster than a real console"?
nesrocks
He/Him
Player (246)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Do you really think none of these happen on a great proportion of the published videos on this site?
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
The only ones I am familiar with are SNES1.43 movies might have less lag than they should. What movies do you speak of FODA?
It's hard to look this good. My TAS projects
Former player
Joined: 12/22/2006
Posts: 193
Location: Flowood, MS
I'm saying that there's no way to draw a line.
And that is why there are judges.
<adelikat> tony hawk is porn for me <Comicalflop>my mom is hot
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
FODA wrote:
- What if the character doesn't move 1 2 1 2 1 2 pixels, but 1 1 2 2 1 1 2 2 when walking? Is that forgivable? - What if the screen fades 2x faster on the emulator between each level? - What if the character jumps 1 pixel higher on the emulator?
Those sound like minor changes to the gameplay, but the mechanisms controlling those things are in such widespread use that an emulator can't selectively affect gameplay like that without breaking the majority of games in obvious ways. There might be ambiguity over where to draw the line, but those three examples don't illustrate it very well. ((However, there is opportunity for those sorts of things in less mature emulators for complicated systems (N64)... there, it's still unusal, but it does happen in a few games before the compatibility reaches a high enough level. We take what we can get, I guess.)) More realistic examples (that all happen in Snes9x 1.43) would be:
  • Games lag less than they should. This could change the gameplay in a probably-small way if it changes the randomization, or in a big way if events are synchronized to music running on a different processor.
  • Games load much faster and pause less between screens than they should. This sounds like your 2x speed screen fade example, but it's really a special case of having less lag, not a different number of non-lag frames.
  • Games exhibit graphical glitches such as missing transparency effects or discolorations. Although it doesn't change the gameplay at all, you could say it doesn't look like the real thing anymore.
  • This one falls solidly into the unacceptable-to-exploit category, but when a game is "tricked" into making illegal memory writes, instead of crashing the game it corrupts the emulator's own memory and causes strange undefined behavior. This explains the turn-into-golden-Rambi glitch in DKC2. (EDIT: more accurately, it happens during that glitch and might explain it or somewhat alter what it should do.)
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
FODA wrote:
I'm saying that there's no way to draw a line.
Difficulty in imposing strict rules doesn't mean that completely clear cases as this one should not be rejected. There's a difference between unclear and clear cases, and this is certainly of the latter type.
Joined: 5/2/2006
Posts: 1020
Location: Boulder, CO
FODA-- You keep posting like you know of some run(s) where emulation glitches have a profound affect on gameplay. If you do, you really should bring them up.
Has never colored a dinosaur.
nesrocks
He/Him
Player (246)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
My point is I don't know. If I could've known I wouldn't have started to make this one in the first place. My point is we can't know.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
If someone submitted a run of some game, but he uses eg. gamegenie codes to achieve things not normally possible in the game, and when his submission is rejected he simply states that he didn't know about such rule, should the submission be accepted because of that? Of course not. "I didn't know" is not a valid excuse to bend the rules.
nesrocks
He/Him
Player (246)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Damnit, I'm not saying I didn't know about the rule, I'm saying I didn't know it was an emulator bug. geez
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
I think you didn't understand my analogy.
S@G
Joined: 9/7/2006
Posts: 81
Location: Luxemburg
Twelvepack wrote:
It amazes me that people will vote yes after the last 2 pages of discussion. Do people not even read the thread before posting....?
I have read the last Pages, and its a Bug, an Emulator Bug, but its still a Bug, so, why not using it. For me it's ok to using them.
I don't need a Signature
Editor, Expert player (2073)
Joined: 6/15/2005
Posts: 3282
S@G wrote:
I have read the last Pages, and its a Bug, an Emulator Bug, but its still a Bug, so, why not using it. For me it's ok to using them.
The issue (according to some of us) is that the emulator bug compromises the game (how closely it emulates what it should be like when played on a real GB). However, you are not required to consider or even read any posts before voting, so don't let anyone bother you about that. It's also your opinion.
Poll wrote:
Vote: Did you like watching this movie? (Vote after watching!)
It only says to vote after watching. Nowhere does it say you must read anything first, even the submission text (although it is probably your benefit to do so).
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
S@G wrote:
I have read the last Pages, and its a Bug, an Emulator Bug, but its still a Bug, so, why not using it. For me it's ok to using them.
Sure. In the next version of the emulator let's introduce a "bug" which grants you complete immunity and removes collision checks. What the heck, let's introduce a "bug" which makes you jump right to the last boss. While we are at it, why not allow gamegenie codes as well? That would be way easier and less work than having to introduce "bugs" into the emulators.