Locked



sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Nach wrote:
[...]how are we any different than YouTube?
Significantly better video encoding, on the whole. Not that that's much use when we don't have anything worthwhile to encode.
Post subject: Re: Youtube
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Is that fact worth the rather large monthly server bill? We have a youtube channel, we could just upload some of Flygon's excellent HD encodings.
It's hard to look this good. My TAS projects
Post subject: Server Renewal, YouTube, Archive.org, TAS?
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Well, we do have the server paid through till the end of May right? So we basically have two months that we're locked into and is already a sunk cost, before we have to make a decision on what we're doing. The question is, do we renew for another year or not? If all we're going to be doing is entertaining runs, people can upload them to YouTube, and do HD too as adelikat points out. Further, whoever encodes a game can put the original MKV up on Archive.org, and link to that from the YouTube video. It is getting harder and harder to see how we're going to be relevant at all. Although, I wouldn't say there won't be anything worthwhile to see, I'd subscribe to a Tool Assisted Superplay channel on YouTube. Speaking of Tool Assisted, is it really "Tool Assisted", with these realizations, it's more like we're assisting the tools to make the movies, not the other way around, as making these movies are built up on emulators and can't be separated from 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.
Post subject: Re: server
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Well, I don't know the exact details on our server agreement. I might be able to get out of it sooner. I'll contact them and exactly how long we are committed.
It's hard to look this good. My TAS projects
Post subject: Re: Server Agreement, Backups
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Well, we registered for it last June, for a year, with a discount. Part of the agreement to get that discount is that you can't cancel before a year. Which means till the end of May. Besides, if we could get it earlier, which I guess is end of April, maybe we should give our users time to backup whatever they like before we shut down the site? If we decide to go through with this, we can immediately put up a message on the site that we're shutting down (with sufficient apologies and rational of course). And we'll leave people with a little over 2 months to backup whatever they want to backup. Sure even one month should be enough for people to backup, but we already paid for the two months thanks to kind donations, so let's give people the extra time, and then we can just let things take their course, instead of fighting with our hosting company over that last month.
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.
Editor, Reviewer, Experienced player (979)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
Hey everyone, sorry for being late to the party. Well, sort of a sad party, it seems. At first I thought this was blown a bit out of proportion, since it seemingly only affected Blades of Steel, but after a while I realised we have no way of knowing exactly which games are affected and which are not. As I see it we have two options: 1) Test games on a real console. Someone buying all the games we have movies for is pretty much out of the question, so we will have to ask for help from our members. Those with a flashcart can help the most. 2) Check the games code to see if it uses input from any uncertain source, such as uninitialized values. This is also pretty much impossible unless we automate it somehow. Nitsuja had an idea for an automatic desynch checker previously, which compared two frames with identical input after loading a frame. If the uninitialized values can be emulated (essentially just giving them a random number each reset), this could work. Either way, I think we should close the queue for new submissions until this has been worked out.
Post subject: SNES Emulation
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
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.
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.
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Does the exact timing matter as long as the same code runs predictably and consistently with the console from frame to frame? The only impact that I can see from this is that the times posted on the site will become meaningless, which is why we are talking about doing away with the speed category. As for accurate emulation, the trick, as I have been saying, is to figure out exactly how closely the games parallel what we are seeing on the console. By the sounds of what Nach has been saying, we can expect to see huge variability between what is possible between the two platforms, and we'll need to summarily reject anything that doesn't match up adequately; this could be done on a game-by-game, glitch-by-glitch basis and we can't accept a new run for a game until this has been done. That sounds like an awful lot of work for the minimal audience and duplicate functionality that the site would have at the end of it all.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
sgrunt wrote:
Does the exact timing matter as long as the same code runs predictably and consistently with the console from frame to frame? The only impact that I can see from this is that the times posted on the site will become meaningless, which is why we are talking about doing away with the speed category.
In most games which are programmed well, it only affects the timing, so things are longer, or not consistent, and a video frame count isn't accurate. But some games actually poll when VBlank is, an since some of the game is synced to the video frequency, and some to an internal clock, and they are timed differently, parts of the game get out of sync, and you effectively have randomness. Like I said before, a couple of games which do this aren't programmed entirely right, and given enough time running, the skew between the two timing intervals starts to create invalid states in the game and the game eventually crashes. It's not something consistent, can't be predicted, and introduces randomness, and we can't emulate this properly (and even if we were to, then we wouldn't be deterministic). Hence, the whole idea we're operating on doesn't really work.
sgrunt wrote:
As for accurate emulation, the trick, as I have been saying, is to figure out exactly how closely the games parallel what we are seeing on the console. By the sounds of what Nach has been saying, we can expect to see huge variability between what is possible between the two platforms, and we'll need to summarily reject anything that doesn't match up adequately; this could be done on a game-by-game, glitch-by-glitch basis and we can't accept a new run for a game until this has been done.
Reread what I said a few times. For at least these dozen games that we know have issues (and probably many others), it'd be impossible to match the system, as not even the system matches the system one play-through to the next. And we can't accurately say whether a given state is a state the game would necessarily get into or not.
sgrunt wrote:
That sounds like an awful lot of work for the minimal audience and duplicate functionality that the site would have at the end of it all.
I think there we are in agreement.
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.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
So, it seems we are more or less agreed on the matter of shutting the site down. Truncated is probably right we should close the submission queue ASAP. However if we announce this now, right before April 1, people are going to think it's some kind of joke and won't take us seriously. Maybe we should wait to announce till the end of the week? Further, since many people probably save submissions for this time of year, we'll probably be less hated if we go out with a smile, and not lock the submission queue until after everyone submits their joke submissions. It won't be so bad to put things off for a few days if people still have nearly two months to backup. On the other hand, maybe we should announce the shutdown now so people can start to back up, even if they won't take us seriously right away? Thoughts?
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.
Post subject: Re: Shutdown
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Nach wrote:
However if we announce this now, right before April 1, people are going to think it's some kind of joke and won't take us seriously. Maybe we should wait to announce till the end of the week? Further, since many people probably save submissions for this time of year, we'll probably be less hated if we go out with a smile, and not lock the submission queue until after everyone submits their joke submissions. It won't be so bad to put things off for a few days if people still have nearly tow months to backup.
This either won't be taken seriously at all, or will be taken extremely seriously. Announcing it in the aftermath of the usual wave of 1 April submissions will help soften the blow and reduce the amount of ill-thought-through anger that usually happens when something controversial of this nature results. Also, announcing this immediately will mean that we won't see those submissions, and people will get annoyed that their work was for nothing. (After all, those runs are presumably being done for the entertainment.)
Post subject: Joke Submissions
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Well submitting a joke submission isn't for nothing even if the site goes down. We'll all get a laugh out of Color a Dinosaur 2.0, even if the site won't last much longer. If we do announce the shutdown soonish, we can request people to still submit their joke submissions to give everyone a laugh alongside the bad news, since we'll be needing some funny things amidst the anguish.
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.
Post subject: Re: Joke Submissions
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Oh well. Way to kill the mood. Well, I suppose you will do what is necessary. I guess it is better to do it on such a festive occassion than on some other time. It gives people the benefit of doubt, too; it will be easier to discuss the dilemma than if it is done on some “serious” day. I am concerned mildly of this because I am also going to submit one such submission, in the usual tempting fashion. I know I should not, but… It is most difficult for me to just throw away some work I have done.
Post subject: Re: Server
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
So this morning I received word about our server contract. We can get out of the server agreement despite having prepaid. However, we are on the hook for the month of April. So if we want we can keep the site up for the next 30 days. I'm thinking that we need to put up an announcement on the main page. Should we keep the site going for those 30 days? Over the weekend I did some soul searching. I pondered if we were crazy for doing this. But every logical chain worked its way here. It has left me quite depressed actually. No TASing and no running the site has left a void in my days. Not sure what I am going to do now. I feel a little angry too, like I've been led astray by a hoax. In 2004 I just wanted to see some asian guy beet SMB3 quickly. Had TASing not happened, I would have found a legit hobby - namely speedruns. Just think had I found a console run instead. What kind of speedrunner could I have been? I wonder how many other people we have ripped away from legit competitive gaming and desensitized them with these hoax movies. I guess I will begin writing a solemn announcement for the front page. I should have it up by tomorrow at the latest.
It's hard to look this good. My TAS projects
Post subject: Making this thread public?
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Sorry for the double post, but I have been thinking. Perhaps this thread should be made public along with an announcement? It might help people help understand how we made this decision.
It's hard to look this good. My TAS projects
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I agree with the thread being made public at the time of the announcement; it should help soften the blow significantly by showing that we've considered all possible avenues of attack on this problem - a lot of the thoughtless backlash that we would otherwise expect will be avoided that way.
Experienced player (828)
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
adelikat wrote:
Should we keep the site going for those 30 days?
Yeah, I don't see the harm in that. People can harvest their favorite TAS input files and encodes for future watching. And it may help to give some people closure.
adelikat wrote:
No TASing and no running the site has left a void in my days. Not sure what I am going to do now.
I agree :( I've poured quite a bit of time into this hobby, but it's not something I'm likely to continue without a dedicate site to showcase mine, and others, works. It has become one of the main ways I spend my spare time since I joined in late 2006, and I'm sad to see it go. :( I guess there's always youtube...
Living Well Is The Best Revenge My Personal Page
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
We definitely need time for people to backup what they want before we close down. I should make a tarball of all the input files ever submitted, and we can let people download that. I have some time to do that later this week. In the mean time, probably would be a good idea to make an announcement, and at the very least, summarize some posts here for our fans.
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.
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
What good are the input files? I thought we'd established their invalidity for the purposes of most types of run (entertainment-based runs aside). In the absence of the extra information from the site, they'd be difficult if not outright impossible to get to play back properly. We have the encodes for anyone who just wants to watch the runs (in cases where we haven't already done so, we can just upload those to archive.org), and verifying the runs by means of the input files is meaningless because we know that everything involved is cheating anyway.
Experienced player (828)
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
I'd rather have the input files because they take up less space, and I can still watch them via emulator for the entertainment value. 500 some-odd encodes is not very HDD friendly.
Living Well Is The Best Revenge My Personal Page
Post subject: Input files
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
sgrunt: Regardless of the accuracy of input files, people may want them, and many videos we have not encoded. So we can make an archive which will be some dozens of megabytes, or we can spend the next who knows how long encoding every submission ever, and then uploading them all to archive.org. I think the former is an easier backup system. Even if we really preferred the latter, we can't do it within a month. And yes I know some submissions are utter trash, but many weren't, and were only rejected because we felt this wasn't the right site for them, not because the movie itself was inherently bad.
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.
Post subject: Re: input files
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Why bother backing up these files? They are a bunch of pointless files of people cheating and claiming it can be done on a console, who cares? If I were a stronger person, I'd delete them from the server right now :/
It's hard to look this good. My TAS projects
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Disk space isn't my concern here. My concern is the input files being usable for anything at all. Let's say a few months from now you decide that you want to play back an input file. You dig out an .fcm. Now, FCEUX should be able to play that back in .fm2 form, so you convert it to an fm2 and start playback. Lo and behold, the run doesn't sync. You would love to know why, but, oh, look, the site resources have all gone away, and you have no idea what the problem might be! Given that there are still runs presently on the site made with FCEU 0.98.12 which indeed don't sync with FCEUX, this is a very real probability; versions of other emulators (say, Snes9x with 1.43 vs. 1.51) will demonstrate similar issues. As another example, let's say you track down a .pxm, and want to play it back. Lo and behold, plugging it in to the latest version of PCSX-rr doesn't sync. You would love to know what plugins are needed to play back the run, but, oh, look, the submission text doesn't exist any more, so you can't figure that out! Basically, the input files by themselves are generally useless without the supporting information the site provides.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
We'd host them because people put work into them, and its memories for some, not because it's really worthwhile in any way. And obviously for playback, they'll need to grab the right emulator. But you bring up a good point, trying 16 different versions of an emulator can be a bit annoying, so I guess the tarball should include /*S.html from the site.
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.
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
The submission text by itself doesn't hold all the answers. Firstly, people will need to know where they can get the appropriate versions of emulators; it's not very easy to track down obscure older versions these days. Secondly, the submission text may not document everything necessary to get the run to play back. Perhaps the author forgot to go back and include something which has proven necessary to get the run to play (the firmware tinkering with 2473S comes to mind), or there just isn't very much information there at all (especially true with some rejected submissions). A lot of these things are discussed only in the forums, and it's not practical to include an archive of them - it would be too much work to go and find everything relevant to getting runs to play back (emulator-specific information isn't going to be restricted to the submission threads) and including everything isn't practical from either a disk space or a usability perspective (offloading the necessary work to go and find the relevant info to viewers would just be mean). Basically, I think it would take more work to assemble the relevant information to make the input files usable than we have time for.

Locked