Public Group

# strange and annoying bug with SDL window

This topic is 5041 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

hi, i have seen this bug for awhile now, however it hasn't bothered me enough to post about it untill recently. i am working on a 2d game using OpenGL for graphics and SDL for input and window creation. i get this very annoying and strange bug that i can't figure out. in my game i use the mouse as movement - when you click somewhere, your character walks to where you clicked.basically the problem is this: when i click on the top part of the window (you know, when you click at the top of a window to click-n-drag it?), instead of me "grabbing" the window like it should - when i click, my character just starts walking to where i clicked! in fact, its impossible for me to grab the window, no matter how many times i click, i just keep walking to where i clicked.. however, the quick "fix" is this - if i minimize the window and then bring it back into focus - the bug goes away and i can drag the window again. a few things 1) i'm taking input by grabbing it using SDL_GetMouseState(), and im using the Enginuity method of checking for input, that is seeing if a button was just pressed or is being held down. 2) i'm not sure, but i think it happends more frequenty (or only) when i have 2 windows open. that is, if i have 2 instances of my game running, it seems to happen more frequently. might be in my head though.. 3) i tried doing something like this:
bool Is_Mouse_Down(int button)
{
int x,y;
SDL_GetMousestate(&x,&y);
if(x < 0 || y < 0)
return false;

if(key_is_really_down())
return true;
}

do you se what i do? i check to make sure the mouse is in the bounds of the window, and if it's not then i return fase. a quick and ugly hack - however, it doens't seem to work. i think it might have reduced how often it happends, but again im not sure and it could just be in my head. thanks for any help!

##### Share on other sites
Well, try this. If it is infact taking the window title bar into account for the input, you may need to offset the title. Instead of checking if the y value is less than or equal to zero, try sixteen instead.

##### Share on other sites
hey PnP,

thanks for the reply. i'm at work right now so i can't test it out, but im pretty sure that it won't work. i would be very surprised to find out that al my mous coordinates are being offset by ~16 pixels. this is because i use the mouse for movement, and i do land exactly where i click. if it was off then i think i would miss my target.

anyone have any clue what the problem could be?

##### Share on other sites
Quote:
 Original post by graveyard fillahey PnP,thanks for the reply. i'm at work right now so i can't test it out, but im pretty sure that it won't work. i would be very surprised to find out that al my mous coordinates are being offset by ~16 pixels. this is because i use the mouse for movement, and i do land exactly where i click. if it was off then i think i would miss my target. anyone have any clue what the problem could be?

No, I don't think that PnP Bios is saying that the mouse coordinates are being offset, I think he is trying to say that the location of (0,0) begins in the top left corner of the title bar - not the top left corner right below the title bar.

Anyways, I was experiencing the exact same problem myself when using SDL for window creation (running WindowsXP Pro) that after playing the game for while it would not respond to mouse clicks on the title bar so I could drag it. After bringing up the task bar, I noticed that I had a major memmory leak (like 5MB per game stage), and after going past the 10th stage the window could not be dragged.

After I got rid of the memory leak I have had no problems with dragging the window. I am not exactly sure what the problem is, but it may be that if you're game is using up too many of your computer's resources, then some messages (like drag window) get dropped. My game uses about 25MB of memmory, and my computer has 512MB of RAM. I did not experience problems until my game was consuming like 128MB of memmory due to the previous mentioned memmory leak.

One question, how much memmory is your game consuming at the point where you can not drag the window?

Also, I was wondering if you were calling SDL_PollEvent() anywhere in your game. I believe that that function will handle window messages like dragging the window, in addition to other input. Someone correct me if I'm wrong about that last one, but I am not sure how your application would receive window messages without PollEvent or a varient of that function.

##### Share on other sites
yes, i understood what he meant, and if you think about it, this would mean my position would be offset by that many pixels (since where i click isnt truly where i click, since its no longer relative to 0,0, but relative to 16,16 or whatever). well, im pretty sure at least (its kind of tricky).

i don't think i have any memory leaks and ive been watching my task manager and dont see any problems.. my game doesn't use up much memory (something like 17,000 K the Task Manager says).

also, i do use SDL_PollEvents() each frame to flush out the keyboard state so i can use GetKeyState(). (which is what i use primarily for keyboard input)

anyone have any other clues?

##### Share on other sites
just incase anyone searches the forums for this problem, i found the fix. apparently it was a bug with SDL. anyway the newer version fixes it and can be downloaded here.

1. 1
2. 2
Rutin
18
3. 3
4. 4
5. 5
frob
12

• 9
• 21
• 12
• 9
• 17
• ### Forum Statistics

• Total Topics
632607
• Total Posts
3007387

×