Yet this had almost no examples. But as we move to the improved emulators, there may appear some people that wish to try improving a movie from an old emulator AND make it on a new one - at once. Sometimes they succeed right away - they find improvements, the new movie obsoletes the old one, everyone is happy. But there are high chances that the existing movie is so tight no improvements are found. And even resyncing the strats or the exact same input requires some delays due to improved accuracy.
All the above is relevant only when we are really moving to more accurate emulators. For two (almost) equally accurate emulators, there must not be any resync work I guess. So here I suggest to work out our new setup for handling resynced for better emulator movies. My ideas:
- Make sure the emulator used to resync on is really better in all ways. There must be some official statement declaring movies of which emulators can be resynced for which emulators. Say, any snes9x movie can be tried to resync on BizHawk or lsnes. But there is no way BizHawk NES emulation can obsolete FCEUX NES emulation right away. Yet.
- - If the above is checked, examine the following.
- Is any time saved overall?
- - If it is a real-time improvement, there is no point to argue, it's an improvement. But it is still needed to know if this is a gameplay improvement, or just a resync luck that affected some lags or RNG on a better core. True gameplay improvement must obsolete the existing movie. Technically lucky resync must be judged as the following.
- - If no time is saved, it must be precisely examined whether all the gameplay time savers of the existing movie were applied or not. Experts of that game must be asked, precise statistics must be prepared on where and why the time was lost. Such a submission is no more under a standard discussion. The new question is: Is it a fair and successful resync for the improved emulator?
- - - If the experts conclude that it's not, it is rejected.
- - - If they find it really was a fair and legit resync attempt, the following goes.
- That movie file gets added to the existing publication, adding the author of resync to the current movie author. The note on what this second movie is are written in the publication description.
- If someone then makes an improvement over the resynced movie on the same (better) emulator, we watch if it is faster than the original movie or not.
- - If it is slower than the original (old emulator) movie, only the second file is replaced. Another author is added if needed.
- - If it is faster than the original movie, yay, we finally got it! Obsolete the whole publication.
- - If it is slower than both, reject.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
adding the author of resync to the current movie author
What's the reasoning for this? "They did something and must be acknowledged for it."? While I'm sure it's not trivial to resync a movie, it's a lot easier than making an original one. Especially for short, extremely highly optimized movies made by the hard work of one person, it seems highly unfair for someone to simply reverse engineer their work and claim equal credit. Or even in some games where there's little randomness, to just look at the inputs and replicate them. A note within the submission I'd think would be fine, but not equal billing for replicating or verifying someone else's run.
Furthermore, comparison seems like an impossible standard without a specific change in the play somehow. If the original movie delays an action due to RNG or lag manipulation and the new movie does not, has to delay less, or just says "remove lag frames to compare," is that truly an improvement?
This is why I have it so much branched. If it is slower, it is only a conversion and must be hosted nearby. If it is faster due to lag frames in non-gameplay places or something, it's not an improvement and must be hosted nearby.
Co-authorship may easily be unequal (one person tases 1 level, another tases 50, both are credited). Spending effort on converting a movie for a new emulator, and on making the one that would satisfy the experts - is really quite some work. But I want to know the sanity borders.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
adding the author of resync to the current movie author
What's the reasoning for this? "They did something and must be acknowledged for it."? While I'm sure it's not trivial to resync a movie, it's a lot easier than making an original one.
Since when do we judge movies based on how easy they would be to perform, and how exactly do you quantify how easy a movie is to make or 'sync'? Furthermore, why would we not want to credit authors of even trivial movies?
I think including the newer emulator movie alongside the old one a decent compromise above obsoleting older movies with no improvements (which I agree is a very grey area - we must not ignore the efforts of the runners of older movies). For example, I'd certainly be happy for someone who resynced smw any% to be credited alongside us, though.
My reasoning.
Case 1: The new movie is more or less identical, perhaps different only due to emulator differences (faster or slower) but shows the same technical ability. Publish alongside old run.
Case 2: The new movie is faster due to genuine improvement. Obsolete old run.
The other alternative is to ignore the efforts of those who bring our movies into a state of being more likely to sync on console (this is what we want, isn't it?) - I don't much like this one.
- 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".
This is precisely what's in question as I would say that typically, replication is nowhere near as difficult as original creation. People have even written workflows here for how to do it, requiring very little human thought to follow. Good faith is the only way to tell the difference between a valid try that came up empty and someone just copy pasting the inputs with a few tweaks to sync it, and I don't see the argument for "You tried really hard to improve it, but couldn't, so here's a gold star anyway."
feos wrote:
Co-authorship may easily be unequal
This is a good point I hadn't really considered though, but I'd say the difference is that co-authorship as it currently exists is cooperative. Both are aware of the other's contributions and knowingly participated together.
Belated Edit: Or co-authorship is given BY the creator of a faster run long after the fact.
Resyncing, however, is not. And in the specific example that spawned this thread, the original author is antagonistic toward it. Although that is in part because it fails the very first test of "is this emulator really better in all ways," so perhaps may be less relevant, but I'm sure some people who put a lot of work into Snes9x 1.43 runs wouldn't be thrilled to have them supplanted by a resync.
It could also very well deter people from sharing their tools, processes, and workflow if those could then be used to trivially wipe out their credit simply from picking a different emulator. They have to at least do something different from the published tricks and tools to improve it and replace (or add) their names to the run. Removing the "do something different" requirement could very well dissuade people from sharing the code or tools they create.
I think the point is the Author/By message in the submission everyone looks at. If a person only does a resync with no improvements or the improvements are only due to the emulator, should they be listed as a Co-Author?
I do not think anyone would disagree with being listed in the end credits for porting the TAS, as what creaothceann said should be the standard.
On the subject of should they be a co-author, I disagree. While it is needed, it is not really doing work on the run, it is work on the container.
If anyone wants to make this discussion worthwhile, a rule-maker (have no idea who makes the rules on TASvideos atm) should detail why a specific emulator should be counted as "should be avoided". Sure, there are a lot of emulators that has big flaws (FCEUX, VBA), but this doesn't means that BizHawk or lsnes is the holy grail. They are improved vastly, and has way more better test results.
However just because emulator X "is more accurate" shouldn't be a reason and I don't even want to hear or read this expression again at least in this thread. Your question is right, why would I say that you shouldn't use more accurate versions?
This is the same reason I stopped a few of my TASes (Indiana Jones, Rygar, Battletoads on BizHawk). As you know, as long as there will be timing issues in these emulators, they will have a very big impact on the way people TAS it.
A short list that used to be abused by TASers in games that's very emulator sensitive:
- RNG manipulation: without any statistics, there are games that uses RNG depending on sounds, CPU cycle time, specific subroutine that doesn't rolls on lag frames
- Mid-frame resets: requires correct CPU cycle/PPU clock
- Resets: requires "somewhat" correct CPU cycle/PPU clock
- Lag frame removing: requires situations that can be impossible to do with different emulator timings
- Timed events: this isn't a big thing, but if there's something that you need to do super frame-perfect, a new emulator could make a lag frame there (I'm referring mostly laggy NES games which there's a lot of them), therefore it won't work, while in a newer emulator it could work.
- Memory corruption: if the game loads a specific value later/earlier, some values could be changed too (we are talking about CPU clock dependent things).
I think you know what I mean, of course there are more techniques that should fit in to this list.
This means, that everytime an emulator will get an improvement that will act more likely like the original console, these things will have to be resynced. This means that if an emulator with even slight core changes will get as many resyncs as versions it had.
First thing the rule maker should decide is when we should move on to the next emulator. He need to understand that the number of emulator (version) switching (which emulator should be accepted) should be minimalized as possible. Of course if there's no core changes, a newer version can be used (since it will be syncable).
Second thing is the reasons you want to change an emulator. In my opinion, changing an emulator just because it has better sounds or graphics shouldn't be a reason. I hardly can think of anyone who would resync super laggy games just because in one of the levels a star is now brighter.
Third thing is who will sacrifice enough time to observe every submissions that uses the techniques I've listed to understand is there any improvement that doesn't happened just because the emulator behaves differently.
Also ideas like "if slower than look this" - "if faster than look this" should be avoided, as I said, just because an emulator loads faster, it could have more lag frames and be slower in total time and vica-versa (emulator loads slower but has fewer lag frames and faster tota time).
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
MESHUGGAH,
Why shouldn't we (TASVideos) encourage accuracy to help further our claims of legitimacy? Some people think TAS runs are cheated runs. If we can prove that Run X, can be played on a console, then that shows that we are not just "cheating."
I can understand the problem that changed cores causes everything that was done, to become useless. But accuracy helps legitimacy and that's what TAS is about.
Using these tools, we overcome human limitations to complete games with extremely high precision, entertaining our viewers as our players tear through games at seemingly impossible speeds. The end result of this process is simply a series of key-presses which may be performed on the original hardware.
With that out of the way, I don't think that re-syncing a run on a more accurate emulator should be given the same weight or whatever we want to call it, as the original run gets. Yes, you did something good for TASVideos, but that doesn't mean you're the author that deserves all the attention for it. Yes, you deserve some notice, but you didn't break the game, the original author did.
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
It could also very well deter people from sharing their tools, processes, and workflow if those could then be used to trivially wipe out their credit simply from picking a different emulator. They have to at least do something different from the published tricks and tools to improve it and replace (or add) their names to the run. Removing the "do something different" requirement could very well dissuade people from sharing the code or tools they create.
This would be real disaster, actually. The most valuable aspect of TASVideos was the atmosphere of openness, and anything that undermines it can not be justified.
I want to emphasize my initial point that it is not expected to become a daily routine. Resyncing shall only be done if the old emulator is really worse and the new one is really better. Say, if the old one gets banned (disallowing further submissions on it) or deprecated (moving to banned in some years/months).
The point is to help the real TASers move to new emulators with less pain. And the effort must be done primarily when it is critical. Then, if someone feels like it, he may try tweaking some of the existing movies to sync on newer emulators. But I see the sanity border here:
Resyncing per emulator release is 100% pointless. Only between really old emulator and really new. It still must be more serious effort and with more serious grounds. This is why I support co-authorship. It vastly helps the original tasers to move to a new emulator (SMW+snes9x case), becoming a member of the game TAS team.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
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).
Super accuracy becomes critical with super glitchy/tricky TASes. We can't actually pretend on pushing the games limits if we have them not as they are on console. That can be tolerable for average level of TASing, for test WIPs, but not for super high quality projects. Of course some insane degree can not be reached, but improving is still improving.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
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.
Just a side note. Bizhawk isn't even the most accurate NES emulator let alone a holy grail that will never be improved. FCEUX is far less accurate than Bizhawk but to say Bizhawk is as accurate on the NES as it is on the SNES is not true. Not to mention there are many FCEUX movies that have been verified themselves.
On the topic I disagree with the co-authorship but am fine with some sort of mention. I would be ticked if I spent a lot of time on a run and someone else got half the credit because they realized adding 2 frames between a level would make it sync on a newer emulator.
I already posted at the Pokemon Yellow on lsnes submission, but I'll post part of it here as well.
I believe that anything that encourages others even to think about resyncing movies (especially those that are not theirs) is a bad idea, because it compromises standards of quality and causes distrust among the community, at a time when TASVideos should be about making new and entertaining movies. An "official resync policy" of any kind does not belong on this site. Cases like the submission I linked above can be handled on a per-submission basis.
Looks like people just don't read threads they post in.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
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.
A resyncing policy is simply not needed and we can deal with the cases as they come. How often are there such cases anyway? Maybe just someone who tried to improve a very short and very optimized run in a different emulator and ended up with the same result? Most TASers never even want to try that.
FractalFusion:
Imagine lsnes had a perfect GB emulation, and VBA had it terrible. And Masterjun did a run on a perfect emulator, what is slower than on a terrible one. Imagine even p4wn3r himself did that and could not improve over his own VBA movie. Would you accept such submission?
Or imagine Masterjun TASed SMW any% on BizHawk and it appeared to be slower than on snes9x (any branch of which is anyway worse than bsnes core). Would that be accepted?
The answer always used to be: if the gameplay was improved (no matter how long cutscenes lasted or how many lag it had on loading the level), it will be accepted. Otherwise - not.
But now (as I stated right in the first post), the question becomes (even according to your post): was the respectable effort put into making the very movie? Because if the effort was huge enough, you would need to accept the slower movie because it is way closer to being ran on console. But it presents no improvements in real time, though no misoptimization losses either, so it can not just obsolete the less accurate movie. This is why I suggest adding co-authors.
And once again, only VERY accurate emulator movies must be considered wanted to make off of VERY inaccurate emulator movies.
So, I'm just suggesting the ways to judge the cases you want judged case-by-case. Sure, it would be case-by-case, because there would be NO exact factor such movies could be accepted by (as now is real-time length). But each of them can easily be figured out right now.
Now please point out where my thoughts contradict yours.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Because if the effort was huge enough, you would need to accept the slower movie because it is way closer to being ran on console. But it presents no improvements in real time, though no misoptimization losses either, so it can not just obsolete the less accurate movie. This is why I suggest adding co-authors.
I still don't understand your logic. Please someone prove me, how hard is to resync the Pokémon TAS. I only tested Super Mario World which I could resync even without any TASing experience on that game and I hardly believe that resyncing Pokémon is harder in any way. Also "efforts" shouldn't count in adding co-authors.
"And once again, only VERY accurate emulator movies must be considered wanted to make off of VERY inaccurate emulator movies." - would you care to write these emulator "pairs"?
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
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.
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.
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.
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.
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.
I think we were talking about the hypothetical situation where the author of resync wants to remove names of authors of the original run.
Anyway, the whole situation is absurd. There should be no resyncs, except for truly frame-perfect runs. People should just improve old runs (while recording them for new emulators) and that's it.
1) New emulators are supposed to provide better tools (as the general progress goes), so that it's easier to find new strategies.
2) New people are supposed to have a fresh view on the game in question, so it's easier for them to spot some omissions in the old movie.
3) New authors are supposed to have full information from the authors of the old movie, so they don't have to reinvent the wheel, and thus they have more time to expand the existing knowledge base.
With all these advantages, a simple resync is laughable.
Anyway, the whole situation is absurd. There should be no resyncs, except for truly frame-perfect runs. People should just improve old runs (while recording them for new emulators) and that's it.
Snes9x v1.51 is, for the time being, still accepted.
So as long as that is still the case, there will still be people recording them on an old emulator because......nostalgia? User-friendliness? (Idk, I never TASed SNES games before)
