We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

What is your desktop resolution?

I was able to reproduce this by setting my desktop resolution to 1024x768, and then casually moving the window to the top of the screen and moving my task bar to the left side of the screen.  The maximum y value I got was exactly 754 in that scenario.

If I squeezed the window up as high as I could drag it, I ended up with a closer value:
Mouse motion: {1023,763}

What's happening is that Windows is clipping the mouse cursor at the bottom of the screen, and using standard controls you can't move the window up high enough to see the very bottom of the SDL application window.  Keep in mind that the resolution you ask SDL for is the client area of the window.

Feel free to re-open this bug if your desktop resolution isn't 1024x768 or I'm otherwise misunderstanding something.

Hello,

Thank you for this answers...

Yes, my resolution was 1024x768 in 32 bits colors, and the header of the windows out of screen.
My Microsoft Windows task bar is bottom.

If i put my screen in 1152x864, the SDL Windows in 1024x864. Then I drag the SDL windows header out of screen, the left-bottom mouse position is (1023,767) (OK).

The problem comes when the windows resolution is the same of the SDL window screen.

If the screen resolution is 800x600 and the SDL Windows is 800x600, the bottom position is 586 (NOK it must be 599).

The problem is that I have, in my SDL application, sensitive button wich hilight when the mouse move over. And when the screen resolution is the same of the SDL Windows display, there is an Y-offset with the mouse and my buttons hilight when the mouse isn't over (even if the windows header-bar is in the screen). It looks like the elements Y-position and the mouse Y-position different...

So, I hope not use my application in the same windows resolution and screen resolution, but it looks like a little bug in SDL.

You can close this bug.
I'll perhaps reopen it if I do more investigations for more presision about this.

Thanks !

Can you attach a test case?  If the visible mouse location doesn't match the mouse motion events, then that's something we should fix.

Yes, finally it is not a wrong mouse position error, it is a wrong OpenGl display position in y !

Here is my last test :
1)
- I put the screen resolution in 1024x768.
- My windowed SDL application is in 800x600.
- I execute my application and I go to my test windows wich contain a 72 pixels long and 32 pixels height button. This button y-position is 160 pixels from the top of the client windows area.
- I move the mouse vertically from the top (0) of the windows to go over my button (160).
- The button hilight when the y-mouse go from 160 to 161. Then the button light turn off when the y-mouse go from 192 to 193.
- This button behaviour is correct.
- I do a screenshot from this screen. 
- On this screenshot, the distance from the bottom of the windows-headerbar to the top of my button is 163 pixels.

2)
- I put the screen resolution in 800x600.
- My windowed SDL application is always in 800x600.
- The left-top corner of my SDL-windows is visible in the screen.
- When I move the mouse from the top to my button, the button higlight about 10 pixels too late, but alway when the mouse go from 160 to 161.
- I a do a screenshot from this screen. 
- On this screenshot, the distance from the bottom of the windows header-bar to the top of my button is 150 pixels.

There is a 13 pixels difference between my button position in this two cases.
I have a back picture behind my button and she has the same y-offset too, between the two screen resolution.

For my elements display I use the following OpenGl commands :
  glEnable(GL_TEXTURE_2D);
  glEnable(GL_BLEND);
  glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
  glBindTexture(GL_TEXTURE_2D, stTexture.nNumero);

  glBegin(GL_QUADS);
  
  glTexCoord2f(0, 0);
  glVertex2i(nX_gauche, nY_bas);
  
  ...

  glEnd();

  glDisable(GL_TEXTURE_2D);
  glDisable(GL_BLEND);


I hope you can reproduce the same behaviour with this indication... and perhaps correct it...

Best regards, and good luck...

Vincent

Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.

Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).

--ryan.

Possibly related to bug #713?

I believe this is a duplicate of another bug that is fixed for the next SDL 1.2 release.

You can test this out with the current SDL 1.2 snapshot here:
http://www.libsdl.org/tmp/SDL-1.2.zip

Please reopen this bug if it isn't fixed in the listed snapshot.

Thanks!

*** This bug has been marked as a duplicate of bug 713 ***