Essay on Vertical Tearing and Jerking

I wrote this essay this morning to help people understand what is going on, and to help me clarify my research. Please feel free to comment and offer your opinions as fresh ideas are always welcome :-)


Vertical Tearing:
- Caused by the VDU scanline updating the same portion of the screen that you (or the video card) are currently drawing to.
- Normally the best way to avoid this is to do all the drawing when the scanline is off the screen, and this can be achieved by synchronising the flipping of buffers with the monitor's refresh rate. This is called “Waiting for Vertical Synchronisation”.
- However *some* video cards don't seem to support “Wait for VSync”. Also some cards/drivers allow you to turn off this capability full stop, which some 3D gamers do so that they can have the fastest possible framerates in their games, even though they experience tearing.
- If the card is waiting for VSync but the flipping of buffers (drawing) takes too long, the scanline will have already started updating screen whilst the flip is still going on. This sort of problem often results in a more or less stationary tear near the top of the screen (or further down on slower video cards.)
- Even though TFTs are supposed to be “progressive scan”, i.e. only updating the portions of the screen that have changed, scanlines and vertical tearing can be seen on nearly all of them, especially older models! (OK this thing about progressive scan is total bull, please ignore it)
- Tearing is most obvious on fast horizontally moving sprites. It looks like the sprite is cut in half horizontally and the two halfs are drawn as if one has been dragged left and one has been dragged right.
- You can also see vertical tearing on fast vertically moving sprites, but what happens is it looks like the sprite has been stretched vertically.
- Some vertical tearing is "clean" i.e. just one tear, and some tearing is ragged, which can really mess the sprites up.
- Also sometimes the tear stays in the same place on the screen, and
other times it can appear to move up or down the screen.
- Tearing can make the sprites look like they are "jerking", even though they are actually moving smoothly in Video RAM.
- Tearing is not so much of an issue for slow moving or small sprites, or puzzle games without much movement. It mainly affects scrolling games and action games with many large sprites.


BlitzMax Flip:
- The following observations are based on DirectX. OpenGL has slightly better results in windowed mode.
- In full-screen mode Flip 0 gives vertical tearing, which is to be expected.
- In full-screen mode Flip –1 and 1 seem to give no tearing on my PC and many others. However, some people still see vertical tearing with Flip –1 or 1.
- In windowed mode (not using MaxGUI) ALL the flags give vertical tearing on ALL systems because the Flip is not synchronised in any way to VSync.
- The tearing in windowed mode can be reduced by calling Graphics() with the same Hz as the desktop. This normally results in a single stationary tear, that can be at a different height every time the app is run (because although the HZ are the same, the flip is not waiting for VSync - it may occur at any point during the frame). Some people still see a moving tear with this technique, however.
- A better solution was put forward by Skidracer. This is a DirectX module tweak that forces windowed mode to wait for VSync before flipping. This works perfectly on some systems, on others it seems to result in a tear at the same place on the screen (flip takes too long or driver is reporting VSync at the wrong time), and others still have random tearing (their cards/drivers must not be able to return a valid VSync value at all).


Jerking:
- It’s important to know the difference between smooth sprites jerking due to dropped frames, and vertical tearing - which is not the same at all.
- Also it’s important to separate a “large step value” from jerking. For example, if an object is moving at 5 pixels per frame, it may look smooth. If the framerate drops by exactly half, the logic will keep the object moving at the same speed real-time, thus it will move at 10 pixels per frame. This is a larger step value (at a lower frame rate), and may appear jerky to the untrained eye. In fact, the object is moving constantly and smoothly but is simply being updated less often.
- Jerking occurs when one or more frames are not drawn and then the fixed logic/delta timing makes the sprites catch up. So the eye sees a stationary sprite for a fraction too long, then it has moved several frames worth in one go, giving a jerking effect. This will affect ALL sprites on the screen, but it should be noted that it’s much more noticeable on fast moving sprites! Also note that if this sort of thing occurs in a 3D game, it is much less noticeable, but can still be annoying if it’s frequent enough, for example when new media loads on-the-fly.
- If there was no timing code in place and the objects moved a set amount per frame, when frames were dropped, the object would appear to slow down momentarily and it would never catch up. Thus, over time it would not travel the same distance as it would if the game maintained a constant framerate. This is why timing code (logic or delta) is SO important!


