Screen refresh shows tearing unless vsync is forced by driver control

[GoogleCodeExporter]

Describe your system:
 - Operating System (be specific): Gentoo Linux (kernel 2.6.36-ck preemtive, BFS)
 - Machine type (32-bit or 64-bit): 32 bit kernel 
 - Mupen64Plus version: 1.99.4
 - Plugins used: Rice's Video Plugin, SDL_Audio plugin, SDL_Input plugin

For visual artifacts, give:
- game name and CRC/MD5 hash (printed on console)
Every game is affected

- description of the artifact (missing polygons, flashing, wrong colors,
etc)
Tearing

Describe the problem:

I think it would be very interesting to have an VSYNC option in the emulator 
core or Rice's OpenGL plugin. Nvidia driver just vsyncs blindly, so forcing 
vsync in the driver (via rc file or nvidia-settings) is not the way to go.
GlideN64 plugin seems to have this option, but it's ignored. Again, enabling 
vsync in the nvidia control panel does the job, but causes high cpu usage and 
desynced frames once in a while.

Please provide any additional information below.

SDLMAME (now on baseline MAME), E-UAE (now mantained as P-UAE for *NIX 
machines) and BSNES use proper vsync control in the emulator, not relaying in 
the driver setting.

Original issue reported on code.google.com by redwindw...@gmail.com on 1 Jan 2011 at 3:39

[GoogleCodeExporter]

Adding the following settings to every game in "RiceVideoLinux.ini" seems to 
resolve most of the flickering/tearing problem, though there are still some 
(different) tears, which you can mostly ignore:

ScreenUpdateSetting=2
MultiSampling=2

Original comment by myownlit...@gmail.com on 26 Feb 2011 at 8:39

[GoogleCodeExporter]

This was fixed by a new Rice-video option called "VerticalSync" introduced on 
April 9, 2011.  Can you please re-test using a fresh build from our mercurial 
repository, or v1.99.5 when it is released?

Original comment by richard...@gmail.com on 5 Mar 2012 at 3:46

• Changed state: Fixed