Way to detect if window is dragged?
BlitzMax Forums/BlitzMax Programming/Way to detect if window is dragged?
| ||
| Hiya, does anyone know a way to detect if a game in windowed mode is being dragged by the title bar? It seems that when this occurs, the game processing carries on but the screen stops updating, so I'd prefer to detect this and pause the gameplay until the user stop dragging/repositioning. Thank. |
| ||
| Yes, and I posted the details on this forum about 2 weeks ago. |
| ||
| if AppSuspended() |
| ||
| hmm, I searched seems I need to look again. Indiepath, any idea of a useful keyword to search for? [edit] Think I found it: http://www.blitzbasic.com/Community/posts.php?topic=56194#624955 but that's just a module hack that prevents the user from dragging. I don't want to prevent dragging, just find out when it's occuring (or better still when it's stopped) so I can reinitialise my Fixed Logic Timers to avoid jumping. The same issue would occur for Delta Timing too I'm sure. I'm already using AppSuspended. That works if the game is minimised or the focus is lost (another window is clicked) but NOT if the window is dragged by the user! |
| ||
| Yeah sorry Grey I can still never find stuff even though they have changed the search engine. You could use my code to set a flag that causes your timing loops to pause. This is where it's all happening.. |
| ||
| Thanks, I'll try that later if time. Meanwhile anyone got any other ideas? |
| ||
| @Grey, This is how you do it. |
| ||
| lol, well I haven't even comprehended what your code/hack does yet and if it'll work until I try it. In Delphi for example, you can tell if the user is moving the window and take action afterwards. So windows does allow it to be monitored, perhaps that is what your code does, I just haven't taken it in yet. |
| ||
| I'm basically capturing the windows messages and acting on them. You can probably do it by Peeking the message queue. |
| ||
| This seems like an utterely pointless thing to pay attention to. You are so going to miss your deadlines. |
| ||
| lol, I'm not looking into it right now. I just noticed it and made a note to post on the forums in case anyone had an easy solution. Meanwhile it's sitting on my to do as low priority. The thing is, if someone moves your game window as it's playing, the game processing stops, yet time moves on in the real world, so when the game retains focus, the Fixed Rate Logic thinks tons of time has passed and catches it all up in a single frame causing a "jump" in gameplay. Of course not that many people will do this or care, but it's not ideal. In fact a bigger related issue is that, have you noticed that if you drag a Max Window slightly off screen and back on, you get a totally corrupted window with bits of the task bar and itself repeated all over it? (try moving diagonally or in a circle!) Anyway, what I'm gradually doing is solving a whole pooload of boring technical issues with BlitzMax and Windows generally so I can have a really solid game framework to put all future games in. Then I might also sell it to interested parties so they don't have to go through the same pain I have had to! |
| ||
| I am sure your gamesplayers are gonna be dragging that window in circles instead of playing your undoubtedly fascinating game :) |
| ||
| lol, yeah OK, but it's not 100% cool. All these little things add up to the game looking less professional. |
| ||
| OK so I checked out Indiepath's code and all it does is prevent the user from dragging the window in DirectX and OpenGL. I'd like to allow users to drag and either not freeze program execution, or detect when a drag has occured and ended to reset the game timer to avoid big skips. Anyone done this sort of thing before? Hmm idea: could monitor the x and y coords of the window and do this before the timing loop starts and when changed reset the timer! This still won't prevent the graphics window from "smearing" horribly as the user drags the window around. Thanks. |
| ||
I think your game processing is being halted and your timing routine is actually the problem (should reset itself if it detects it has just suffered a long pause)? eg:Graphics 640,480,0 t=MilliSecs() While PollEvent()<>EVENT_APPTERMINATE SetClsColor Rnd(255),Rnd(255),Rnd(255) Cls Flip tt=MilliSecs() If tt-t>200 Print "resetclock" t=tt Wend End |
| ||
| Thanks Skidracer, it already reset it self after 500ms, but I've reduced this now. What I was really looking for was a neat way of doing it by detecting that the window had been moved. I also tested the code in BlitzPlus and it halts program execution too, but if you move the window off screen, it doesn't "smear" itself with the taskbar and other graphics unlike BlitzMax. Well I just wrote a mini app in Delphi to test if program execution is halted in other languages when the tile bar is click, and it is. Although delphi doesn't "Smear", this must be a 3D card effect I guess. |
| ||
In the end I check the window position before the timing loop begins, and if the position has changed I reset the timing variables:
Type TRect
Field L%, T%, R%, B%
End Type
Function ccWindowPosition:TRect()
Local hWnd% = GetActiveWindow()
Local window:TRect= New TRect
GetWindowRect(hWnd,window)
Return window
End Function
'Quickly check to see if the window has moved.
'If it has, this is because the user has dragged it and so we should
'reset the timing variables.
Local Rect:TRect = ccWindowPosition()
If Owner.WindowX <> Rect.L Or Owner.WindowY <> Rect.T Then
Init() 'reset timing variables
Owner.SetWindowCoords()
EndIf
|
| ||
| good thinking |
| ||
| I thought so, esp. as it actually works ;-) |
   |