It looks like 2.0 runs significantly slower than 1.2. for example, if you enter a time trial, and compare the game's timer with a stopwatch application, you should get something like this:

Turns out the time difference is about 6 seconds every 5 minutes. While I am unsure why exactly the game runs slower, I suspect it may have something to do with the framerate. When I was doing some sample video recording of version 2.0, I noticed that I would get a duplicate video frame once every 50 frames when recording at 30 fps (VVVVVV 1.2 has no duplicate frames at 30fps). I thought that perhaps the game was running at NTSC 29.97 fps but this only resulted in one duplicate frame every 54 frames. Then I noticed that under "nearest ms" heading of virtualdub (the capture program I use) there was an option of 29.41 fps, which incidentally enough seemed to be the exact framerate 2.0 was running at as my captures no longer had duplicate frames.

My hypothesis is that VVVVVV 2.0 runs the timer as if it were running at 30fps when in actuality it is running at 29.41 fps, thus causing a discrepancy in the timer. This correlates with observed data, as 29.41fps/30.00fps = .9801 and 306s(5min, 6s)/300s = .980.

So in fact version 2.0 is actually running at 98% the speed as version 1.2. while that doesn't seem much, the error really adds up over the course of a single play through.

It looks like 2.0 runs significantly slower than 1.2. for example, if you enter a time trial, and compare the game's timer with a stopwatch application, you should get something like this:

Turns out the time difference is about 6 seconds every 5 minutes. While I am unsure why exactly the game runs slower, I suspect it may have something to do with the framerate. When I was doing some sample video recording of version 2.0, I noticed that I would get a duplicate video frame once every 50 frames when recording at 30 fps (VVVVVV 1.2 has no duplicate frames at 30fps). I thought that perhaps the game was running at NTSC 29.97 fps but this only resulted in one duplicate frame every 54 frames. Then I noticed that under "nearest ms" heading of virtualdub (the capture program I use) there was an option of 29.41 fps, which incidentally enough seemed to be the exact framerate 2.0 was running at as my captures no longer had duplicate frames.

My hypothesis is that VVVVVV 2.0 runs the timer as if it were running at 30fps when in actuality it is running at 29.41 fps, thus causing a discrepancy in the timer. This correlates with observed data, as 29.41fps/30.00fps = .9801 and 306s(5min, 6s)/300s = .980.

So in fact version 2.0 is actually running at 98% the speed as version 1.2. while that doesn't seem much, the error really adds up over the course of a single play through.

Um... why do you still have 2.0? Terry released the 2.1 patch long ago.

It looks like 2.0 runs significantly slower than 1.2. for example, if you enter a time trial, and compare the game's timer with a stopwatch application, you should get something like this:

Turns out the time difference is about 6 seconds every 5 minutes. While I am unsure why exactly the game runs slower, I suspect it may have something to do with the framerate. When I was doing some sample video recording of version 2.0, I noticed that I would get a duplicate video frame once every 50 frames when recording at 30 fps (VVVVVV 1.2 has no duplicate frames at 30fps). I thought that perhaps the game was running at NTSC 29.97 fps but this only resulted in one duplicate frame every 54 frames. Then I noticed that under "nearest ms" heading of virtualdub (the capture program I use) there was an option of 29.41 fps, which incidentally enough seemed to be the exact framerate 2.0 was running at as my captures no longer had duplicate frames.

My hypothesis is that VVVVVV 2.0 runs the timer as if it were running at 30fps when in actuality it is running at 29.41 fps, thus causing a discrepancy in the timer. This correlates with observed data, as 29.41fps/30.00fps = .9801 and 306s(5min, 6s)/300s = .980.

So in fact version 2.0 is actually running at 98% the speed as version 1.2. while that doesn't seem much, the error really adds up over the course of a single play through.

Um... why do you still have 2.0? Terry released the 2.1 patch long ago.

Wow thats very strange.

I've found the issue. Its a minuscule rounding error due to the locked framerate on flash vs C++.

We never spotted it because Terry and our testers can finish most areas in about 30 seconds. :p

I'll fix that now.

Edit: Ok in game timers are now based on ticks and super duper accurate. Update goes live tonight.

Moved this message from Beta 2.1.2 Pre-release testing thread to here and added the last bug on the list.

Few bugs found so far. Haven't tried anything else except changing the graphics options and playing 5 seconds of flip and normal mode.-Mouse cursor is still there.-Alt+entering to windowed and back to fullscreen still always uses the AUTO setting in fullscreen, even if I had used 640x480 before alt+entering.-Bringing up the map or the esc quit screen while playing in flip mode scrolls the map onto the screen a bit wrong. Only the right side of the map is visible on the left side of the screen while it scrolls, but when the scrolling ends it centers itself like it should, filling the whole screen. Seems to do this too only when fullscreen resolution is AUTO (1920x1080).-After alt+tabbing from fullscreen vvvvvv to desktop and back, whenever I press enter in game it (alt+enters) changes from fullscreen to windowed.-In the graphic options when enabling/disabling opengl (by pressing space) the arrow keys wont do anything until I press space a second time after the mode has changed.-First and last columns of pixels sometimes freeze when it does the flashing&shaking (like using a teleporter or changing to and from flip mode in the menus). It does this to me only when my resolution was set to AUTO and not when using the 640, 800 or 1024 resolutions. Picture related. http://imageshack.us/photo/my-images/205/77759784.png-Sprites change color when near the screen borders in flip mode. Picture related. http://imageshack.us/photo/my-images/43/77646092.png

Moved this message from Beta 2.1.2 Pre-release testing thread to here and added the last bug on the list.

Few bugs found so far. Haven't tried anything else except changing the graphics options and playing 5 seconds of flip and normal mode.-Mouse cursor is still there.-Alt+entering to windowed and back to fullscreen still always uses the AUTO setting in fullscreen, even if I had used 640x480 before alt+entering.-Bringing up the map or the esc quit screen while playing in flip mode scrolls the map onto the screen a bit wrong. Only the right side of the map is visible on the left side of the screen while it scrolls, but when the scrolling ends it centers itself like it should, filling the whole screen. Seems to do this too only when fullscreen resolution is AUTO (1920x1080).-After alt+tabbing from fullscreen vvvvvv to desktop and back, whenever I press enter in game it (alt+enters) changes from fullscreen to windowed.-In the graphic options when enabling/disabling opengl (by pressing space) the arrow keys wont do anything until I press space a second time after the mode has changed.-First and last columns of pixels sometimes freeze when it does the flashing&shaking (like using a teleporter or changing to and from flip mode in the menus). It does this to me only when my resolution was set to AUTO and not when using the 640, 800 or 1024 resolutions. Picture related. http://imageshack.us/photo/my-images/205/77759784.png-Sprites change color when near the screen borders in flip mode. Picture related. http://imageshack.us/photo/my-images/43/77646092.png