Version 2: Report bugs here

Started by Terry, July 28, 2011, 03:15:02 AM

Previous topic - Next topic

PJBottomz

Quote from: Officer Captain on October 01, 2011, 03:49:16 AM
I think you need an empty line after your last script, sir.

... Shouldn't we wait until we see the script before we give him/her advice?

Officer Captain

#76
Well, if I've been having similar problems, and I had found a way to fix it, is it incorrect to try and share my findings?

You know what, don't answer that. Let's keep the thread going.

Buttons

Figured it out: don't end a line of dialogue with a colon, or the program will think it's a new script.

PJBottomz

Quote from: Buttons on October 01, 2011, 03:04:09 PM
Figured it out: don't end a line of dialogue with a colon, or the program will think it's a new script.

Oh yeah, that bug. *shudder*

robloxfan1999

 :verdigris: I got a bug! 1. Man that bug is just annoying me on VVVVVV so much!

Damn It AL to Hell

I have to say, these are very weird, I've only run into a couple myself, but not some that are so strange

Tranquilite

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.

Damn It AL to Hell

I am falling through some single tiles, is that supposed to happen? Oh, and there's no gray warp background.

PJBottomz

Quote from: Tranquilite on November 02, 2011, 08:33:24 AM
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.

Whirligig

Hey, I still have 2.0. Then again, it is because I'm on a Mac *cough cough*  :violet:

Tranquilite

Quote from: PJBottomz on November 14, 2011, 09:05:16 PM
Um... why do you still have 2.0? Terry released the 2.1 patch long ago.

I suppose i should have put 2.X as the behavior is the same in both 2.0 and 2.1.

xTwoTails

Click it, download it, extract to the VVVVVV folder and replace the .exe
Have fun gaming with a much smoother game we all love~ =3

http://distractionware.com/forum/index.php?topic=693.0

simoroth

#87
Quote from: PJBottomz on November 14, 2011, 09:05:16 PM
Quote from: Tranquilite on November 02, 2011, 08:33:24 AM
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. :D

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

starttimartti

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

My specs: W7 64bit pro, 1920x1080 screen, nvidia gtx260 with 275.33 drivers, Intel Q6600.

simoroth

Quote from: starttimartti on November 20, 2011, 08:20:44 AM
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

My specs: W7 64bit pro, 1920x1080 screen, nvidia gtx260 with 275.33 drivers, Intel Q6600.

Great thanks. The mouse thing is a constant irritation for me, it never works right. :p

The columns of colour either side of the autoscreen should clear, I'll put in some extra code just in case. The other problems should be fixed in the next release.

I'll try and see what's causing that flipmode thing.