Submission Text Full Submission Page
  • FCEU emulation
  • Level Select 20, Speed Hi
  • No glitches
  • Time-attack
-I played this game a lot in high school and I wasn't this good.
-It's difficult to make a puzzle game interesting. I pondered a few because of the rarity of the runs, and this one won over Tetris. I tried as often as possible to make the viewer wonder why I put a piece where I did only to find out later that it cleared out viruses 2 rows underneath while still maintaining a solid speed. Unfortunately, the game has a solid memory of what pieces are coming next, and once I got an opening to win, it would have taken an extra 2 minutes-ish to clear the board, and even then, the virus died before the extra pill pieces were cleared so they were there anyway, but I left it so it appeared that the remaining pieces were at least the same color. Unlike other puzzle games of this genre, the pieces given don't alter based on the remaining obstacles - in other words, just because you don't have any red viruses remaining doesn't mean you won't get any more red pieces. I aimed primarily for the fastest time and secondarily for an entertaining video. It will probably be still be more boring than the least exciting action game, but at least it's short.

Bisqwit: This movie was surprisingly good, but it disappointed me near the end. For a long time, all the pieces were used purposefully, but near the end you ended up fighting against yourself a few times.
I'm rejecting this submission in favor of Baxter's submission.


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15575
Location: 127.0.0.1
This topic is for the purpose of discussing #417: -ziplock-'s NES Dr. Mario in 03:26.00
Former player
Joined: 8/12/2004
Posts: 651
Location: Alberta, Canada
Well it wasn't THAT boring, I have watched runs which were less entertaining than this. Although my main problem with this is, I have no idea if it's fast or not. The fact that peices which have to settle after a some pills are cleared do so slowly, kinda draws away from the speed of the game. Also the amount of time spent getting the last virus seems a little bit long, although again, I have no idea.
Former player
Joined: 3/13/2004
Posts: 1118
Location: Kansai, JAPAN
I can't find the right ROM for this game. Every one I can find has a suffix in the name...JU, E, VS, etc. Can you give me more information, like the full name, or the file size (zipped/unzipped)?
Do Not Talk About Feitclub http://www.feitclub.com
Former player
Joined: 3/9/2004
Posts: 484
Location: ­­
The (JU) version worked for me, despite the incorrect checksum.
Skilled player (1410)
Joined: 5/31/2004
Posts: 1821
No offence... but I can play like this on a real nes. I started making a movie of this game once... and it can be done a lot faster. The only thing I don't get is why you didn't have to scroll to level 20 at the beginning of the movie.
Emulator Coder
Joined: 10/9/2004
Posts: 453
Location: Norway
I have to vote no here. Not enough planning and no luck abuse at all.
Skilled player (1410)
Joined: 5/31/2004
Posts: 1821
Luck abuse? That's the only real + on the movie... The only thing that can be called luck in the game is the way the viruses are placed in the beginning... All the capsules that fall are determened after the level is started... so the only way to abuse this is by starting the level a few frames later... You'd have to find a good level with suiting capsuls... but it never completely fits... I think the level chosen is pretty good...
Former player
Joined: 9/26/2004
Posts: 217
Pretty much hit the bee between the buttcheeks there. I did my best to turn the disadvantage that the next piece isn't random into an advantage by planning ahead, but the level chosen is the only real luck abuse. I mostly tried for "Why'd he put that there?" as often as possible because I thought that would make it more interesting, without sacrificing any speed. I suppose it wasn't that good of an idea, but I didn't have much to go by except for the already published video. (This is, I think, 2 minutes faster.)
Skilled player (1410)
Joined: 5/31/2004
Posts: 1821
But how did you enter the level 20 with speed high so fast??? I had to scroll from level 0 to level 20, then go down and put speed on high when I tried this...
Former player
Joined: 9/26/2004
Posts: 217
Well, I'm not a coder so I can't tell you how it works, but I can tell you how I did it. I started recording from reset and put in my settings. I didn't like the way it was turning out, so I stopped the movie and started recording a new one (again, from reset). I hit start and the settings were already in there. I liked the new run I was making, but I thought this might be a problem, so I stopped it and reloaded it to see what would happen and, don't ask me how, the fcm remembered the settings. Maybe someone else knows why.
Former player
Joined: 8/12/2004
Posts: 651
Location: Alberta, Canada
Well, the game might be made to save your settings so you don't need to change them each time you play the game, but this brings up an interesting point. Technically this might count as playing from a saved game. While it does seem realitively minor, one could compare it to starting a game and have it skip the 3 minute intro sequence because it remembers already showing it to you. I'm not sure though, guess we might need some official word?
Editor, Reviewer, Experienced player (979)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
What puzzles me is how this somehow was saved in the moviefile, which is only keypresses. Was this movie from savestate and not from reset?
Former player
Joined: 8/12/2004
Posts: 651
Location: Alberta, Canada
Oh boy, I never thought of that, it says it's from Reset. That makes things even stranger. Edit: Ok I just did some tests. The game remembers when you reset it, but not reload the rom. When you record from reset, it remembers your settings, and strangely even remembers them on playback. Even after a fresh load of the rom. Edit2: Well I remember reading this from the fcm section of the FAQ: The savestate offset is <header_size + length_of_metadata_in_bytes + padding>. The savestate offset should be 4-byte aligned. At the savestate offset there is a savestate file. The savestate exists even if the movie is reset-based. This could be why. Infact, now that I think about it, in Ninja Gaiden I make sure I start recording from a blank screen, or else I end up with garbage for a few frames before the intro screen loads. It's possible more data is being saved than we want. I'm assuming this doesn't happen in famtasia?
Joined: 8/31/2004
Posts: 298
Location: Falun, Sweden
I've seen this too sometimes and I think it has to do with the RAM-file that the emu creates. I the RAM-file is removed the game will start from scratch. But if the RAM-file still is present the game will continue like you've just puched the reset button. (This situation occured on SMW quite some times when I did the intro)
Bein' away for like five years, and not a single new post in the ZSNES forum... :'-(
Editor, Reviewer, Experienced player (979)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
Yeah, but ziplock's submission shouldn't include the RAM-file, should it?
Joined: 8/31/2004
Posts: 298
Location: Falun, Sweden
True, but a movie that has "record from here" chosen does not need a RAM file to continue from the chosen lokation, right? But there is a chance I'm wrong ofcourse. b's exploanation is probably better.
Bein' away for like five years, and not a single new post in the ZSNES forum... :'-(
Editor, Reviewer, Experienced player (979)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
Found it.
Even if the header says "movie begins from reset", the file still contains a quicksave, and the quicksave is actually loaded. This flag can't therefore be trusted. To check if the movie actually begins from reset, you'll have to analyze the events and see if the first non-idle command in the file is a Reset type control command.
Guess it's time for some programming, either a check when you submit the movie, or (preferably) a patch to FCEU to not load the savestate. Otherwise you might end up losing a lot of work when you find out your movie didn't actually begin from scratch. In this case, probably the quicksave contains the level settings, and these are not changed with the reset command.
Former player
Joined: 8/12/2004
Posts: 651
Location: Alberta, Canada
Well, without looking at the code, i'm guessing that when the emulator resets the game to begin recording, it instantly takes a savestate to give the movie somewhere to start from. This works fine for the most part, but with a reset RAM is not cleared. So when the savestate is taken some data is saved, resulting in a problem similar to the one in this video. The easiest solution would just be instead of reseting the game, simply reload the rom.
Former player
Joined: 9/26/2004
Posts: 217
Well, of course, it was unintentional, but there are some interesting points here. For example, if a password was entered, then the movie recording started that saved the password at reset (Punch Out!!), you wouldn't need to enter that password again. Or worse, and I'm not sure, but if a game could be reset and you could continue to, say, the final boss by hitting reset and continuing, this method could be used. If memory serves (although it usually doesn't) Strider remembers the password at reset, and thus remembers the continue. Reasonable man says you could tell immediately whether this was being used within seconds of the movie starting, but if not for a popular game that most people hadn't seen... In any case, I should withdraw this submission? (Doesn't look like it's a "go" anyway)
Joined: 8/31/2004
Posts: 298
Location: Falun, Sweden
Sorry to say this -ziplock- but I whould say: Yes. There is nothing wrong about your movie but since it breaks one of the main Guidelines, though it wasn't intentional, I don't think this should be accepted.
Bein' away for like five years, and not a single new post in the ZSNES forum... :'-(
Active player (411)
Joined: 3/16/2004
Posts: 2623
Location: America, Québec
The problem here is not that savestate thing but the fact that FCEU doesn't have an hard reset feature. It only has a soft reset. So movie file use that reset which is wrong evidently. Blip surely know that and decided to use savestate instead of implementing an hard reset for some reasons I ignore, but it's not his fault but official developer's one. Well blip could surely implement it since I have reported this bug a couple time ago http://tasvideos.org/forum/viewtopic.php?t=1020. The only solution to couter this is, open a rom then pause the menu, close the rom and reopen it, it must stay paused evidently. Now you can start to record from reset without having this problem.
Editor, Reviewer, Experienced player (979)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
>The only solution to couter this is, open a rom then pause the menu, close the rom and reopen it, it must stay paused evidently. Now you can start to record from reset without having this problem. To me it's pretty obvious that most people will miss this, forget, or not care. It almost has to be hardcoded.
Player (71)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
Well.. I woulden't feel any wiser if I had to see the counter go up to level 20 and speed set to HI anyways. So I think these kinds of things would be accepted as long as they show a sign of it in-game. In DR. Mario it says what level you are playing on and what rate.
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Don't cancel the movie yet (for the reset-question reason). I'll verify it. The site should automatically refuse FCEU movies that don't include a reset event (yes, it's an event, not a flag), but there might be a difference between power-down and reset.