CBright wrote:Tommy wrote:rawvf contains mouse events and a unique identifier for the clone that the video was made on (or a group of compatible clones - arbiter43, arbiter44, clone 97, clone20x, for instance).
Now, this raises the question: do we want special clone-specific video players? Personally, I think we have some right to declare any click processing discrepancy with the original as bugs (excepting the original's bugs).
I actually think we have to accept all behaviour clones produce/have produced. Consider what arbiter did before .43 - that ís definetly not acceptable by your definition. Yes, games making use of that did not count for highscores. But, for instance, an old highscore of mine*, played on a more recent version of arbiter, would have been a blast (in the last couple of seconds too) if I'd played it on arbiter43. There is no way to represent a blast like this if we assume that there is only one acceptable behaviour given a "stream" of mouse events. There may be real old arbiter videos of interest that suffer from this.
* (it can be found here
http://www.youtube.com/watch?v=qqWOjsmwA50, and I'm not sure, but I guess this
http://minesweeper.cc/uploaded/videos/T ... _42.16.avf is the correct avf)
CBright wrote:
Tommy wrote:
1.) It seperates the converter and the video player, making the whole process less bug-prone
But any bugs caused by the converter will be preserved to disk, and might not be evident to a video player. Better to distribute the click processing rules and let video players follow them than to follow board events for which there is no guarantee they weren't generated by faulty click processing rules.
I think basically you've reinvented *.rmv, except as text based rather than binary. Of course that's fine, but at least rawvf solved a pressing problem.
...
They shouldn't be evident to the video player IMO - the video player can be a dumb terminal. Or, of course perform analysis on the video, maybe to find flaws in click handling behaviour of different clones. Or whatever, you get the picture. This also opens the door to viewing videos produced by "lucky mode" clones, for instance. Or in general, varieties that don't adhere to the classic minesweeper rules. What if we are talking about a version that uses input methods other than a mouse? Somehow hacking together mouse events that do the same might work, but a stream of board events is a more accurate representation of what happened (and the video won't look stupid in implementations that are not aware that no mouse was used, and display a cursor haphhazardly and irritatingly jumping across the board, for example).
And yup, this is very close to a 1:1 text impementation of rmv.
About bugs being preserved on disk - sure, but how severe can they get? Basically, we are talking about a display glitch (since text-based video formats will never be authoritative anyway). In the beginning, some converters might produce imperfect output, and the worst case is that a couple of not entirely consistent videos remain online somewhere (If the videos are unusable, they will either be replaced or deleted).
Don't anthropomorphize computers - they don't like it.