Forgot how to remove the mouse lag bug
BlitzMax Forums/BlitzMax Programming/Forgot how to remove the mouse lag bug
| ||
| Hi all, I've forgotten how to correctly remove the bug with blitzmax and mouse input where the mouse lags behind. I'm running on a super-powerful computer and if I recall it had something to do with creating a pixmap. At the moment, it's unplayable with particles turned on. Note: this isn't slowdown, but a known mouse lag issue - just need some example code to eradicate this. I think skid had a solution but for the life of me I cannot find that thread. Please post example code if you know the issue I'm talking about :) Thanks! |
| ||
| Wasn't it grabbing a pixmap/image just before or after flip? |
| ||
| Just in case you want to see the old threads search on 'mouse lag' |
| ||
| Or use OpenGL driver as it is a DX only problem. (an alternative way which you sadly can't is forcing the flip queue to a size of 1. Ati tray tools allows that) |
| ||
| http://www.blitzbasic.com/Community/posts.php?topic=54919 no conclusion, nice. I get the lag too, and mine is a Radeon 9800XT. oh here's a conclusions: http://www.blitzbasic.com/Community/posts.php?topic=54938 |
| ||
| Yeah something to do with pixmap, but I don't know what. If you're reading skid, please could you clarify what it is I must do? |
| ||
| oops sorry, I've edit teh second link it was supposed to be different! I thought the conclusion was use OPenGL, or do various gramimage tricks etc. |
| ||
| either grab or draw a 1*1 pixmap to 0,0 |
| ||
| whats faster? |
| ||
| The problem is DX. It can precalculate up to 8 frames ahead if your card is fast enough. This can be forced to 1 frame ahead with ATI Tray tool and similar tools and through manual writing operations. OpenGL in max can calculate 2 frames ahead |
| ||
| I cannot ask all my customers to force it to 1 frame with ati tools so this will never be an option. I tried using grabpixmap and my framerate went from 1,400 to 300. |
| ||
| youch. What's wrong with OPenGL. Looks Like I'm gonna do mine in that so the game will work on a Mac. |
| ||
| You hurt pc sales. It has to be DX on pc first with ogl as fallback. |
| ||
| This is an old known issue with DirectX7 trying to precalculate frames too far into the future. It was a pain in the ass back in the days. Haven't thought too much of it lately as DirectX7 is long gone (in the normal windows world that is :) |
| ||
| Right... begs the question then: as BlitzMax 2D heavily relies on DX7 could we have this fixed? I am actually drawing a small pixmap, and that seems a lot faster than grabbing a pixmap. I will have to check if that actually works though! Will report back... |
| ||
| Why not use the SDL device? Didn't somebody do something like that? |
| ||
| look forward to the report. |
| ||
| Grab a pixmap. You can't use drawpixmap. Perform a grabpixmap to cure the lag bug. However, it will be at a price: it seems to really impact on my frames per second - quite badly. Maybe thats just me? |
| ||
| DrawPixmap works for me. GrabImage worked also, maybe try that instead for speed. You're right though, every solution I've found seems to cut my frames in half. |
| ||
| DrawPixmap doesn't work for me, so we have to assume it's not reliable on all machines. GrabPixmap is a lot slower than drawpixmap for me. But it works. May I ask with what flags do you use DrawPixmap? Simon and Mark, what are your thoughts on this? I am not some fool criticising you, but asking for your views on how this should be tackled? Its a problem that exists on my test machines - would be nice to eradicate it. |
| ||
| I just shipped a game that uses GrabPixmap and it cuts my FPS down by a third. I really wish this could be solved another way. |
| ||
| ...And may I go off topic for a sec and say what a cracking job you made of it too, sir... |
| ||
| Since this whole thing is apparently caused by a DX setting to pre-render -x- frames, wouldn't it be possible to programmatically disable this from an application? If so, that would be a *really* welcome addition to the command set, since this mouse lag is really bothersome... Either the whole game experience feels 'slow' due to the delayed mouse movements, or you're artificially slowing it down at a noticable rate due to the overhead of the workarounds. |
| ||
| You don't need to force the users to 1 precalculate chainlength. You can force it through a DX setting ... but please don't ask me which ... perhaps someone else can say how thats done so we can add it? (I'm not sure if DX7 has this setting thought as the GPUs that were fast enough for longer flip chains started comming up with DX8 / 9 ...). The only way to prevent mouse lag at least a little is to use flip 0 so it does not wait for VSync ... this way the actual frame theoretically has the actual mousedata ... Theoretically ... PS: Don't forget, opengl renders 2 frames ahead as well if activated in driver. But at least not 8 frames :-) |
| ||
| The only way to prevent mouse lag at least a little is to use flip 0 so it does not wait for VSync ... this way the actual frame theoretically has the actual mousedata ... Theoretically ... Which seems to work... Except that leads to tearing and flicker, which isn't exactly an improvement. |
| ||
| It just doesn't work, I do flip 0 and it achieves nothing. It merely disguises the problem on some machines. Mark and Simon - please address this issue. |
| ||
| Problem is: Flip 0 only has any use if you didn't default disable VSync in driver settings which especially shooter fans normally have (you need the pic as early as possible for snipering) |
| ||
| ew, on my old pc: without = 25fps... with grabpixmap, 15fps??? That makes playability suffer quite a bit (on old machines) so I'm going to look for workarounds. I don't hold out much hope though |
| ||
| May I ask with what flags do you use DrawPixmap? Global DXImage:TPixMap = CreatePixmap(1 , 1, PF_RGB888) ' After Flip If launchedMode = 1 Then DrawPixmap DXImage, 0, 0 ' Cure mouse lagI'm not doing anything special, it must be a machine specific fix as you suggested. I'll go back to GrabImage for now. As with others, I will hopefully be shipping a product by the end of the month, it would be nice if Simon or Mark could offer us a fix before I have to cripple my game's performance on slower machines. |
| ||
| I wish I didn't have to use grabpixmap. |
| ||
| Lets talk about crop circles or something else non-technical, that should get their attention. |
| ||
| This is where the "support yourselves, we don't have time" attitude really hurts. Most of the time it works, but something like this really needs addressed by Mark. |
| ||
| for gods sake this was asked 15 hours ago on a weekend... one eyed, how does OpenGL hurt PC sales? |
| ||
| @dmaz, keep up, this has been reported a few times over the past 3 months or so with BRL involvement. @One-Eyed Jack, BlitzSupport suggested emailing if you think an im0portant topic/bug report was missed or has been ignored. Might be worth giving it another go in the bug reports followed up by an email. |
| ||
| I can't see the problem using OpenGL. I mean most drivers these days support OpenGL. And Blitzmax IS a crossplatform language. It should only support GL ;) |
| ||
| The problem is my target market have a lot pcs where drivers haven't been installed, that is - they can do dx just fine but lack an opengl component. Or don't have very good opengl drivers. This is mostly older pcs from casual gamers. I really wish it wasn't the case but DX isn't going anywhere. |
| ||
| Yeah, almost all up to date drivers support OpenGL. Most installed drivers aren't up to date, though. |
| ||
| Discovered the lag mostly happens in high fillrate low poly situations. I've had the card buffer half a second ahead. It's crazy. |
| ||
| this sounds bad. It could be a real stinker for casual games. |
| ||
| Isn't this only a problem because you are drawing and flipping the frame-buffer every loop rather than every 5ms or so. Calling flip 1400 times a second is dumb. At most the monitor is running at 100, 120 hertz. You should decouple your rendering code from you physics and game code and call each only when its needed. I've never had the problem and don't really understand the issue is so please ignore me if I'm missing the point. |
| ||
| Thanks but you're missing the point... solved? I managed to find a trick that flushes the driver's buffered frames - at least it works here: all people affected please check: http://www.blitzmax.com/Community/posts.php?topic=58192 If you aren't affected then don't worry. |
| ||
| Yep, that works for me, OEJ! I've put test code in that thread to demonstrate. On my system at least, the mouse lag goes away. |
| ||
| I may be thick but what does Flip 0 achieve other than draining the users battery by rendering a shedload more frames than can be displayed and effectively reducing CPU time able to be allocated to a games update routines. |
| ||
| Flip 0 or flip achieves the same lag result. It's not the point. |
| ||
| what does Flip 0 achieve[?] --- Flip 0 or flip achieves the same lag result. FWIW, on my mid-level PC (AMD Athlon XP 3000+ with Radeon 9600), running my sample code here: with Flip (no "0"), and with no OEJ "magic" (Const set to False), the sample runs somewhat better than it does with "Flip 0" and no magic. However, with Flip using 0 and magic turned on (Const set to True), it clearly runs the best of the four magic/"0" combinations. Now, that's just on my machine. Jack's beefed-up bug report source for his faster PC crawls on my system regardless of the Flip value (though it jumps to the last mouse position rather more quickly with his "magic" in the workaround section than without it). But in my example (taken from the MouseX example in the BlitzMax help), using Flip 0 with OEJ's magic fix is clearly better on my system than using 0-less Flip with his fix (though, in either case, the circle hugs the mouse cursor better when using Jack's "magic" fix). |
| ||
| OK, some results using the "OneEyedJackMagic" code: Flip 0, False = small lag, i.e. if I move the mouse in a circle, it appears to follow the pointer around about 1cm behind. Flip 1, False = small lag, tiny bit worse than Flip 0 (maybe) Flip 0, True = no log Flip 1, True = small lag (it's still there!) btw the lag isn't that bad in that example, it may only be one or two frames. hope this helps Radeon 9800XT |
| ||
| So none of this problem happens at all with OpenGL, the mouse stays totally up to date with where it is position right before the flip? |
| ||
| Most likely you won't see it, yes. Most users don't know how to tune their drivers to set OpenGL to render 2 frames ahead where you would see a little lag (8ms with flip 1 and 60hz), but not that noticable. |
   |