What causes jerking?
- So far I’ve come up with two main reasons:

1) One reason is simply that background windows tasks are interfering with the game, and thus the game is losing valuable CPU/Rendering time and thus frames are dropped.
o If the game has an FPS counter you would see it dip occasionally as frames are dropped. The jerks occur as the framerate returns to normal, like the sprites are on elastic, and they snap back into position.
o Some systems have a lot more background tasks going on than others and thus see more jerks.
o Playing music and sound effects may also have an effect.
o Also I think that some video card drivers prefer VSync Off and sometimes when it is On, they have trouble rendering at a constant rate, and thus frames are dropped. This might be more related to my second main reason.

2) Another reason is that the game is simply rendering too much for some video cards to maintain a constant framerate.
o Remember that if Flip –1 or 1 is used in full-screen mode, the game is trying to run at a constant framerate, and that enough strain occurs on the video card the framerate will halve. E.g. full framerate = 60Hz, too much rendering and it will drop to exactly 30Hz, then to 15Hz etc.
o If a game runs at exactly half the full-frame rate, and it used proper timing, the sprites will have a higher step value but they shouldn’t jerk, so it should look OK, but not as good as full-frame rate.
o *** Now here is a critical observation. What if the video card is on the borderline between full-frame rate and half frame rate? In other words, as it renders, sometimes it can manage 60Hz and other times the strain is just slightly too much, and it misses the VSync and thus drops to 30Hz. If this happens a lot, the framerate will fluctuate between 60Hz and 30Hz - the timing system will compensate BUT it will result in a horrible fluctuating from smooth to not so smooth which may well look quite jerky.
o Changing to Flip 0 avoids this halving of framerate issue; the video card will render whenever it is able to and the timing will compensate, thus the FPS will fluctuate wildly, but it might look OK, apart from vertical tearing, which cannot be avoided with Flip 0 by it’s very nature.

3) One more thing. I was getting a high step value on my laptop, but I remembered that I have it set to output a signal to a second screen (a monitor through the VDU port). My game window was just off the edge of the laptop screen on the right by only a couple of pixels, this meant that the video card was trying to draw the missing pixels on the monitor! When I moved the window left, suddenly it all went smooth. Please bear this in mind if you have multiple monitors set up!


Professional Games:
- I’ve tested a few professional indie games now and most are fine in full screen, but many show tearing in windowed mode and also stuttering. Therefore this problem is not just confined to Blitz Max.

Nice read.

Note; I also get that Mouse-Lag thing that Max suffers from when using pro games like GTA.

Huh? LCD monitors sync / refresh with exactly the same vertical and horizontal timing signals as any other monitor.

The term progressive scan these days is used in HDTV to differentiate between interlace where alternate frames only update odd or even lines and progressive where all lines are updated every frame (1080i vs 1080p).

Like I pointed out a couple of days ago it's just not possible in the majority of cases to sync to refresh in windowed mode, no matter how many times you try it just will not happen.

I quote:

And guess what it's the same problem with OGL.

OK nice read... could use some proper indenting and formatting tho ;)

"big10p (Posted 11 hours ago)
I get a slight jerking with the new version. It's the same in both DX/OGL and windowed/fullscreen."

This was with flip -1. I believe that the flip and sync stuff needs a proper look at in Blitzmax and may be related to tearing also.

Maybe it's DirectX 7 as that's what the issue is with, not BlitzMax.

Well I've got a plasma TV and they are progressive scan right, that's why light guns don't work on them. A knowledgeable friend said TFTs were the same, I guess he was wrong then, I did wonder why I saw scanlines, thanks for the update. I'll edit the essay...

