Now, here's the bigger point. I can't agree with having both of these movies published anymore... they're just too similar!
I must admit there's some truth in this. If you watch one movie and then immediately the other, they indeed look very similar. It's like they are doing the same things, just in a slightly different order. Disregarding the order in which the rooms are visited, otherwise it feels like there are only quite minor differences (like one run not getting a weapon the other does). These differences don't feel like big enough to make the movies look all that different...
I think "takes no damage" has merit when doing so without losing any time is more difficult than taking it. Of course it would simply become another "abuses luck" which is mindlessly slapped onto every run without even the slightest thought about whether it really deserves the tag or not...
Btw, I think that in some cases "abuses programming errors" is given to games where actual programming errors are not abused at all, but level design errors are. Level design is not programming, and consequently abusing level design errors is certainly not the same thing as abusing programming errors. (Often level design errors arise from the level designer not knowing that with the game engine some very unlikely maneuver is actually possible, and it never comes up in testing. The maneuver itself is not necessarily a programming error at all.)
Another interesting question is that is something like zipping "abusing programming errors"? The zipping feature of some games is *intentional* and works exactly as programmed: The game engine has been explicitly programmed so that the character will be ejected from blocks, and it works exactly as programmed, and thus it's not a programming error. (Of course one could argue that getting inside a block is the error, not the zipping per se, but one could also argue that if the zipping was coded into the game the programmer knew that there are situations where you can get into blocks. If he knew that and he programmed a solution for it, is that really a programming error? After all, everything works exactly as the programmer intended.)
Moi. I'm not very entertained by Super Metroid at all, and all "uber 1337 $Ubp1x31 0p+1m@z@+10n$" look pretty much the same to me (which is saying something, considering I can spot pixel mistakes with ease in other games. When watching in real time.) Differences in route to save in-game time will not look any different to me at all, since I've never played the game and thus will not know a route change when I see it. Hell, the only thing that stood out to me as being visibly new was the Torizo skip. Add in that in-game time saving tricks also look identical to real time strategies, and the run really did nothing for me at all. Neither did the first version.
"Two characters controlled by 1 author" would be more accurate, although a bit clumsy of an expression.
The "1 author" part is the part which is, at best, unnecessary, and also frequently incorrect.
Well, in the case where two authors make a movie, each controlling one playable character, then the movie would not receive that tag, but something else. If one single author controls both playable characters, I think that's a feat deserving its own tag. While I don't have personal experience, I can assume that controlling two playable characters is at least slightly harder and more laborious than controlling just one.
I agree with Aqfaq. I think it should just be "controls 2 players" or simply "2 players".
Couldn't "2 players" be easily understood as the movie having two authors?
Besides, what are controlled are not players but playable characters (ie. PCs).
"Two characters controlled by 1 author" would be more accurate, although a bit clumsy of an expression.
While I still don't like the idea of beating the in-game timer at the cost of real-time, maybe it wouldn't be such a bad thing to have both categories published. I'm voting yes, with two meanings:
1) Yes, if "aims for fastest in-game timer" is considered a valid alternative category, this movie should definitely be published.
2) Yes, perhaps both "aims for fastest in-game timer" and "aims for fastest time" should both be published as separate categories.
Aren't people supposed to compile stuff from source on Linux?
That's assuming you can *find* the source codes, which in this case seems to be surprisingly hard.
As in, the binaries aren't usually distributed, or so I hear.
It depends. Most distros have official (and less official) binary distributions of most programs. Also many third-party programs are also distributed in binary form (eg. in RPM packages). Anyways, that's not really the problem here at all.
Thanks. It compiles and runs, but has no '-autodemo' option at all, nor any obvious way of replaying smv files.
I know some people are able to replay smv files in their linux systems. They simply refuse to tell me how they are doing it. I'm still at square 1.
Has the ability to replay smv files been completely removed from the linux version? The source code compiles and works in linux, but has no support whatsoever for the '-autodemo' feature. (The command-line parameter has been commented out in the source code, and even the commented-out code refers to some 'autodemo' variable which doesn't exist anywhere in the source code, commented-out or otherwise.)
I know some people manage to replay smv files in linux. Everybody refuses to tell me how they are doing it.
The linux version of snes9x seems to be one of the best guarded secrets in the entire internet. For example, I can't find *any documentation whatsoever* about the command-line options of snes9x for linux *anywhere*. "snes9x --help" only prints a partial list of command-line options.
Even a better guarded secret is how to play smv files with linux snes9x. I can't find this information *anywhere*. Only from mouth-to-mouth word I heard about the magic command-line parameter "-autodemo". However, the "official" snes9x I have in my OpenSuse distro does not support this option at all. I can't figure out any way whatsoever to play smv files with it.
Seemingly some people have an ultra-secret version of snes9x for linux which can actually play smv files, but I can't find this anywhere. Even tasvideos.org only links to Windows versions of snes9x. No mention whatsoever about any linux version, much less a linux version which can play smv files. When I ask people about this, I only get silence. It seems I'm not part of the trusted inner circle.
Could someone PLEASE tell me where to get snes9x v1.43 which is capable of playing smv files for linux? I promise to keep the secret and not tell anyone. I'll make a blood oath and perform any necessary secret initialization rites if that's necessary. I just want to replay the smv files without having to boot to Windows.
That webpage is confusing, even though I understand Spanish. I still can't decipher what is it that they are doing/offering/whatever. What are the cards for? What do the cards have to do with that fighting game video? I don't get it.
However, it just feels like whatever product they are making, it's screaming for a trademark lawsuit... ;)
Yes, I obviously meant legit, original commercial (and non-pornographic) games, even if they had a limited distribution (which in practice means it was only distributed in Japan, and if it was distributed in the US, it was censored).
I suppose also I "own" HL2 twice because of the orange box. OTOH, since I bought the orange box through Steam, it didn't even download HL2 because it was already installed in my system, so I have only had one single copy of it, technically speaking. Just paid for that copy "twice".
I think generally at the site, the fastest possible movie is always published (whether it is 1 player or 2 player). A slower 1 player movie is almost never published, as it is likely to be less entertaining (and also slower in this case). A slower 2 player movie is published if it is more entertaining than the 1 player movie, but doesn't obsolete it.
Of course there's a gray line: What if the 1-player movie is 1 frame faster than the 2-player movie? My assumption is that it would hardly be published. If so, where is the line?
- To step backwards one frame, jump to the previous frame using the above technique. This will get slower the closer you get to the next second, as it will involve up to 59 emulated frames for every step.
I don't know how fast emulators can emulate and playback a movie file internally (while not refreshing the screen), but I would bet it can be done very fast. Thus I assume that the emulator restoring the last automatic savestate from memory and internally playing back 59 frames should probably happen in a small fraction of a second.
One interesting question is whether the "number of trailing zeros in n!" function could be written as a non-iterative/non-recursive function (ie. one where the number of required operations does not depend on the parameter). If it can't, proving it could probably be quite hard.
I do think a movie which aims for 100% kills, aims for fastest time when possible, and uses options to create "art" is possible. This type of movie could obsolete both published movies.
As far as hitting 100% of the notes in the song, I'm going to go out on a limb and say that one measure of the song (measure 325, 90% through the song) will remain out of reach of human ability if for no other reason than hitting notes at a rate of 26.67 notes per second is unreasonable.
The success of that tactic depends a lot on *when* the program actually calculates which item to drop. If it calculates it *after* the enemy has been killed, then simply watching memory locations won't be of any help, because you may as well just watch the screen to see which item was dropped. It won't save you any work at all.
If the item to be dropped is calculated before the enemy is killed (as it may be the case with some games) then it can be quite useful to see in advance what that item will be. However, I don't think many games do this (because from a programmer's point of view it's much simpler to simply calculate a random drop item after the enemy has been killed).
This doesn't mean that in the first case it's *impossible* to predict which item will be dropped. It's just much harder. It requires a great understanding of the game's RNG and what affects it and how.
That's a completely different category because it's so explicit. The video I linked is *unintentionally* gay. If we are talking about *intentionally* gay music videos, then nothing beats something like this: http://youtube.com/watch?v=ayZGZ2NSxs4
Both FCEU 0.98.16 and FCEUXD have memory editors. It's fairly easy to spot RNG variables with these, since they'll be changing, perhaps continually, in a random manner.
Yes, but it's a completely different thing seeing how the random numbers change than to reverse-engineer the RNG to such extent that you can actually predict what it will produce with certain input.
