Well i went out and bought Bioshock since I got so enthralled by the demo. I didn't even know about this game until the demo surfaced.

At any rate, I have been marvelling at the graphics the whole time, thinking how wonderful it is that they manages such polish, with high framerates, AND no tearing.

Then...under the options I saw it. The ability to disable vsync. Just for the hell of it I tried and it was met with aweful tearing. The kind of tearing that other titles ship with, and force you to look at regardless.

Well kudos to 2K for this! You can actually enable and disable vsync. Games like Dirt, GRAW, RB6, amongst many other are nearly ruined for me when the tearing starts going. I'd gladly give up a few FPS for a better visual experience.

Maybe some other developers will follow suit...or maybe MS will allow "force vsync" under the dashboard, to override the in ga,e preference.

Saint's Row has VSYNC disabled by default and you can enable it, pretty much the same thing. But yes I fully support VSYNC options for ALL games!

I concur. Let us decide how we want our games to look.

ignorance here, but are you talking about the framerate option? Is that the "VSYNC" you allude to? I tried that smooth framerate option yesterday, and while it was amazingly silky smooth I noticed terrible tearing as well. Maybe we'll get to the point where we can get to smooth framerates and have no tearing at all!

I'm glad they included this as well. I didn't notice any hiccups while playing last night. Now Saints Row on the other had is horrible. If you enabled VSYNC is had horrible framerates. Glad this isn't an issue with Bioshock.

what is VSYNC

I could google it.. but you guys like to type anyways.. :0)

Yes typing is fun!

Baically it locks the framerate to a divisor of your screen refresh rate (60hz). So your framerate would always be 60, 30, 20, 15, 10, etc etc. This means the frame is always completely rendered before it is sent to the screen, eliminating tearing.

amazing that they get this right but can't nail down 16:9...

ignorance here, but are you talking about the framerate option? Is that the "VSYNC" you allude to? I tried that smooth framerate option yesterday, and while it was amazingly silky smooth I noticed terrible tearing as well. Maybe we'll get to the point where we can get to smooth framerates and have no tearing at all!


Can somebody answer this? Is this the same option? I think it defaults to OFF. Right?

This is a nice option. I tried it myself and saw no reason to not have Vsync enabled (the tearing without it was the worst I had ever seen, what do they call that option 'Lock Framerate' I think).

This made me wonder why you would want to turn off Vsync at all, then I rembered from my PC MP days that turning off Vsync does allow the view to react faster to player input which equals more kills.

I guess that's why the whole 'adaptive' framerate concept makes no sense to me. The problem here is that in an MP game like Gears of War or RB6, my 360 may have Vsync on my display at the same time that my oppent has Vsync disabled, allowing him to get the drop on me. You can actually tell when this happens in the game because it drops frames because the two machines are out of sync (one second you're alive, then a graphical stutter and the guy that was 10 feet from you is through you and you're done). Obviously network variables come into play there as well, but if two 360's are trying to sync their framerate over the internet there are obviously inherent issues for deathmatch type gameplay.

I think having the option is even more important for multiplayer. I want to enable Vsync for the single player story so I can look at the pretty pictures and I want to disable it for Multiplayer to maximize reaction time to what's happening on screen. Either that or have it always enabled or disabled so everyone is on the same playing field.

I totally hate tearing, for me probably the worst thing about NG.

This is a nice option. I tried it myself and saw no reason to not have Vsync enabled (the tearing without it was the worst I had ever seen, what do they call that option 'Lock Framerate' I think).

This made me wonder why you would want to turn off Vsync at all, then I rembered from my PC MP days that turning off Vsync does allow the view to react faster to player input which equals more kills.

I guess that's why the whole 'adaptive' framerate concept makes no sense to me. The problem here is that in an MP game like Gears of War or RB6, my 360 may have Vsync on my display at the same time that my oppent has Vsync disabled, allowing him to get the drop on me. You can actually tell when this happens in the game because it drops frames because the two machines are out of sync (one second you're alive, then a graphical stutter and the guy that was 10 feet from you is through you and you're done). Obviously network variables come into play there as well, but if two 360's are trying to sync their framerate over the internet there are obviously inherent issues for deathmatch type gameplay.