Indiepath: Yeah I read that and concluded the same from my tests on many PCs.

I wrote it in word and it was properly laid out but obviously it looses all that when pasted in the forum.

Edited my reply Grey, didn't want to sound rude. Plasma pixels do I think have a persistant property so they have to be darkened or lightened to change, ie they don't fire then fade like other display technologies. I think TFT pixels still fade, they just have a reputation of doing it too slowly, not that this impacts on the refresh cycle at work that updates each and every one of them.

GTA Vice city? but yeah, I know it's a DX problem. Bit of a bummer :)

Well I suppose, at least some people are taking their Blitzmax bug reports one step further. :)

Skidracer: That's OK, I was just totally misinformed that's all. Just checked out the whole thing on wiki. I've certainly seen slow fading pixels on TFTs, it makes action games look horrible and blurry, esp. as the fade is different for different colours.

Cyg: Or they just have some naff interface code... The problem doesn't exist in DX 9 (apparently).

Enay: well, my essay is just a general discussion about issues that can affect games, no matter what the language, and BMax has them too. I'm just trying to find the best solutions/workarounds so we can all enjoy smooth action games on a larger range of PCs.

I thought the delay in TFT LCD panels was due to the crystals realigning themselves to a new angle.
I believe Grey was right further up, as in pixels on an LCD only change if there's new information.

Think of LCD like this - light passes through a layer of crystals, that bend light according to which direction they're facing. These crystals are controlled by currents in a matrix grid. Whenever you change the currents, the crystals need some time to move before settling. This is what the 25-12-8-6ms whatever is all about. The lower the ms, the faster the crystals readjusts.

Anyone got links to this to perhaps prove me wrong?

Lowering the Render Ahead fixed the issue, so it's the same problem. I see it in other pro titles too, though I don't have a list :)

retro.hack , True, however;

The TFT still has to receive the information, and to do so it uses the 60hz signal. The data can therefore only update the same speed as a TV- pixels at the bottom of the screen may well be from a previous frame.

retro.hack. Yeah I had heard that and got confused thinking there was not supposed to be a scanline, but there is of course.

Cyg: OK, interesting info on Render Ahead, thanks.

It's worth using flip -1 as it won't drain battery life like a bastard on laptops.

Yes, you're right.

Your graphics cards send out rasterized information to the monitor, even if its a CRT/LCD/Plasma, and the monitor converts it into information it can use.
The problem however, which I failed to demonstrate above, is that this process is entirely controlled by the graphics card.
In earlier years, programmers had direct control of the raster and used it as a tool to make cool effects and special graphics modes.
Today however, its an obstacle we have to overcome because its functionality can be decoupled by the drivers, hardware or software.
It makes sense to draw everything before Vsync, but you can't be sure that every hardware configuration works the same.

I can see a future where they get rid of the whole rasterization process, and just upload whole frames to the monitors. In your programming, you'll just have to throw a RenderFrame() at your decided interval, and not worry about timing issues.

Bah, Im ranting.. please ignore me :)

Bleeeh! It worries me a bit that game developers could fall into putting technical pedantry before consumer experience. If your customer sees a jerky update then your update is jerky - how very clever you might be being in the background really doesn't matter one iota. *I know* you're addressing developers here, but I still think it's genuinely important to bear this in mind: Untrained eyes are the eyes you ultimately have to please.

Other than that, it's mostly good as long as it's taken in this context: You can't win. Either you fix the rate of your game and it falls out of sync with certain monitors or you sync to the monitor and your game runs at different speeds on different boxes. There are benefits and costs associated with whichever method you opt for and how you choose to implement it, and while it would be fantastic to have those benefits and costs collated so folk can make an informed decision, I wouldn't waste any extra time and energy trying to "solve" this logical impass.

I'm not trying to be horrid here, I'm just saying great work, but don't get too caught up on something that isn't really fixable. A comprehensive essay that explains the problem and one's options would be massively valuable in and of itself.

