Double and Triple Buffering do not work.

I'm available to test out special builds etc. that attempt to resolve this problem. Just contact me via PM or MSN Messenger.

I really want to see this fixed as I'm extremely sensitive to screen tear and this really sours any motivation to play quests :/

The way it works is this: If doublebuffer if forced (doublebuffer = 1) then it always will take precedence. Else if triplebuffer = 1, then it will always try and check if it can be used, but may fall back to double buffering if it can't. If there is no preference then it may use whatever is best.

Does screen tearing occur in fullscreen also? What is your refresh rate?

yeah and I play at 640x480, sbig=1 and it occurs fullscreen and windowed. Is there maybe something in the allegro.log that can be of help?

Edit: Log file specifically states "Triplebuffer not available" but doesn't mention anything about vsync/double buffer.

With Release Candidate 3 there is still a problem with Triple Buffer/Vsync not working in Fullscreen or Windowed mode. You won't notice it in Windowed mode under Vista or Windows 7 if Aero is enabled due to how Aero handles the display.

I also noticed the program doesn't match my desktop refresh rate, opting to run at 75hz instead of 60hz.

Edit: Due to there being no Vsync, the program exhibits excessive and highly noticeable screen tear. This leads me to believe it is also failing to enable Double Buffering but without any log information about that I can't say for sure or not that double buffering is working or working but not as intended.

Double Buffering appears to work fine in Windows 8 Consumer Preview (No screen tear) but still no triple buffer.

Does setting disable_vsync = 1 in the [graphics] section of ag.cfg change anything one way or another?

Try this: http://www.mediafire.com/?w46zwndew44889p
It's surely got other issues, but does it at least fix the screen tearing? You'll probably need to run it with FPS uncapped.

I assume you want the frame Rate Limiter disabled so as to produce a more pronounced effect more quickly, speeding up my testing process? Good idea as the game won't run ballistically fast if Vsync is working.

For all tests Double Buffer and Triple Buffer are both enabled (Set to 1), resolution is at 640x480 and colour depth is at 8.

1) The disable_vsync = 1 setting doesn't have any impact when set to 0 or 1 regardless of EXE used.
2) The original games EXE file runs extremely fast in both Windowed and Fullscreen modes.
3) Your custom EXE runs blazing fast in Fullscreen mode but runs at 60FPS (My refresh rate) in Windwoed mode. Vsync is functional in Windowed mode with this EXE file even at custom resolutions like 1280x960.

All right, about what I expected. It's not quite a perfect solution, since I know some people use F1 or ~ just to speed up the game here and there, and that won't work with this enabled... I guess I'll add an option for it in ag.cfg. I don't have a better idea at the moment.

Better then nothing at least, especially with the game now scaling up the graphics to fit larger resolutions.

I'd like to point out that it still doesn't work at all if using Aero basic or have the DWM disabled under Windows 7. Having it work under such circumstances would be perfect as the DWM causes intermittent stutter for me (A general problem that affects numerous programs on my PC).

If you can't fix the stutter when running the game with Aero disabled, then I'll just Dual Boot with Windows XP which surprisingly has no problems running applications that don't use an exclusive display mode.

I'm not sure what more we can do for those cases... Have you tried messing with application-specific video settings? That's about all I can think of right now.

I'm unsure if you read it but I previously mentioned this would eliminate the problems with vsync and Aero, however the guy there made a few mistakes when writing up that post (The biggest being that the feature is called DwmFlush() and not FlushDWM()). A less detailed description of what causes it as well as improved information on how to fix it can be found here.

I am not very good with words, especially when it comes to technical stuff. I have a problem with Vsync and how it works with Aero. I believe the common factor between affected applications on my computer is that it only affects applications that don't use an exclusive display mode as it affects numerous indy games and media players but few if any, fullscreen gaming applications. A fresh install of Windows 7 x64 eliminates the problem from being software (Driver, virus, improperly setup security software etc.) related.

Information about my problem can be viewed here and up to date information on how to resolve it is available here.

