I noticed that due to the double 5:55, a mod went and added milliseconds to all the runs in the LB.
The problem is that all of them were incorrect because they were just based on what livesplit was saying (sometimes when the text screen was shown (i noticed that in the case of Baruch at least), sometimes just when the timer was stopped like for me or the newer 5:55. In the first case, it didn't take into account the gap at the start, and in the case of the 2 other runs I mentioned, it didn't take into account the gap both at the start and at the end.
In short, do not add milliseconds unless the run was framecounted (we need to figure out a clear start & end point for that in fact) or unless there's an autosplitter out there that we could use (that would be great but there isn't one right now).
It's true that the new 5:55 is slightly faster and the LB should reflect that, but adding wrong/quite off milliseconds is not the answer.
Hi !
I am actually the one who asked one of the mods to add milliseconds in order to reflect, as you said it, the fact that my run was slightly faster than Baruch's. However, you made a very valid point regarding the exactitude of the added milliseconds.
In my opinion, there are two options. The first one is to framecount all the runs starting on the frame where the runnner press start on the title screen and ending on the frame on which Obelix and Idefix appear (that is actually written in the rules). The second one is to not add the milliseconds but look very carefully when two runs are close in order to rank them accordingly (in that case two runs could have the same time on the LB but would not be tied). I do not know how the leaderboard has been coded so maybe it is not possible for a mod to rank two runs differently when they have the same time in which case I guess I will have to submit a run in 5:54 :-) or you can also decide to start counting on a later frame in order to make my run a 5:54 and Baruch's still a 5:55.
What do you think ?
Hey o/
Maybe we can ask for future runs on emulator to :
- define what emulators are allowed
- display frame count and inputs
- reset between runs
- define a clear start and end
For now, I'm ok with having approximate milliseconds on Mad_Max's run and mine, in order to have a different ranking.
I'm 100% against approximate milliseconds personally. It's either accurate or we don't put them.
That being said it's not too late to framecount them as long as we define the start and the end properly and find out a consistent way. I assume you both still have local recordings so once a method is established, the framecount can be done in a breeze (if needed I'll do it myself if you don't have virtualdub and all but it's not hard to get). When the video is on Youtube, you can pretty much reach a close answer too by using the frame advance tool that Youtube has combined with the timer but that should be mostly used as a confirmation or a last resort and not the main method. Even if you don't have a local recording, downloading the video from twitch and using it as such should do the trick (btw i hope you recorded at 60 fps because that's the most accurate, but if you recorded at 30 it's not the end of the world).
Also we don't need to add milliseconds to every run, we can do it under a certain treshold like in LBs such as SMB1 (or 3 in two categories). For example right now, only the top 2 or top 3 would need milliseconds really, and then every new run that beats a run that already has milliseconds (or is within the same second) needs milliseconds itself as a rule, something like that?
For the end frame, simply using the first frame of the text saying you rescued Obelix or whatnot would be perfect imo as you said. Easy to locate and matches what we were aiming for when stopping the time basically.
The start frame is slightly trickier to locate usually, would need to be tested quickly in an emulator (by frame advancing and all from the start input) to see if the duration between start & gameplay is consistent (that's not necessarily the case). And see if we can find a clear visual cue that would help us locate the start input (the start input has no cue itself if i'm not mistaken but maybe the title screen disappears consistently like always the same number of frames after you press start). So for example if the title screen always disappears 5 frames after (number thrown randomly), we can first locate that disappearing frame, and then go back 5 frames to locate the start.
It sounds like a hassle at first but believe me, once a method is established and agreed upon, it's then done incredibly quickly when needed and is much more reliable & convenient than any alternative.
Ok, it sounds pretty good to me. I think we all agree that the end frame is the one with Obelix and Idefix with the rescue message. As regards the start frame, I took a look at several recordings in VirtualDub and it turns out that the first black frame (the menu disappears and the screen becomes black) after you press start could be a good candidate.
Indeed, I noticed that the gap between the first black frame and the first level 1-1 frame is always 18 meaning that the black frame is number 1 and the level 1-1 frame is number 19. I forgot to mention that my recordings were done at 30 FPS (sorry, I will change that for future recordings).
Therefore, I used those frames to calculate a more precise time for my 5:55 run. The first frame is the 451st and the last one is the 11111st. So the real number of frames for this run is N = 11111 - 451 + 1 = 10661 frames. As I mentioned earlier, I recorded at 30 FPS, thus the time for this run is T = 10661/30 = 5:55.367
Maybe you can double check for the start frame so we can be completely sure and if it is validated by you then Baruch can do the calculation to get his time with millisecond precision.
How does that sound ?
Yeah I can definitely also have a look (and I'd like to) but if that's alright with you, can it wait this week-end? I'm quite busy until then but I promise to do it this week-end without fail (might even be able to on friday).
Yeah man it's cool. Don't worry there is no hurry, I am just happy that we are doing things properly. By the way, I appreciate your reactivity on this subject and the fact that you cared enough to seek a satisfying solution. I would also like to point out Baruch's fairplay because he could have been against the all thing but on the contrary he is willing to help improving the ranking system as well.
I agree with displaying milliseconds only under a certain threshold (5.55 I guess).
Unfortunately I have no local recording of my run. Your recommendation is to download from twitch and use virtualdub ? Never used it but I will try.
Alright so a bit late but here we go, here's a short album, followed by my explanations. The explanations might seem confusing at first but I'll summarize the idea & the method at the end. All the values I'm gonna give are for 60 fps but i'll talk about what should we do with 30 fps recordings after (in the future please use 60 if possible).
After pausing the emulator (screenshot i called frame -1), i buffered the A press, and frame advanced. So on frame 0 (i call it 0 because i like how the number of frames after that visualizes directly the duration but you can call it frame 1 if you prefer, it just has different implications) the input is registered, that frame 0 is the start of the run (and the one we should use when framecounting runs imo, there's no sense in measuring the time from a later cue because we should really time from the very first input on the title screen).
Consistently (I checked if it was always the same) the screen will be black after a duration of 3 frames (frame 3 in the screenshots). That frame is easy to find with vdub to time it precisely so we should use it.
A common confusion is which frames to include in the calculations, if we have to add one extra after doing a substraction etc. The short answer is that you use the frame of the final cue and the frame of when the first input is registered in your calculation and you do nothing else. Imagine the last frame as a barrier, as soon as you see it the run is done and anything beyond the barrier is not part of the run (so the point is you don't want to include the duration of that frame itself). In the screenshots I posted, the duration would be 4 frames and not 3 if we included the duration of the black frame itself, but it becomes black after a duration of 3 and not 4. Anyway that's a really convoluted way to explain (and I don't even know if it was needed) but basically just substract the two values you found in vdub.
As a reminder, we said that the last frame was "Bravo! Tu as retrouvé Obelix" or w/e it is in other languages.
--------> LET'S TAKE AN EXAMPLE
You just got a run and are retiming it in vdub (the video is recorded at 60 fps flat). The black screen after the start input happens on frame 56447 in vdub. The Bravo! screen happens on frame 78012.
56447 - 3 = 56444 , that's your "frame 0" or when your input to start the run was registered 78012 - 56444 = 21568 , that's your run duration in frames (at 60 fps flat) 21568 / 60 = 359.4666666... , run time in seconds (divided by 60 as it's the speed of the recording, obviously you divide by 30 if your video is at 30 fps)
Which gives us an official time of 5:59.466 (and not 467 as we round down times in speedrunning typically).
--------> WHAT ABOUT 30 FPS VIDEOS
Alright so that's a small pain (please do 60 if possible), particularly because the black screen cue is after 3 frames, which can't be divided by 2 to have a full number of frames.
Basically, from the black screen, you'll have to substract 2 frames to find your first one (you'll overshoot the start by an invisible half frame though (when i say half frame i mean at 30 fps)). If you substract only 1 frame you're gonna have a final time faster than it actually was. In theory we could substract 1.5 frame but we'll have a run duration in frames that won't be a round number, which is really silly. Timing should be based on the concrete footage available I think.
--> Quick example at 30 fps: Black frame at 21028 Bravo! at 31858
21028 - 2 = 21026 , frame 0 31858 - 21026 = 10832 , run duration (30 fps) 10832 / 30 = 361.0666666666...
Official run time: 6:01.066
In theory we could also at this point substract from that total 1 frame at 60 fps of duration knowing that we overshot the start by that (or for example do it before the division: (10832 x 2 - 1)/60 -> 6:01.050, which matches the difference of 0.01666.. or 1/60) . Although I'm personally usually more inclined to really stick to the number of frames of the video (and encourage people to use adequate fps), I'm not particularly against the idea either and it's definitely not unreasonable so I'll see what you think of it.
So yeah, quite a long and convoluted post but gimme your feedback about all that, what do you think?
I think you found a reliable way to get a total number of frames that represents well the run. As I mentioned previously, I recorded my 5:55 run at 30 FPS (I changed this since then), therefore using your method, my frame 0 is f0= 451 - 2 = 449. Moreover, The last frame of the run is frame number 11111. So we get the following number of frames for this run: N = 11111 - 449 = 10662 frames, which gives us the official run time: T = 10662/30 = 5:55.400
From now on, I will include this calculation in the description when I submit a run and the recording will be at 60 FPS :-) (I am about to submit a run in 5:54 by the way).
Finally, I would like to thank you for taking the time to find that method and I wish you and Baruch a merry Christmas.
Grats on your runs!
I forgot to mention something important in relation to framecounting: checking that the recording didn't have any frame dropped. OBS tells you if frames were dropped, but on top of that it's not too difficult to check after the fact if you didn't look or just don't know.
What you can do after you calculate the final time based on the number of frames (if you're not sure if frames were dropped i mean) is compare what you found with what the timer would be if you started and stopped perfectly the splits. For example if you see on your recording that you started your timer 3 frames late, and you stopped it 3 frames early, it means that the final time on your splits should be lower than what you calculated by 6 frames or 0.100s. Of course there's sometimes small rounding inaccuracies with the timer (which is why we framecount to begin with) so as long as it's within like a 1 or 2 frames margin it should be fine. If there's a big discrepancy though you know your recording is missing some frames.
I actually checked for your two 5:54s and both of them matched perfectly in that regard so no frame was dropped.
Thanks, it sure took me many tries to get to 5:54 since I started running this game. Besides the difficulty level, the hardest thing to handle is the lagging. For some reason, it tends to happen at critical moments like in the middle of a jump for instance and sadly it is not always possible to reduce it effectively.
Anyway, I was not aware of the frame dropping issue you described and I will be sure to pay attention to that for my future runs. Generally speaking, you gave me an efficient method to framecount my runs and I will use it from now on, so thank you.
By the way, do you still run a few games from time to time or did you kind of retire from speedrunning ?
Right now I'm inactive but I'll most likely do a few small things with speedrunning next year. I'm considering playing Asterix again at some point in fact (for like a week or two, don't have the time for long grinds like what i did with smb3).
So you are going to play Asterix again after all :-) It is good to read that you will be back speedrunning (a little) in 2019, eventhough this means that my Asterix record is in big trouble...
Well, I guess I will see you around. Have a good one !
Congratz Max :)
What video file format are you using ? I record using OBS, but it seems that virtualdub can't read flv or mp4 :(
Thanks Baruch !
I am using OBS to record my runs (just like you do) and the output file is in mp4 format. This format is not handled natively by VirtualDub, so you need to add some plugins to make it work.
Here is a link where you can download the plugins you need to open mp4 files with VirtualDub:
https://sourceforge.net/projects/virtualdubffmpeginputplugin/files/latest/download
You will download a ZIP file which contains two directories: "plugins32" and "plugins64". You need to put those directories and their content in the VirtualDub directory and then you should be able to open mp4 files.
Once you have your recording in VirtualDub you can move back and forward frame by frame using the left and right arrows of your keyboard.