Oh and users that turn vsync off in their card's drivers have opted to see screen tearing... it's not your job to fix that!

Hello.

He said jerking. Snigger.

Apologies.

Goodbye.

All commercial games do this, what exactly is the problem? bigger gaps between movement is the nature of the beast when pcs slow down.

In the old days the actual time would slow down instead so you were running through glue. You prefer that??

Actually the timing method (Reto64 as Jake calls it) suffers from exactly that.

> In the old days the actual time would slow down
> instead so you were running through glue.
> You prefer that??

Sometimes that sort of slowdown is better, especially on shooting games, you can't argue that the game cheated you out of responsiveness and you died as a result.

Old skool slowdown made the game temporarily easier for you :)

Simple answer: Yes. With delta timing you don't actually know what the hell your end-user will get to see. Not knowing what you're presenting means you've failed as a designer, regardless of how technically superior that fancy-pants timing code makes you feel inside your own head.

And, of course, if you're honest about your required specs then slowdown won't be an issue.

Sledge: Sure, a larger step size looks jerky to consumers (and me) but I was trying to point out the difference technically between a large step size which is constant (looks OKish), and random jerks caused by dropped frames (worse imho). That's all, perhaps my wording could be better... But yeah plenty of games run at half the framerate and even used to in the old days, some Amiga games ran at 50Hz and some at 25Hz. I prefered the 50Hz ones, they looked smoother.

Indiepath: You have to have a really slow crappy logic loop for this to occur. Also remember that on a slow PC delta timing will result in missed collisions unless you implement special code. Swings and roundabouts ...

re: required specs. The problem is someone may have a great CPU but crap video card or vice versa, and then the game runs crap. It's also much harder to specify a certain type of graphics card as a min spec. They don't have a simple rating like CPUs e.g. MHz of GHz (I know they do internally and techie users know this) that the end-user can gauge the power by.

One Eyed Jack > [All commercial games do this, what exactly is the problem] : it's why all PC games make me mad... I HATE jerky animations !!!

One Eyed Jack > [In the old days the actual time would slow down instead so you were running through glue. You prefer that??] : yes, I would.

All this problems because, after DOS Games ), people didn't want to play 60hz games on their CRT monitors...

Timming on PC are like a car with 3 wheels...

yeah it stinks and makes me mad. Hopefully in the future there will be some standard, esp. if Microsoft want no tearing on their Desktop.

I think there's an insult there somewhere, but I'm not offended. I think you are wrong.

The problem is with "And, of course, if you're honest about your required specs then slowdown won't be an issue." -- firstly, many users don't know their own specs. Secondly, many things can happen that makes a pc run out-of-spec.

Therefore I will just have to try my best. BTW: "regardless of how technically superior that fancy-pants timing code makes you feel inside your own head." -- I don't understand your problem. This isn't about how clever I feel, I am not one of those people. This is about how I can deliver the most similar experience on the widest amount of machines.


For "Slowing down" affectionados, please be aware this alienates you from every realtime multiplayer game there is. It's simply no solution at all for games.

I understand where a lot of you are coming from - I'm likely a lot older than the majority of you and have played those old games, but time moves on... it doesn't slow down ;)

