I think the demo here speaks for itself:
ScreenMove_Middle
PRINT "Your program borders : "; glutGet
(506) PRINT "Your program titlebar : "; glutGet
(507) PRINT "To properly center your program, it should be at:" PRINT "Using Screenmove_Middle, it is currently at:" PRINT glutGet
(100), glutGet
(101) PRINT "Using _SCREENMOVE _MIDDLE, the screen is placed at:" PRINT glutGet
(100), glutGet
(101) PRINT "Which, as you can see, doesn't account for our borders or titlebar width and height."
PRINT "Maybe a better example would be to move the screen to 0,0." PRINT "Notice how the titlebar and borders are still here?" PRINT "Our program is actually at: "; glutGet
(100), glutGet
(101)
ScreenMove 0, 0
PRINT "And notice how our program window now starts at 0,0, like we told it to?" PRINT "And, as you can see, we're now actually at :"; glutGet
(100), glutGet
(101)
PRINT "And, best of all, since all these values are calculated manually, you don't need to worry about using a _DELAY with them, at the beginning of your code, as we're manually setting our X/Y position and not trying to do it automatically."
BorderWidth = glutGet(506)
TitleBarHeight = glutGet(507)
BorderWidth = glutGet(506)
TitleBarHeight = glutGet(507)
_SCREENMOVE x
- BorderWidth
, y
- BorderWidth
- TitleBarHeight
Note: I found these subtle positioning differences to be vital for me, in another little batch program which tries to interact with my screen in various ways. Clicks were often not registering as my screen simply wasn't where I expected it to be. A box from (0,0)-(100,100), wasn't really at those coordinates, as it was instead at (borderwidth, borderwidth + titlebarheight)-STEP(100,100)...
Which was more than enough to throw all my work off and cause all sorts of unintentional glitches. ;)