Ye olde DX mouse lag
BlitzMax Forums/BlitzMax Programming/Ye olde DX mouse lag
| ||
| Has anyone noticed the old DX mouse lag problem returning when using Flip 0 (no VSync)? I have had it a few times now, sort of off an on, weird... |
| ||
| Yes, I have seen DX in Windows seem to lag when I am letting my app run as fast as possible with no throttling. It is wierd, because it does it on my PC at work while running about 400fps, but then at home running about 650fps it does not lag. Anyway, I switched to the OpenGL driver and everything is fine on both machines and it runs about the same speed. |
| ||
| what no one else has noticed this with DX in windowed mode and Flip 0? Maybe I'll have to make a demo... |
| ||
| It appears that the DX lag fix isn't used in windowed mode with the new DXGraphics module? |
| ||
| Yeah that's what I'm saying and it's rubbish. Do you think we can get BRL to fix it? |
| ||
| I dunno, it looks pretty deliberate, perhaps there's a reason for it? You could always try changing it back yourself to see what happens? |
| ||
| Maybe it's something to do with not hogging the CPU or something in windowed mode? Who else wants the lag fix back in for windowed mode? |
| ||
| I've never seen this fabled mouse lag. Example please! |
| ||
Taken from the original posts found using 'mouse lags''SetGraphicsDriver GLMax2DDriver() Graphics 1024,768 While Not KeyHit(KEY_ESCAPE) DrawLine MouseX()-5,MouseY()-5,MouseX()+5,MouseY()+5 DrawLine MouseX()+5,MouseY()-5,MouseX()-5,MouseY()+5 'Flip 0 ' no lag Flip 1 ' mouse lags 'Flip -1 ' mouse lags Cls Wend @GA, Just report it as a bug and see what happens. |
| ||
| TonyG: Not that's not it. That's a normal mouse lag which has been in BlitzMax since day one. It's around 1 frame for DX and 2 for GL (i.e. worse) and is due to the input being read before you see the vsynced flipped buffer. It goes away with Flip 0 because it updates the screen much more often. Sorry I should have been more clear with my intitial post. The problem is a DX rendering issue with the pipeline getting clogged up which causes a major delay to all input. It even messes up graphics drawn with delta time as DX stores up the frames and then just outputs them one after the other with no timing. Here is something that will show the issue. Run it and press z and x randomly then stop pressing them - note how the square MOVES ON ITS OWN as the DX buffer rendering catches up. Change to OpenGL or full screen and it's fine. You may need to adjust the loop size to make it runnable on your PC...
'SetGraphicsDriver GLMax2DDriver()
'Graphics 800,600,32
Graphics 800,600,0
x = 300
y = 200
While Not KeyHit(KEY_ESCAPE)
Cls
If KeyDown(KEY_Z) Then x = x - 10
If KeyDown(KEY_X) Then x = x + 10
SetScale 8,8
For i = 0 To 2000
DrawRect x,y,30,30
Next
SetScale 1, 1
Flip 1
Wend
If other people get this, then I'll post as a bug because this got fixed a while ago and has now started again with the new DX module. |
| ||
| Hmmm, I get the problem but how is it related to a 'mouse lag'? |
| ||
no time for testing this morning but try changing dxgraphics.mod/d3d7graphics.bmx[167] to:_primSurf.Blt( dest,_renderSurf,src,DDBLT_WAIT,Null ) and some interesting reading in ddraw.h for some background in to microsofts mental-ity, they seem to have some major confusion with the definition of the numbers three and one... /* * These flags indicate a presentation blt (i.e. a blt * that moves surface contents from an offscreen back buffer to the primary * surface). The driver is not allowed to "queue" more than three such blts. * The "end" of the presentation blt is indicated, since the * blt may be clipped, in which case the runtime will call the driver with * several blts. All blts (even if not clipped) are tagged with DDBLT_PRESENTATION * and the last (even if not clipped) additionally with DDBLT_LAST_PRESENTATION. * Thus the true rule is that the driver must not schedule a DDBLT_PRESENTATION * blt if there are 3 or more DDBLT_PRESENTLAST blts in the hardware pipe. * If there are such blts in the pipe, the driver should return DDERR_WASSTILLDRAWING * until the oldest queued DDBLT_LAST_PRESENTATION blts has been retired (i.e. the * pixels have been actually written to the primary surface). Once the oldest blt * has been retired, the driver is free to schedule the current blt. * The goal is to provide a mechanism whereby the device's hardware queue never * gets more than 3 frames ahead of the frames being generated by the application. * When excessive queueing occurs, applications become unusable because the application * visibly lags user input, and such problems make windowed interactive applications impossible. * Some drivers may not have sufficient knowledge of their hardware's FIFO to know * when a certain blt has been retired. Such drivers should code cautiously, and * simply not allow any frames to be queued at all. DDBLT_LAST_PRESENTATION should cause * such drivers to return DDERR_WASSTILLDRAWING until the accelerator is completely * finished- exactly as if the application had called Lock on the source surface * before calling Blt. * In other words, the driver is allowed and encouraged to * generate as much latency as it can, but never more than 3 frames worth. * Implementation detail: Drivers should count blts against the SOURCE surface, not * against the primary surface. This enables multiple parallel windowed application * to function more optimally. * This flag is passed only to DX8 or higher drivers. * * APPLICATIONS DO NOT SET THESE FLAGS. THEY ARE SET BY THE DIRECTDRAW RUNTIME. * */ |
| ||
| tonyg: if you are doing a lot of game drawing and you move the mouse cursor round, it will appear to lag because all input lags, and it's the most obvious input (for casual games). SkidRacer: great, thanks for the quick response. I'll try this out. Interesting reading. Also it says it's for DX8 yet we are using DX7, no problem there? |
| ||
| In the code tonyg posted I find I get the mouse lag on Flip 0 and no lag on Flip 1 or -1. I recently had to downgrade my graphics card to an old Radeon 7000 card when my 9600 card died so maybe the age of the card is to blame. Could someone verify the comments in the code are correct - Flip 0 should have no lag? |
| ||
| Hmm. I see a tearing effect in Grey Aliens example, although the tearing isn't in OpenGL or full screen the rectangle moves slower than in DX window. Other than that I don't see any lag or the rectangle moving by itself. |
| ||
| It depends on the Video Hardware/Drivers. My PC at home does not do it. My PC at work does it. But, if I set the driver to OpenGL, then it doesn't do it on either machine. |
| ||
| CGV: Yeah the comments in tonyg's code are correct, you should see a lag if you move the mouse fast but not with Flip 0. Azahoth: weird. Did you try adjusting the loop size? |
| ||
| I did increase it later but still didn't see much in the way of the rectangle moving on its own. The main thing that caught my eye was in DX window mode it suffered tearing and but moved faster. |
| ||
| skidracer: That fix didn't work I'm afraid. There is still lag. |
| ||
| I think it's better to submit to bug area and post the examples code, I got the lag ,too. |
| ||
| ok will do. |
   |