Grey Alien > [if Microsoft want no tearing on their Desktop] : I think we could, just flip with a "Vwait" thing ( I know that with this method the frame rendering for video won't be regular as a 60hz tv ). The most important thing is to creat a standard for full screen games. I hope DX10 will do something for that, as a lot of PC gamers are bored with tearing, Vsync, triple buffers, jerky rendering, etc.

:(

Cool, well lets focus on what we can do now :)

Good. I'm playing devil's advocate to an extent. The complex answer is that I have a tolerance for it like everyone else, especially where 3d is concerned. But ultimately it's far from ideal to rob players of visual information and, yes, dropping frames in order to convey the illusion that the game is working okay on a low spec machine *is* a bit of a con.


Don't take it personally just because I was writing in response to your post. "You" and "your" I meant in a general sense but that's hard to convey in written text of course - unless it's excplicit, I'm not commenting on individuals.

I do think that there's a techical challenge within delta timing which predesposes geeks (geeks=good; nerds=bad, remember) to seeing it as a worthwhile pursuit without fully considering its effects on gameplay on low spec machines.


This could all be covered by the provision of a demo, which is normal for indie stuff anyway.


That's just it - the experience you get when frames are dropped is vastly different to when they aren't. Suddenly there is (perhaps vital) visual info missing and that's unfair on the player... at least slowdown is unfair in the player's favour. BUT HANG ON...


I'm not arguing FOR slowdown, I'm arguing AGAINST variable frame rates. Ideally I don't want to see either.


Stonkingly good point.


Bleeeh! Again.

Well said Rob, frankly this is all "Pie on the Sky" whilst you are all arguing about it. I'd suggest finishing the games and making a few bucks :)

bravo, I concur.

Anyway OEJ: I'm going to stick with fixed rate logic at 200Hz (although it's user-defineable in the framework) and Flip -1 in full-screen mode + lag fix. This gives a good result on many PCs, but not all, mainly due to windows interference or underpowered cards (I think) In windowed mode I'm going to go with Skidracer's Vwait fix, and Flip -1 + lag fix, so there is no vertical tearing on machines that support it. This may result in a tear at the same position on some machines so I'm willing to change this in the future. If I change, it will be to Flip 0 and no VWait because the fixed rate logic will handle the varying FPS and the tearing won't look too bad if it's random. It's certainly not ideal, but I can't afford tomess around any more, sorry :-( Let me know how you get on, I'll keep watching ...

Nice review of the issues, Grey Alien.

I say bring back the `vertical blank interrupt` from the Amiga. :-)

One thing that came to mind is the part where Windows, or any other o/s, fights with your app to take away some of the CPU time for whatever it needs to do. In the old days on the Amiga, for example, you could take over the whole machine, shut down the o/s (disable multitasking), open your own screen and draw directly to the video memory. You also had a vertical blank interrupt which you could put all your graphics drawing code inside so that it would always be called at exactly the right time - or that you could use to do hardware flipping of the front/back buffers. Perfectly smooth all the time so long as your system had enough oomph to always finish drawing all the gfx in time.

So what you have now is Windows has multitasking switched on and is trying to do some other tasks. Either you have to turn multitasking off, which might not be feasible, or you have to allow for the fact that it IS going to pre-empt your application for various reasons at who-knows-what time and for who-knows-how-long. Maybe what we need is a command that returns control to the o/s toward the end of a frame, but pulls it back from the o/s when the time comes to do a flip. Or maybe a form of Flip that, while waiting for the VWait or software timing, hands back control to the o/s for a bit. Then the o/s can do its thing and not have to fight so hard to interrupt your app. That said, who knows if this would even satisfy it, maybe it would still interrupt you at any given moment. Ideally if you could switch off multitasking you'd be all set.

I also wonder if the FlipHook would help. If you know that the flip is probably vertically synchronized (Flip -1/1), then you could put all your game code inside the FlipHook function so that it gets called immediately after the flip. This would almost be similar to a vertical blank interrupt. Not sure of the benefits of that though.

Another issue that came to mind for me, that you didn't mention, is that in OpenGL, or probably DX also, although you've drawn stuff using the interface command it doesnt necessarily mean that the gfx card has flushed that and drawn it to the buffer. This doesn't usually matter because you don't see the drawing, due to a backbuffer, but what might affect things is that the gfx card might not be actually doing the drawing until you call Flip() or glFlush() or similar, then it has a sudden rush to draw all the gfx in one go, whereas this could've been happening much sooner if the gfx card were drawing in parallel to the CPU processing the game. This could cause extra delay and slowdown of the overall game. We should look into how/when to render, where in your loop to put the gfx code, and how to get the gfx card to be working hard throughout the whole frame evenly.