That's what I used. Thing is, anything more than a very basic implementation is difficult in ZC because there's no separate paint thread. If we sit too long waiting for vblank, that holds up the game logic.

Thanks for at least trying to resolve the problem that I experience. Is there a reason Vsync fails when Aero is disabled regardless of the exe version used?

I've had recent success in another program of mine by switching it to OpenGL mode, that resolved the problems I was having with DirectDraw and Direct3D such as stutter, completely.

Do older versions of ZC w/vsync have this problem for you? I noticed that vsync has been removed in the current version, not sure why. It tends to use all but a little of a CPU core when enabled but if it fixes tearing on some cards I think we can enable it again at least as a config file option.

I always assumed that the Cap FPS option was vsync renamed. I didn't think it would be replaced with a frame rate limiter, is that what you're implying? That the Vsync functionality was replaced with a FPS limiter?

Now that I think of it, it better explains my prior test results as I was working under the assumption that Vsync was simply renamed to Cap FPS.

franpa wrote:Thanks for at least trying to resolve the problem that I experience. Is there a reason Vsync fails when Aero is disabled regardless of the exe version used?

franpa wrote:I assume you want the frame Rate Limiter disabled so as to produce a more pronounced effect more quickly, speeding up my testing process? Good idea as the game won't run ballistic fast if Vsync is working.

For all tests Double Buffer and Triple Buffer are both enabled (Set to 1), resolution is at 640x480 and colour depth is at 8.

1) The disable_vsync = 1 setting doesn't have any impact when set to 0 or 1 regardless of EXE used.
2) The original games EXE file runs extremely fast in both Windowed and Fullscreen modes.
3) Your custom EXE runs blazing fast in Fullscreen mode but runs at 60FPS (My refresh rate) in Windowed mode. Vsync is functional in Windowed mode with this EXE file even at custom resolutions like 1280x960.

With regards to full screen, the game uses an exclusive full screen display mode and such a display mode prevents the Windows Vista/7 compositor from interacting with it and managing Vsync, hence why it always ran at max speed regardless of the configuration settings I changed, it also explains why vsync fails in the exclusive full screen display mode with the version of the exe you provide in post #8.

With regards to windowed behavior while the compositor is inactive, the lack of support for vsync built in to the game is obvious.

With regards to windowed behavior while the compositor is active, I never really paid much attention to it but the original release candidate 3 exe file ignores the compositors vsync capabilities and continues to run blazing fast when the compositor is enabled. However the exe you provide in post #8 does take advantage of the compositor handling vsync for it (The compositor is shit at handling vsync though, at least on my system it likes to generate random stutter).

If you were to re-implement vsync functionality then both full screen mode and windowed mode (With the compositor disabled for windowed mode) should work perfectly and allow me to avoid ever having to experience how the game interacts with the compositor, again (A good thing.). If you do want me to still test an older version of the game to test my current line of thought then I shall, do you have any idea of how far back I should go to test? 100 builds?

Hmm.. Saffith did add the relative DWM code you suggested. For the vsync code I don't know that it worked in older builds now that I think of it...

Lets try the simplest option here first: What I will do is re add the vsync option to zc with a keyboard shortcut to toggle it on/off while ZC is running, then we'll take it from there.

franpa, do you get the same problems with tearing running ZQuest also?

How would I test it in Zquest? Fill the screen with animations? I do notice the animations don't seem to be capped at 60fps.

Currently in Release Candidate 5 vsync appears to be working great (In Fullscreen). The log file even reports Triple Buffering Available. I'm unsure if this is because of a change made to ZC or a side effect of using newer display drivers but yeah, smooth as silk here in fullscreen without screen tear.

Great. Glad to hear the new vsync option fixes your tearing issues.

I'll just move this to exterminated then.

I noticed that setting Double Buffer and Triple Buffer settings in ag.cfg to a value of 1 will result in allegro.log reporting that Triple buffering isn't available. Yet when I leave the values at 0 then allegro.log will report Triple buffering as available.

Also setting them to 1 makes the game run at double speed.even when Cap FPS is enabled.