Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Very good point. An interesting thing to note is that some NES games also "run" at 30 fps (the game only updates memory every other frame), such as Solstice. Perhaps this should be taken into consideration for these games too, although I guess it would have to be manually corrected.
The statistics engine indeed does not consider the FPS. The movie lengths on this site are indicates in seconds, not in frames, so statistics can only count "rerecord / second" (or minutes, or hours).
Which it does. I don't see there such thing as "rerecords / frame" being indicated. Am I mistaken?
Joined: 4/8/2005
Posts: 1573
Location: Gone for a year, just for varietyyyyyyyyy!!
Yeah, there's probably too much work to do it manually. Some games even have in-game changes, like Genesis Gods, which behaves like a 30 fps game during the levels, but the shop cursor accepts faster input.
Yet another interesting approach might be to calculate the rerecords per frames that accept input. Oh, actually, it would not work well...
A more interesting idea (though probably not practical at the moment) would be to calculate rerecords per frames that have active input. This would ignore frames that have no input present. It would give a very different top-10 list. For some games this method might give a better approximation of how dense the rerecords are during gameplay. You seldom need to retry level loading screens, cutscenes or other parts where you don't press any buttons, so if the game has lots of those, the rerecords seem not so dense. On the other hand, games with short load times are generally higher in the list. This results in some "error" in the statistics. Technically, there's nothing wrong with the current statistics, but there might be a better way of doing this. I can't think of any practical solution, though.
Well, these are trivial things, but sometimes trivial things are funny and funny things are never trivial.
Hey, for Super Metroid, it might even be interesting to calculate the rerecords per in-game time!
Joined: 4/8/2005
Posts: 1573
Location: Gone for a year, just for varietyyyyyyyyy!!
Yeah, maybe it is ok that way. It definitely works as a statistic. It just seems a bit strange to use a real-time time-unit in the division, because re-records have nothing to do with real-time. It is the input frames, which are re-recorded. That is the reason why I think 30 FPS movies (N64?) now get only 50% of their re-record density compared to 60 FPS movies. But maybe it is not worth the effort to implement the frame-specifications to the system.
Oh, here's a funny and somewhat related TASVideos FAQ quote: "Once upon a time, someone calculated that in a 11 minute movie that has been re-recorded 50000 times, a savestate has apparently been loaded on average 75 times per second. What is wrong with this figure?"
While I agree that some may think 50000 rerecords for 11 minutes is excessive, there can be many reasons for that thinking, and the FAQ doesn't really address that.
The FAQ may seem to indicate:
- People think that 50000 rerecords in 11 minutes means that a savestate has been loaded 75 times per real-time second, which is so ridiculous that to think people think that is in itself ridiculous.
- People assume that rerecord density is uniform (i.e. for 50000 rerecords in 11 minutes, a savestate has been pressed precisely (or even about) 75 times for each second of the movie. In actual fact, rerecord density is far from uniform.
In my opinion, what people actually think is that the 11-minute movie takes no more than a few days to make, which makes the 50000 rerecords seem excessive. If they knew that the movie would take, say, 6 months, then it wouldn't seem so excessive. It should be stated in the FAQ how long it generally takes for these projects.
The title of the section is: