Don't emulators simply create the NES thingy from the start, as if they'd just come from the factory each and every time? Besides, if you have 2 NESes with different timing thingies, and they are in different states when the game is loaded, you essentially have 2 different consoles. You might as well compare the NES to the SNES, and try to make the game and TAS work on both of them, and then wonder why you can't do it.
I'm sure, with some time and more testing, memory hacking, etc., you will find the common variable/way to set it to a certain, universal start. With that, the game will then be TASable (along with others that suffer this effect). If TASes manage to work as they already do for most games, then it is proof that it does work. Has anyone even checked on how each emulator handles the DMC thingy?
Life is like a box of chocolates-when you want peanut butter, all you get is coconut.
I didn't realize this myself, but now everything it is clear to me. We have been cheating ourselves through all these years. Things will never be the same again, but this was just inevitable. ;)
Joined: 5/17/2004
Posts: 106
Location: Göteborg, Sweden
Since its conception as nesvideos this place has always been about stretching the limits of a video game within the rules set by that game. If the emulation used isn't accurate then you're essentially posting videos of someone playing a different game, with different rules. Imagine if, say, the Super Mario Bros speedwalks were linked to videos of someone trotting through Great Giana Sisters? Tactics like that are deceit, plain and simple; it's now clear that such deceit is at the very core of the technology used thus far to make TAS:ing possible.
In light of this discovery, what choice is there? I commend Adelikat and Nach on having the moral fortitude required to make the right call, sad though it may be to make.
I only hope that the site can be reopened in the future, when the TASvideos hardware team has finished designing and synthesizing proper, console-compatible hardware with complete RAM and register save states kept for each clock cycle. The bandwidth and space requirements should be no more than 3.5 GB/second or <20 TB/movie for the NES, which should be quite realizable within a few decades.
Honestly, I've always considered TASes and regular speedruns to be two separate things in general. So what if they can't be done on a real NES? Some of the ROM hack TASes can't even be played on a real NES by most of the populace, but yet we still have videos of them. The more important thing is the enjoyment we get out of watching them.
I also thought we weren't competing against real speedrunners or trying to compete with them in any way.
And since it's so close to April Fool's, I'm gonna give this a couple days to blow over. Then if we're still in a panic about it once April 2 or 3 rolls around, then I'll give more of my two cents. Color me skeptical, but I'd rather just hold off and give more of my opinion when I know I'm not being suckered into an elaborate joke or not.
Joined: 3/31/2010
Posts: 84
Location: Middle of Nowhere
Yeah it seems like either A) it's a big hoax and maybe it's trying to elicit some lukers to come out and play (kinda like a publicity stunt) or B) the site is really going down and everybody who made a TAS apparently wasted their lives making it.
See my post in the announcement thread if you wanna see my rant on it. In a way, I agree with Rick. I kinda wanna wait a bit and see if this blows over. I really hope it does, as this was a great site, and although I might not have been very active on it, I still spent a good many days here.
Joined: 6/28/2004
Posts: 219
Location: Raccoon City
This is a joke, right? We make amazing works of art that continuously challenge people to "play outside the box" for seven years, while entertaining thousands, and now it all goes away because one guy is hung up on some conceptual TAS nonsense?
Ive been on the site since 2004, and never have I read anything about how the entire framework of TAS "idealogy" hinges on whether its possible to recreate it on actual hardware in a speedrun fashion. From the beginning, there has been a stark differentiation between speedruns and TAS's. Its like comparing apples to oranges. They are different.
As someone said before: their understood purpose is to entertain. I believe there was even a quote to this effect on the front page for a long time to steer away the people who accused the videos of being fake or fraudulent.
Simply put: I am entertained. Everyone is entertained. I don't care about clock cycles, RNGs, acronyms I don't understand, or idealogy. I am entertained.
Admins' jokes aside, I'd like to latecomment.
zaphod77 wrote:
The theory of a TAS is that it should be possible to play back on real hardware.
...only if this hardware is capable of actually "playing back" (as in: being deterministic). This is closer to the real definition. But it sounds too long so it's gonna abridged anyway.
The flaw of current TASing lies in our method of storing session information in a keypresses file. If only every game had ingame replay mechanism, we wouldn't need all these imperfect emulators. Well, dreams.
Input file is only quick-and-dirty solution that was used in 2003, but didn't evolve too much. Does it have to evolve? It seems Tasvideos is fine with it. Although, honestly, from higher perspective, our "art" is similar to composing music with those "automated mario" levels. It's still great, but there will always be people who want it to be "more realistic"/less artificial. So I really hope there will be a day when consoles will have built-in recording mechanism, and then maybe some tools like hardware-powered quicksaves.
TASing as it is now - is still kinda proof of concept. It already highlighted some undexplored sides of human psychology (e.g. it appears that human mind is almost 100% capable of percepting time as full-fledged dimension, while still creating art from anything), but I beleive it can be much more.
zaphod77 wrote:
The fact that the DMCs registers are effectively random to start off with means the cpu stolen when it is first activated is unpredictable.
This makes it a source of entropy NOT CONTROLLED BY THE PLAYER.
Since the game has a source of entropy not depend on input from the player in any way, this INVALIDATES ANY TAS of said game.
This indeed undermines the concept of "keypresses files". At least this makes "frame-whoring" laughable. But this doesn't invalidate the concept of tool-assistance. And superplay.
zaphod77 wrote:
Any NES emulator that was truly accurate would emulate this behavior after all, and thus any attempted TAS of a game that does this would desynch. The fact that it doesn't means that the emulator is not accurate
What are you talking about? "truly accurate"? There cannot be truly accurate NES emulator. It's not even discussed among emudevs. For example, how can you emulate or simulate bus conflicts? These are common on old hardware, although emulators ignore those possibilities.
zaphod77 wrote:
The state of memory after power loss is RANDOM.
And this is the least problem. Even on NES majority of games DO clear RAM after power up. As for older consoles, it's common practice.
zaphod77 wrote:
Also a game could conceivably uses uninitialized RAM to get the first seed. This would cause the same problem again. In fact, games for certain other 8 bit systems count of the fact that the state of RAM is random when the system is powered on, and will not work al all if it's not!
Uh, can you provide real names of these games? I'm really interested. Because every RNG in NES games I checked didn't use random state of RAM, instead it initialized random seed by fixed value (even though this seed was previously zeroed by another subroutine at the powerup).
The theory of a TAS is that it should be possible to play back on real hardware.
That's incorrect. The theory of a TAS is that a perfect, god-like being would be able to match the completion time of the TAS on the real console (give or take a few frames due to possible tiny differences between the emulator and the real hardware) and how it would look like.
All the glitches, rng manipulation and such techniques are perfectly replicable on the real console, even if it's a one-time event (due to whatever randomness there might be left when the console is started/reset). It would be possible for a perfect god-like being to replicate the completion time because he would be able to use all the same tricks and techniques. (Heck, a god-like being would probably be able to complete the game faster on the real console because TASers are fallible humans, even when using tools to aid them.)
Joined: 6/28/2004
Posts: 219
Location: Raccoon City
OmnipotentEntity wrote:
I never found much of an issue, just because the game starts with a random state doesn't mean it CAN'T start with the same state as the emulator does.
The game can not be infinitely random because there must be a memory limitation on how high whatever number is generated can go. because the game must be finitely random, then at least 1 of these random startups will coincide with the initial state of the TAS. Therefore, TAS's are possible on real hardware, and this entire thread and closing of the site is for nothing.
case. in. point.
edit: read the front page. got it.
I never found much of an issue, just because the game starts with a random state doesn't mean it CAN'T start with the same state as the emulator does.
The game can not be infinitely random because there must be a memory limitation on how high whatever number is generated can go. because the game must be finitely random, then at least 1 of these random startups will coincide with the initial state of the TAS. Therefore, TAS's are possible on real hardware, and this entire thread and closing of the site is for nothing.
case. in. point.
edit: read the front page. got it.
That would be true, if not for the fact that the NES were also affected by external conditions; slight variations in timing crystals and so on.
It's been discussed already - you'd need not only the right starting state, and for all physical conditions to exactly match the 'averaged' assumptions of the emulator.
It's not just a single value starting from an unknown value, it's the entire hardware setup and how it mechanically proceeds with its operation. Everything from the temperature of the room to the TV can effect how a console runs. Its not at all guaranteed that even two consoles fresh off the same assembly line played side by side on two TVs fresh off the same assembly line by being fed the exact same frame perfect input would behave the same; you'd eventually get a de-synch simply because the timing mechanisms are NOT perfectly deterministic machines like we'd all been led to believe.
There's no knowing if any given input file would ever work on the original console simple because there's no way to know from any given emulation whether that specific timing variation is possible (And probably isn't given that its based on a perfect average of something that's random).
The flaw of current TASing lies in our method of storing session information in a keypresses file. If only every game had ingame replay mechanism, we wouldn't need all these imperfect emulators. Well, dreams.
Input file is only quick-and-dirty solution that was used in 2003, but didn't evolve too much.
Would it be any better if each press of the "frame advance" button goes to the next input opcode rather than the next... whatever it currently goes to? I remember Nach mentioning something about this a while ago, but I don't remember the context.
Limne wrote:
There's no knowing if any given input file would ever work on the original console
Until someone succeeds in making a device that can play the file on the console, that is.
Just how much variance is there in the performance of the console due to temperature and all of these other factors? Can they cause it to execute opcodes out of order, for example? It seems like that would crash games pretty quickly.
There are programmable controllers... The problem is that they'd be too unpredictable to be useful for just these reasons.
As for the amount of variance, you'd have to ask Nach, he's the one who's been explaining these things at length the last two or three days, but here's an excerpt:
Nach:
While working on SNES emulators, we came across at least a dozen different games that don't take any steps to protect themselves against variable timing.
These games if left running long enough (a few hours) would reach an "impossible state" and crash the game. I don't remember the exact games off hand though.
The point is based on this variance in timing, sometimes a game would poll input on the 6th video frame, sometimes the 7th, maybe occasionally the 5th, because the timing crystal beats erratically, essentially some milliseconds are longer, some shorter, regardless of the initial state of the system.
Think of how pseudo-randomness works, and why some chips have thermal based randomness. If you could externally measure the beats of the crystals in the SNES (and similar systems), you'd have a true source of randomness.
Because of this, every game on these systems are inherently random throughout. Some to the extent where the game could crash, others just that you have an extra frame or one less frame of video between events.
Our emulators on the other hand are based on computer systems with more precise timing, and a more precise construct running the game, making frames last a consistent amount of time, based on an average of how long a frame lasts on a real system. But this means that how long it lasts is also different from a real system, no matter how you look at it.
I have never known a NES game to deliberately crash if RAM has a pattern in it, but it was a rather common antipiracy trick on the c64, to defeat the freezer carts, that would clear out the ram or write a repeating pattern to it so they knew what ram was occupied by the game and what ram was not when you pressed the RAM copy button. So when they detected a pattern in unused memory they would jump off into never never land (the cpu had a handy "illegal opcode" that crashed the cpu instantly, requiring a poweroff). TO even get them to run at all on emulators, you had to randomize the reset pattern, or pick a pattern the game didn't know how to check for. Or just remove the protection. Particularly devious ones would actually write the state of some unitialized ram to disk, and if it was the same next boot, crash. Oh, and if it couldn't write the state? crash again.
It's true an emulator has to idealise the timing crystals, as it's truly impossible to simulate a real life imperfect oscillator affected by the environment accurately. This is also an issue with the PSX, where they didn't all run at the exact same clock speed, and some games didn't have proper tolerance for this (Gradius Gaiden, we're looking at you).
But an emulator CAN make uninitialized ram random. It can make the initial state of the DMC random. And such an emulation will be more accurate than one that does not (it's behavior will be closer to real hardware). And on such an emulator, the game would become unTASable, without provisions to store the initial state of ALL memory and write only registers when recording starts. (just because they are write only on the real hardware doesn't stop the emulator itself form reading them) But then we have the possibility of people manipulating that initial state by hex editing the file. Is that legit?
Thanks for C64 trivia. I've heard of some games detecting copiers by checking available RAM size, but solving the task of recognizing data patterns just for the sake of copy protection... wow.
zaphod77 wrote:
But an emulator CAN make uninitialized ram random. It can make the initial state of the DMC random. And such an emulation will be more accurate than one that does not (it's behavior will be closer to real hardware). And on such an emulator, the game would become unTASable, without provisions to store the initial state of ALL memory and write only registers when recording starts. (just because they are write only on the real hardware doesn't stop the emulator itself form reading them) But then we have the possibility of people manipulating that initial state by hex editing the file. Is that legit?
Here's how I see it. Every TAS starts from savestate, which is embedded into emulator instead of keypresses file, so that noone can manipulate that state. Thus there's no difference if emulator simulates random state of RAM/registers/etc at the moment of opening ROM file, or it doesn't. It still has to "load" the clean savestate after opening movie file. That seems quite legit if you ask me.
Advanced accuracy of emulation has nothing to do with the problem (problem of not being able to repeat TAS session on real hardware by feeding it with just keypresses file). I guess to solve the problem you have to be omnipotent entity - to control the state of real console and load "clean state" at will.