Just to clarify also, the vertical tear is caused as you said by the video beam/update overtaking or being overtaken by the copying of the back buffer to the front buffer. This is all due to either drawing stuff direct to the front buffer, or copying the backbuffer to the front buffer (Flip). What I wondered is if it is worth trying to implement your own copying routine that is more friendly with regards to how the video beam is likely to behave, to avoid tearing. What if you copied the back buffer to the front in sections? What if instead of copying the whole buffer from the top left to the bottom right a row at a time, you copied in thin vertical strips from left to right? If the video beam overlapped the drawing of one of those strips, tearing would be restrained to only the width of the strip and probably hardly noticeable (or maybe the tear would bounce up and down the screen more?). I know that at least in OpenGL you could use glReadBuffer() glWriteBuffer() and glCopyPixels() to do the blitting.

I also wondered if there is a way to `time` the frame, how long it's taking, or how long it ideally takes given the hz rate, and then if you know things are v-sync'd, time your flip or time your gfx drawing to be in better harmony with the video beam? Not sure what I'm saying there.

Overall what I'm finding also is that there ISN't at this time a reliable certain solution. There is no reliable way of finding out for sure exactly what hardware is available, exactly where the vertical blank is, exactly what buffers the hardware supports. It also is not possible on some systems to open a context requesting certain buffers and have it open without crashing out when the buffers don't exist in that mode, so you can't assume ANYTHING is going to be certain. All you can assume is that on most systems, some most basic modes will work right. Beyond that you could provide the user with some options to `try` but that's as good as it gets.

For example if your desktop is 16-bit, normally you would not get a depth buffer/stencil buffer/alpha buffer. Same is true of fullscreen. Yet on some systems, if you take the dare and request those buffers you actually get them, AND due to some wierd internal handling of what you've requested, it might actually run much faster than without those buffers, perphaps due to how it rearranges the alignment of data in memory, or how it avoids certain software-based routines that the OpenGL driver uses in certain modes. You can never quite tell what the graphics card supports, in what modes, with what buffers, and which is going to work right or faster or better or be available.

I think all you can do is have some of the most basic `safe` `most predictable` modes, and offer any enhanced features ie extra buffers used etc as switches the user can try. If they fail, chances are the app will bomb out. That's the best you can hope for. What I'm doing is aiming for the user to have at least one decent 32-bit mode, because in 32-bit you can *probably* be fairly sure that it will support all the buffers - stencil/alpha/depth/accum. Then if it's anything less than 32-bit, assume it has no extra buffers, cus on different platforms it either does or does not support it. Then let them select to try turning on these modes, and risk crashing. It's pretty precarious and unreliable and frustrating, but that too is the nature of the hardware/driver/support beast at this time.

Anyway, good stuff.

AngelDaniel good points there, thanks.

First one, which I was also thinking of recently is switching off all OS control when drawing to ensure it's top speed, like you said, then giving it control at some other time when it's allowed and safe, providing it doesn GRAB too much control and come back late or whatever.

Second big point you made about the draw commands maybe being queued and then all done at once with the flip is a very good point. I bet some cards do this. Some kind of way to force that drawing at a set time not with the flip would be great, then the flip would occur quickly and not result in any visible tear.

The whole working in harmony with the video card by drawing certain strips at certain times etc is very intersted and clever but I don't have the time do look into this now :-( It might not work on all PCs as some don't give decent feedback about their scanline position.

Also giving customers options to turn on fancy stuff is a good idea for action games that techie types might play but normal users won't ever look for this. They'll take one look at it and go, "uh it's all funny and jerky" and exit = Lost sale.

Indiepath was saying that perhaps Max just needs to be brought up to date with DX8 or 9. But then we exlcude a lot of customers, swings and roundabouts again ...

Heh, I was saying to Grey that I remember programming multi sprite games for the C64 using the raster interrupt. Since you could only have 8 sprites we used to split the screen according to the raster line and use that to display as many sprites as we could. Now why can't we do that with windows?

