creo: thanks for the half-speed! You don't have time to grasp what's happening in the full-speed ones, so i think there should be such an encode for the full video. The sounds are a little off but i'm guessing that's just the speed-halving.
No problem. For the sounds I use GoldWave's "Time Warp" effect; it has several modes and I'll try the other ones...
Also, do you have a powerful enough computer to do your own encodes? If so, could you provide one? My laptop is sufficiently old that I can't power SNESHawk to 60fps.
That's not the point he was making and your analogy is completely out of whack. If there ARE indeed errors, then fixing them is indeed improving the run. But treating existing runs as if they are problems themselves that have to be fixed is wrong and would wipe out most of the site.
I admit that I had some trouble understanding FractalFusion's point so my analogy may be inappropriate.
However, who said that all existing movies would need to be converted? The first post in this thread was talking about what to do when there are "some people that wish to try improving a movie from an old emulator". Doesn't sound like a new policy that declares all movies on older emulators invalid to me.
Tangent wrote:
It's not the content, it's the container. Not correcting an actual error, just presenting it in a different emulator. If you want to really stretch the book analogy, it's more like republishing from hardcover to pdf. Sure, it's a lot of work to type it all out again (ignoring scanning and OCR), but that's not the same as writing the book yourself.
That's exactly my point too, and the reason why I suggested separate "resynced by" field(s) on the previous page.
AnS wrote:
I think we were talking about the hypothetical situation where the author of resync wants to remove names of authors of the original run.
Allowing that would be illogical, I don't think we need to discuss that.
Mostly referring to our authors' efforts in creating the TAS. In my mind, the TAS efforts that we present with our existing publications are undermined if one irreverently presents resyncing as a solution to a problem that really doesn't exist, in effect declaring existing publications as "problems" to be fixed no matter how much effort the authors put into the TAS. This is also where I feel the distrust comes in.
The problem does exist if the TAS can't be played back on a more accurate emulator.
Resyncing does not change the actual content (gameplay) of the TAS, it just adjusts it to a slightly different timing situation. Therefore I don't see why TAS authors should feel bothered about it at all. It's like saying "the author of a book misspelled a word, the editor fixed it, now there's distrust between them".
Statistically speaking a single person is always going to make errors no matter how much effort is put in; nobody should feel personally attacked if these errors are pointed out.
Sure, there are a lot of emulators that has big flaws (FCEUX, VBA), but this doesn't mean that BizHawk or lsnes are the holy grail.
No, they are. The point of using the bsnes core, which is what is used in these emulators, is that it is so accurate that further accuracy improvements will have no impact on commercially released games. The timing has been 1. figured out and 2. emulated correctly. Once a TAS has been created for these emulators, it is extremely unlikely that it will need to be modified for playback on newer versions.
Also, emulators that emulate the games just like the real SNES does is a great step towards making these runs feel "authentic". The idea is that a TASer with superhuman reflexes could've gone to the system's release event and finish the game in ten minutes. If a TAS runs only on SNES9x but not on BizHawk, there's a chance that the run's techniques worked only because the game was emulated incorrectly - which would be disappointing (and making the above impossible).
- Movies created for more accurate emulators automatically obsolete movies from lesser accurate emulators (e.g. opcode accurate < cycle accurate) as a new category because the older movies are now basically in the category of "movies for hacked games".
Does the platform have a "perfect compatibility" emulator (e.g. bsnes)? If yes, use that.
If not, and there's one or several emulators that can run the game, use the most compatible emulator and the least invasive fixes (settings, patches etc).
Preferably host this software package on the site (even, or rather especially, if it's game-specific).
Of course it looks largely the same: the interface (i.e. hands) hasn't changed. The advantages are inside:
- online connectivity
- more customization (in terms of third-party programs)
- much more storage space
- better graphical abilities
I'm not sure we have very strong legal grounds for requiring any kind of credits.
At the very least the input sequence is solely the "intellectual property" of the TASer, similar to how a company develops advantageous gene sequences or an author writes a book.
Then there's the act of creating the video. Official TASes don't have much creativity in them except the decision of where to place the logo and where to end the video, but some users (like Saturn, evilchen and myself) have created what could be called "TASMVs" (TAS music videos).
Of course this is the internet and data is widely available to anyone, so there's not much one could do except pleading for fairness and/or contacting the video hoster.
I guess it won't ever solve the equation of what the fastest route is, but to even be able to predict where each missile is a what time would be useful + I think that's something that's going to be useful in lots of levels. So if someone has time, it wouldn't go to waste to find the missile speed and create a basis for that sort of calculation.
It takes 632 frames for a missile to go from left to right and back again, and 232 frames for the missiles in the upper areas.
So one complete cycle is 18328 frames (~4min).
I made a slight gaff when re-stocking on holy bottles in Alvanista. Didn’t realize you could enter Alvanista from the southwest stairs beside the item, weapon & armory sign.
[...]
in the real run
[...]
I should’ve done this to begin with
Grid is 12x12 pixels, i.e. 26x16 blocks.
