Blitz Runtime Window too tall
Archives Forums/Blitz3D Bug Reports/Blitz Runtime Window too tall
| ||
| I've noticed that the Blitz Runtime Window is actually 33 pixels taller than I tell it to be through the Graphics command when in windowed mode. I am guessing that this is compensation for the title bar, but this can be confusing when working with the Windows GUI, and if an app is sized to fit the user's exact desktop width/height, it will be 33 pixels too high. While a bit of a sudden adjustment, I am sure it wouldn't be too horrific of a change. If worse comes to worse, we can always have another window mode that sizes the runtime window the way I want it, leaving still the option for the old, wrong way. |
| ||
| No offense, but for GAMES, having the window set by client size is a GOOD thing. The "actual" size will vary over different versions of Windows, especially with XP and its skins, but the client size will remain the same allowing your game and any x,y locations used in your game (sprites, collision, etc) to be accurate and work correctly on all systems. Even for apps, I prefer to size by client-size. That way I know what the "usable" area of a window is and will be on all systems and can program the app accordingly. |
| ||
| I agree that client size is a good thing, but what about the bottom 32 pixels? We can't just abandon them :P |
| ||
| Whatever you tell Blitz to size the window as, is what the client size will be. If you want a window sized to the desktop (which varies system to system), use the stretch feature, this is especially good as some people leave the taskbar always displayed instead of hidden. It would be asinine to do away with sizing by client size in Blitz. Window sizing in B3D works properly. |
| ||
| Mr Pick - this is the code I use to handle the titlebar/caption problem:- (nResWindowed is 0/1 - i.e. do I want it windoed or not.) win = 1 + nResWindowed CaptionHeight = 0 If nResWindowed CaptionHeight = GetSystemMetrics(SM_CYCAPTION) EndIf Graphics3D wid, hit -CaptionHeight, fd, win |
| ||
| Cool, thanks John! I was hoping for a less arbitrary way to deal with that. So, I guess the client size window sizing is actually a feature :) Still, a native way to deal with that stuff would be kind of nice. Perhaps, as I suggested, another option in the Graphics command for the window type, along with some way to get the width/height of the back/front buffers... (Which, I suppose, makes this a feature request). |
| ||
| A less arbitrary way? - yes, in an ideal world. By now you've probably found that you also need to adjust for the window borders for width, depending on what you're doing. Have yoou got all the SystemMetrics info/flags you need? |
| ||
| Oh, the pain... I suppose I could just make the app smaller than the user's desktop by a really extreme amount. Window borders don't really matter too much, though. I think they're a bit big in Vista, which will be a pain, but right now I doubt anybody will notice their absense. I guess I could resize the window with Win32, then change my camera viewport to something. Hmm... there's the feature request that would solve these problems: Functions to get/change the width/height of the area where Blitz is drawing its stuff. (I'm assuming, of course, that the function would be aware of the window being resized at some level). |
| ||
| Tell me what you're trying to do. Is it a Bitz3D app, but borderless and matching the user's desktop size? If so then you will have to: a) get the size of the borders/caption (which can vary from user to user) b) Create the window as usual, but specifying extra width/height, so that the main view area is what you eventually want. c) remove the borders etc d) reposition the window at 0,0. Summink like that? |
| ||
| Is this any use? http://www.blitzbasic.com/codearcs/codearcs.php?code=1682 |
| ||
| Yes, that's the style-a-fing. Except for handling the window borders. And the redundant html code. ;) |
   |