I think having the option is even more important for multiplayer. I want to enable Vsync for the single player story so I can look at the pretty pictures and I want to disable it for Multiplayer to maximize reaction time to what's happening on screen. Either that or have it always enabled or disabled so everyone is on the same playing field.

That Gears of War stuff is purely a network issue, it has nothing to do with vsync.

I was a hobbyst game programmer for quite a few years back when DOS was the OS of choice for games programmers.

As I remember Vsync, it worked like this (and since hardware has changed things might be a little different now):

1)
There was an area of addressable memory mapped to the video screen.
2)
Each memory location = 1 pixel on the screen.
3)
If the screen was in 8 bit mode then there would be a total of 256 possible values for each memory location (0 = Black 255 = White) hence this was 256 color mode.
4)
There was a special register on the Video Card that was called the Vertical Blank Indicator (or something like that)
5)
If the register was on (or off, can't remember which) it was safe to write to video memory because the data was not currently being drawn to the screen
6)
If you chose to ignore the VBI then you risked writing a new frame while the screen was in the middle of doing a refresh -the result being that the screen would be a mixture to two frames -hence the tearing.
7)
So the deal was this: If you wanted to write a game that ran at 60fps then you needed to ensure all your game processing was done within the 60hz window of oportunity. If your game was fast enough to manage that then the logic looked like this:
(a) Read input from user
(b) Apply game logic
(c) Check the VBI and wait until it was set then draw the new frame
(d) Go back to (a)

Obviously, if you missed the 60hz boat then your game (by definition) has to wait for the next VBI cycle, which means your game has now just become a 30hz game.

ps. this is why Tearing is not an issue related to performance -it is an issue related to synchronisation. No matter how fast the game runs, if it does not sync with the VBI then it risks mixing frames together. This would not be noticeable when things are largely stationary, but very noticeable if you do a quick pan.

pps. While I'm reliving the past..

This is where 8 bit vs 16 bit vs 32 bit became really important. If you were using a 32 bit CPU running in 32 bit mode then you could copy the data to the screen 32 bits at a time (as versus 8 or 16) which meant much better performance (half the number of instructions required to move the same amount of data). This is why the recent move to 64 bit O/S's offers the potential for big performance gains even though the CPU clock speed is the same as if it were running in 32 bit mode. You can move data around at twice the speed because you are working with 64 bit registers. It's like having a much bigger shovel.

I noticed Half Life 2 Lost Coast has a special 64 bit mode and I'm willing to bet that it does pretty much exactly what I said above, in as much as when it comes to moving data around, it does it using a full 64 bit register/memory moves.

While the industry seems reluctant to face the move to a 64 bit O/S (quoting lack of driver support) the faster we do it, the faster we will give developers the opportunity to fully utilize the hardware we own.

Good description Quidam67, I remember playing FEAR on the PC and finding around 30% framerate hit for turning on VSYNC. Interestingly, if you ever play PC games you can sometimes find that they have an advanced video setting called "enable triple buffering". The idea is to not make the game engine wait to be able to render a scene, so you can have VSYNC enabled with a reduced performance hit. The tradeoff made by the developer is giving up video memory for the extra buffer.

Yes, you are absolutely right. It's all coming back to me now!

It was entirely possible to split the graphics card memory into multiple buffers. Historically speaking, this was an option for lower resolution screen modes that did not need all of the available memory on the card, and in fact had enough memory to support 2 or more frame buffers.

There was a special register on the card that held the address of the frame buffer (start of the graphics memory). All you had to do was toggle the value of that address between the two buffers between each rendering cycle.

This meant your game could update the "off-line" buffer any time it wanted to (no waiting for the VBI) but it still needed to check the VBI before switching between the two buffers or else you could get 1/2 of buffer A then half of buffer B drawn on the screen, resulting in tearing again.

But things have changed so dramatically since the good old days where developers had direct access to the hardware.

Windows came along -and switched the Intel CPU's into "protected mode" which meant application software had to play by the rules, accessing all its functions via the Windows API -direct interaction with hardware was a no-no because the software would then be proprietary -which is the defintion of a device driver. That was when I kind of lost interest (in my hobby) because writing a Windows program simply wasn't fun. It just felt like hard-work and I'm basically allergic to hard-work.