Personally I have never liked "rules nazism", and I really think that exceptions to the basic rules and quality standards can be made in a case-by-case basis. I do understand, however, the concerns about this setting unwanted precedents. ("Hey, you accepted that OoT run which had obvious flaws and significant known improvements, why are you rejecting my run of game X, which has significantly less flaws? That's unfair and hypocrisy.")
If what people have written in this thread is true, it seems that while this run is an enormous improvement to the currently published one, it has obvious flaws and clear suboptimalities which in almost any other case would be grounds for rejection because it doesn't meet the minimum quality standards of the site.
So I suppose there are two possible points of view:
1) This is an absolutely huge (and probably record-making, at least in absolute time) improvement on an existing publication, making it significantly better, and hence it deserves publication. The obvious flaws and suboptimalities can be penalized by giving it a low technical rating (which is what that rating is for, after all).
2) The run does not meet the current minimum quality requirements of publication, and publishing it just because it's OoT would set an unwanted precedent which may cause protest and animosity in the future.
Pick your choice.
Sonikkustar wrote:
Besides, No movie can ever be perfect.
There's a difference between "is not perfect" and "has obvious flaws and significant suboptimalities".
Lot of games released for both console but Megadrive has better graphics and sound
Wait, what?
Yeah, that claim confuses me too. The SNES had things like additive alpha blending, while in the Megadrive you only had 1-bit transparency (which means that if you want to simulate a semitransparent layer, you have to use a checkerboard pattern of fully transparent pixels).
Also, the SNES uses PCM sound samples (which are mixed by a dedicated processor), while the Megadrive has a sound chip which is basically the precursor to the one used in the Adlib soundcard (and it really sounds like it).
Given that other people seem to be having the exact same problem with other software which use the same x264 decoder as mplayer, I think that the problem is in the decoder itself.
Anyways, I noticed that there's a newer version of mplayer in the Suse repository, and I also fiddled a bit with the x264 settings, and now the encoding succeeded. I don't know which one affected this. Perhaps updating mplayer.
I think there's a rule of thumb which helps deciding on most of those issues: Maximization of entertainment.
Given that we are slowly reaching the point where we can TAS games which have different graphical quality settings, I think that the most obvious rule of thumb is to maximize visual quality, unless there's a very good reason not to. (Most modern games don't become slower with this, they only update at a lower framerate.)
I'm not sure so many similar tags are necessary or useful.
Then have you changed your opinion from last year? By this I mean the following statement:
I think it might be a good idea to distinguish between the game's own warps (eg. in SMB1) and "warping" due to glitching.
"Uses warps" has a whole different meaning in those cases.
I though that you were suggesting tags to replace the "heavy glitch abuse" tag. If you were suggesting more detailed tags to replace the "uses warps" tag, then it might be a different issue, although I still think that four tags is a bit too much.
Ever wish you knew in advance how everything around you would happen?
To the tiniest detail
Ever wish you could change what you knew would happen?
Subtly manipulating seemingly irrelevant, chaotic factors
Ever wish you could go back and fix that mistake?
And in case you fail to fix it, try again
And again
Ever wish you could have made something just perfect?
Perfectly coreographed
To the tiniest detail
This is TASVideos, to video games.
I've always thought of heavy glitch abuse as meaning "abuses programming errors to skip significant portions of the game."
It's not the only case where it applies. If a run abuses glitches to, for example, get 99 items of a certain type, that's quite heavy glitch abuse.
Thus, I think there simply needs to be more to distinguish between different kinds of warps:
I'm not sure so many similar tags are necessary or useful.
I'm wondering about how useful "manipulates luck" is as a category. As has been pointed out before, most games have it in some sense or another and I don't see why you would ever NOT manipulate luck if it would help.
As has been commented many times, there's a difference between "heavy luck manipulation" and the regular luck manipulation which happens in almost every run. I won't repeat the discussion here.
It works if input.avi is short, but if it's quite long (haven't measured the exact threshold, as x264 encoding is slooooow...) I'm getting a bug. At the very end of the second pass I get this error:
x264 [error]: Incomplete MB-tree stats file.
x264_encoder_encode failed
and then mencoder hangs completely (the only way to kill it is with "kill -KILL", no other signals will stop it).
The resulting avi is broken, as it lacks an index. Even if a rebuild an index using mplayer's -idx option, the video file is broken (it issues tons of errors of the form "[h264 @ 0x890f040]number of reference frames exceeds max (probably corrupt input), discarding one" and the video becomes full of artifacts.)
This is clearly some kind of bug in the x264 encoder, but since I know encoders here are using multipass encoding with it (and with quite long videos) without problems, I wonder if anyone would have any hint about why I am getting this problem.
Google is unhelpful. It seems I'm not the only one having this exact same problem, but nobody in the universe seems to know why it happens or how to avoid it.
The mplayer version string seems to be "MPlayer dev-SVN-r29796-4.3-openSUSE Linux 11.0 (i686)-Packman (C) 2000-2009 MPlayer Team".
Your time measurement is flawed.
If sorting the 1000 integers takes less than one tick of the clock, it will be measured as taking 0 seconds. IIRC the clock() function updates less frequently than 10000 times per second in linux systems, so it's perfectly feasible for a piece of code to run faster than that. And even if it doesn't run faster than that, if the clock ticks only a few times, there will be a rather big rounding error in the timing.
2players: Should it be only movies where 2player is slower or every 2player movie?
I suppose it would be informative to use the category even if the 2-player run is the "main" run (ie. the fastest one). This especially so if a category name is included in all file names. (Of course this raises the question of whether it would be necessary to somehow indicate that this is the "main" TAS of the game even though it uses 2 playable characters...)
Another dilemma: What if there are two different runs of the game, both using 2 playable characters but with different goals (eg. any% and 100%)?
Btw, the "2 players" has always been a problematic term because it's a bit ambiguous. Generally speaking it means that two controller inputs are used to control two independent playable characters (one controller for each character), as if there were two people playing the game (even if there's only one author). This is different from a run having 2 authors (who might be controlling the one and only playable character at different points in the run) and also from the game having 2 playable characters but still being a 1-player game (iow. the characters are played in alternation by one player with one controller). The same goes for other amounts of playable characters, of course.
But I suppose "2player" is unambiguous enough for the file name, especially since it should be short. (We wouldn't want the category to be something like "oneauthorcontrolstwoplayablecharacterssimultaneouslyusingtwocontrollers").
warpless: self explanatory
*snif* :..(
anypercent: only if needed. Again, I think this only applies to metroid
"any%" is also more or less synonymous with the "main" TAS of the game (ie. usually the fastest one). In other words, it means "just get to the end as fast as possible, disregarding any other goals" (in other words, things like collecting items are completely secondary and don't matter, as long as the run is as fast as possible).
If all file names should contain a category name, then we should think what it should be in the case of the "main" run, if not "any%".
Pro: The new nickname would match your new avatar better... :P
Con: All posts which quote you with a "Flygon wrote:" would become disconnected because people would then not know who is being quoted.
How about this: If we ever get movie publication #4999, the next published movie will jump to #50000 and start from there forward. That way the files will sort ok, and we won't be running out of numbers anytime soon.
(Yeah, half-kidding here. Maybe. Although the idea is interesting.)
It will scale the video a bit smaller, making room at the bottom for the subtitles so that they don't get mixed with the status bar in the game. (The subtitles are also scaled a bit larger than default). Works great on fullscreen.
So think of frameadvance as "Ok, I'm done for now - keep going as usual"
Scheduler yielding is what came to my mind as well, when reading the explanations in this thread (see "man sched_yield" if using linux for an idea). "yield()" would be a much more accurate name than "frameadvance()", which really doesn't.
The explanation clarifies the issue a lot, but the name of the function is quite misleading. Well, I suppose it's too late now for anyone to change it.
I didn't know Dallas had a capital. And what does it have to do with weather forecast? Man, I've seen dumb videos, but my brain exploded from the dumbness of that one.
You did understand it's a parody, right? The description itself makes it clear (well, at least the tags do). Also there are clear telltale signs, such as a 555 telephone number. It's not like it tries very hard to hide being a parody.
So if the lua script does indeed command the emulator to advance to the next frame in an infinite loop, like in all the examples in this page, the user does indeed lose control? That's how I read these example scripts to mean, and nobody has given any other explanation.
From your description I also have to deduce that the emulator does so as fast as possible, without any delays or pauses. So the game would just fly by as fast as your computer can emulate it...
But the example scripts given in this thread wouldn't make any sense that way, so there's obviously something else going on.
Would it be a big trouble to just explain how it works? I'm pretty sure I'm not the only one who doesn't understand what that "frameadvance()" function does. It just sounds to me like it really means "wait until the next frame before continuing executing the script", because that would be the most logical interpretation, but the name of the function says otherwise.
Is that supposed to be a furret eating a cheeseburger?