The SML2 TAS I submitted yesterday has
7740 frames on emulator (2 minutes 9.5885479887824 seconds),
~7978 frames in recorded AVI (2 minutes 13.5733121259052 seconds).
This is because some lagframes throughout the TAS take longer than the duration of 1 normal frame, ~0.016 seconds. The recorded AVI accounts for that and records multiple frames in place of one. This also seems to be why TASes on Youtube end later than they are supposed to, time-wise.
Yet, the submission time says 2:08.98. Why aren't lagframes accounted for in submissions and publications' times? Also, why isn't it 2:09.59? I used framerate 59.7275 (taken from here). 2:08.98 would mean the framerate used for calculation was 60.
Dolphin currently has a related problem. Recorded AVIs don't account for lag (as far as I know, a recent revision fixed it for Direct3d11 (?), so recorded AVIs that use Direct3d11(?) add multiple frames in the place of 1 lagframe). Should future gamecube TASes have those miscalculated times too? It would mean that times would be many seconds lower than they actually are.
The SML2 TAS I submitted yesterday has
7740 frames on emulator (2 minutes 9.5885479887824 seconds),
~7978 frames in recorded AVI (2 minutes 13.5733121259052 seconds).
This is because some lagframes throughout the TAS take longer than the duration of 1 normal frame, ~0.016 seconds. The recorded AVI accounts for that and records multiple frames in place of one. This also seems to be why TASes on Youtube end later than they are supposed to, time-wise.
It was a bug with LCD on/off in the old GB core and somehow fixed in the v20-v24 versions.
The frame rate used in VBA-RR is 60.000000000000000000000....
EDIT: Perhaps we should require future GB/SGB/GBC movies to be TASed with v24 or newer.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
That would mean lagframes are not accounted for. Isn't that the wrong way to go? Times in submissions and publications would be inaccurate.
Why aren't we using the console-based frame rates? Is it just a special case with VBA? Because Desmume does record AVIs using 59.826 fps, at least in 0.9.2~0.9.4.
Also I added info about Dophin to my first post since you posted.
Technically speaking, wrong. The fact is, there is no video frame during the "lagged while screen period", because the LCD is turned off by the game. And that is to say, "video frame length" is variable in GB games. Since we currently record input on video frame boundaries and we don't record how long every frame lasts, we are unable to represent the exact length of the gameplay in movie files. Shall we switch to time-stamp-based input recording like as openMSX does?
MUGG wrote:
Isn't that the wrong way to go? Times in submissions and publications would be inaccurate.
That's why I bothered to resurrect and fix the old buggy v20 and then upgraded it to v24. In v20-v24, the emulator simulates white-blank video frames even when the LCD is turned off. That is technically hacking, but it generates better results.
MUGG wrote:
Why aren't we using the console-based frame rates? Is it just a special case with VBA? Because Desmume does record AVIs using 59.826 fps, at least in 0.9.2~0.9.4.
I don't know. It has been in this way for years. Perhaps because inaccurate lag emulation would weight over such a small difference.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
The site uses 60.0 fps for gameboy. The policy of the site has traditionally been to use whatever the emulator emulates at. Does VBA not emulate at 60fps?
Desmume emulates at 59.826 fps (more specifically it runs at 33513982.0/6/355/263 fps) and so the site reports that fps.
Personally I think we should calculate movies based on the console fps even if the emulator fails to run at said fps (for instance SNES is ~60.98 just like the NES but SNES9x runs at 60 fps).
As far as emulating the machine being "off", that kind of is outside the scope of what we can do. Hacking it to be blank frames is a hack but at least it approximates the results well. I'm not too concerned with that issue then. All options produce only an approximate result and all choices result is approximately the same reported time.
Last time this came up byuu said 315/88*6000000 / 1364 / 262, which is 60.098477556112263192919547153838.
315/88*6000000 = 21477272.72(72...) is the master clock frequency, 1364 is the number of master clock cycles per scanline, 262 is the number of scanlines per frame.
EDIT: Perhaps we should require future GB/SGB/GBC movies to be TASed with v24 or newer.
Will it be enforced? I think something like this has happened to Snes9x v1.51, but it seems not much people cared, as some runs are still made in Snes9x v1.43.
Last time this came up byuu said 315/88*6000000 / 1364 / 262, which is 60.098477556112263192919547153838.
I just redid the analysis, and I get the following (for NTSC, accuracy core):
ppu::scanline() with vcounter()=0 is called 357368 or 357364 PPU cycles (it alternates between these two) apart.
PPU clock frequency looks to be equal to CPU clock frequency, that is, 21477272Hz (NTSC). From this, one obtains frame rate of:
21477272Hz/(357364+357368)*2 = 10738636/178683 Hz.
Which is exactly equal to figure I gave before (IIRC, I locked the measurement to CPU that time, locking it to PPU gives much cleaner values).
Doing the same thing for PAL (again, accuracy core):
ppu::scanline() / vcounter()=0 interval: 425568 (doesn't alternate this time).
CPU/PPU clock for PAL: 21281370Hz.
=> 21281370Hz / 425568 = 322445/6448 Hz.
Again exactly matching the figure I gave earlier.
Edit: These figures are the same with compatibility core.
Edit #2: I think I figured out where the difference in these two figures comes from:
There are 1364 clocks per line, except if all of the following are true:
- NTSC region is active
- Interlace (448/478 high output) is off.
- Vcounter is 240.
- Field is odd.
In that special case there is only 1360 clocks on line.
This causes every other frame to take 4 cycles less, and this explains most of the difference (the remainder is explained by the fact that the clock frequency is 21477272Hz and not 315 / 88 * 6MHz).
Edit #3: PAL interval 425568 = 1364 * 312 (312 scanlines, 1364 clocks each).
Joined: 10/27/2004
Posts: 1978
Location: Making an escape
adelikat wrote:
The site uses 60.0 fps for gameboy. The policy of the site has traditionally been to use whatever the emulator emulates at. Does VBA not emulate at 60fps?
I have no idea what the newer ones are like, but I know the older ones had some issues. Yes, VBA uses 60 FPS, except some frames last longer than others. For instance, load up my Daikatana run in the VBA it was recorded in and watch the frame counter. Right before the title screen, you'll see the frame counter pause for nearly a second before continuing on, but the music is still playing. In other words, that "frame" was one second long, while others were 1/60th of a second long.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
I don't think lag frames are the boogeyman here, just "Screen Off" frames. When the screen is off, there's no vblank interrupt or vsync, and the screen can turn back on at ANY time, and it will immediately begin the next frame.
This is significant because other systems like the NES keep the video counters running with the screen off, and you still get periodic vblank interrupts. Then you turn the screen back on during vblank time, so the next frame displays properly. But not on the gameboy. The screen can be turned on at any time, so what would otherwise be the middle of the frame suddenly becomes the start of the frame.
The only accurate way to time GB videos is to count total cycles executed, or measure Screen-Off frames in fractional units.
The site uses 60.0 fps for gameboy. The policy of the site has traditionally been to use whatever the emulator emulates at. Does VBA not emulate at 60fps?
Not quite, it expects to emulate at 60 fps, but not always does so. VBA achieves its 100% speed by controlling the sound, not the video (i.e, it'll resample the sound to twice the frequency if you select x2 speed). That's why the game will be emulated at the highest speed your PC can handle if you turn off the sound instead of muting it. The ROM can stop all sound circuitry, but it seems in those cases it'll output silence to the buffer anyway, whereas in no video frames it just doesn't render them. This used to cause massive audio desyncs in versions prior to rr, and I'm not sure how the AVI writer handles it now.
Even the emulator's core has trouble determining the speed, since it measures frame intervals. If you watch 1637M, whose encode is around two minutes larger than the vbm time, you'll see the speed dropping to 80% or even 70% when those larger frames pass. If one were to force it to run strictly at 60 fps, sound would be screwed up at those parts.
klmz wrote:
That's why I bothered to resurrect and fix the old buggy v20 and then upgraded it to v24. In v20-v24, the emulator simulates white-blank video frames even when the LCD is turned off. That is technically hacking, but it generates better results.
Might be solved only in v24, in v20 Pokémon Green has a frame of massive length, like what Ferret Warlord is describing. That TAS is the only one made in v20 that doesn't sync in v24, right? The reason might be just that.