Grey .... you can do glFlush() at certain points in the code, maybe halfway through a frame, would help. This will force the gfx card to draw what it has in its buffer.

However, to your second assumption, it would not help *directly* with tearing because when you flush the card all you're doing is asking it to draw stuff to the backbuffer. It's not the drawing to the backbuffer that makes things tear, it's the copy to the front buffer. However, that said, if the gfx card has to a) draw everything all at once and b) then copy to the front buffer, chances are that it would finish drawing to the front buffer *sooner* if it had already finished drawing to the backbuffer earlier in the code.

ie, if the gfx card finishes all drawing to the backbuffer way before the flip time come, then when the flip happens it doesnt have anything holding it back so it will copy to the front right away. This *might* allow it to be far enough ahead of the vwait that it doesn't produce tearing.

It also *might* be worthwhile doing a glFlush() (in opengl at least) just before you do a Flip, since the flip will spend some time waiting, so you might as well use that time to have the gfx card begin drawing its stuff if it hasn't already. And remember though in some cases the gfx card will render immediately and you wont have any benefit by trying to force a flush. Also they say that flushing should be used sparingly, I forget the reason, but something to do with that it doesn't return control to your app until the flush is complete or something? Who knows, maybe it'll help.

Do you know that all the tearing problems are DX only and would be fixed by updating DX, or does it apply to OpenGL as well?

Also, do the people who get tearing in window mode, also get tearing by using a MaxGUI window?

I also agree that primarily you want to open a screen display which is correct on a majority of systems, but then offer extra options for those who are inclined to seek and use them. Ideally your basic mode will be free of tearing and will open properly.

The vertical flipping (in strips) rather than horizontal full-screen copy may or may not help, I might test it eventually. Generally speaking on my system, Flip 1 is smooth and solid with no tearing, so I wouldn't know.

How about this idea ... If you have a user who has opened a window and it is tearing in generally the same sort of place, although the hz rate is synchronized to the desktop, and you generally can't do anything about it, you COULD allow the user to press some keys which would move the tear `up or down` the display, given that it is usually confined to a given region.

The achieve this, what you need to do is use software timing to do your flip, ie time it with millisecs based on the hertz rate and use Flip 0, and adjust the amount of milliseconds that you offset it (ie wait a bit) so that the tear moves. By inserting a wait for a little while when the user presses the key, and still calling Flip 0 at a given framerate, you should be able to move the tear up and down the display.

It's at least an option for those who might be interested in using it. It would be kind of like tuning a tv to prevent picture roll.

Also if you have access to a correct vwait or beam position, you could use this to synchronize your software flip.

That's what I meant.

I wish there was a DXFlush() ... maybe there is...

mainly DX I think as I haven't done much OpenGL testing. Sorry I don't have more info.


Again, I don't know this. Skidracer was inferring it would be better to use a MaxGui canvas and event driven code, but I donn't have the time to invest in this yet. I'll see what others come up with.

Your tearing idea is cool (like manually tuning the Vsync based on your eyes because the stupid drivers can't do it!), but regretablly impractical for the average casual game player who totally won't get it. Like I said before, they'll take one look and won't bother to look for options.

Yah, well for those people who wont bother to press keys or wonder if thats possible or read that it is, they obviously won't use it, but some people will. Some is better than none. I know it's preferably to fix it for everyone so that isn't even needed, but fact is right now you are not going to get 100% coverage on all platforms no matter what you do, unless someone comes up with a miracle fix.

I wonder if we should start a thread discussing whether there is truth to this idea of a `casual gamer` who seems to be given the personality of someone really stupid.

not "stupid" just unaware of technical issues, thus doesn't go looking for them and wouldn't understand if they found "Press Arrow Keys to adjust VSync scanline to reduce vertical tearing" in the options page ;-) Even though it IS a cool idea.

No discussion needed. They exist.