Getting Around the Dock

AlStaffieri
Unregistered
 
Post: #1
Let's say your making a game that requires a 1024 x 768 monitor because the main window fills that. When something like that is the case, what do you do with the Dock? Do you tell the user it won't run on their Mac because there's not enough room? The Dock could be placed on either side or at the bottom and various sizes. Do you let dealing with it up to the user? Do you hide the Dock while your game is running? What do most games do with that situation these days?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
You scale your content to fit their screen space, or you go full-screen.
Quote this message in a reply
Moderator
Posts: 682
Joined: 2002.11
Post: #3
The dock hides itself when you're in full-screen mode.

My web site - Games, music, Python stuff
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #4
This is all my opinion, but it's better these days to have your game not be pixel dependent since new displays are coming out with pixels smaller than 72 per inch. Besides, OpenGL does hardware scaling without flexing a muscle. What I do instead is rely on a fixed aspect if needed. 1024x768 is the ever-so-popular but going-out-of-style 1.3333 aspect. To maintain the aspect I do automatic letter boxing (black bars on top and bottom) and pillar boxing (black bars on left and right) depending on how the user has their window sized, so there are no restrictions. I set glViewport to the size of the window and then clear it black. Then calculate the size of the actual viewport needed for the game and set glViewport again, which then requires glScissor as well, and clear it for the game and everything is good to go from there. It's pretty simple in practice. You can download InkuGame for a demo of it in action:

Download the iDevGames Inkubator Project 2007 here

Side-note: The camera in the game isn't getting recalculated correctly when resizing, but that's not related to the resizing technique I'm talking about. We still need to fix that. It's especially noticeable between relaunches. It's been on the to-do list for a long time now...
Quote this message in a reply
AlStaffieri
Unregistered
 
Post: #5
Ok. I guess I asked the question the wrong way. I'm actually making a game editor/engine. I hate apps that have windows that stay on top of the main window and you have to keep moving windows around to get to the part you want at any given time, but I guess because of the Dock issue there's no real way around that.

If you're going full screen to eliminate the Dock then what's the purpose of Apple's Dock anyway? Doing that also hides the menu bar which I definitely don't want to do for a non game.

Ugh! Apple makes it so tough to configure a simple GUI these days!
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #6
AlStaffieri Wrote:Ugh! Apple makes it so tough to configure a simple GUI these days!

Gruff... Snort... These days? Simple GUI configuration has never been easier than it is now!

Quote:I hate apps that have windows that stay on top of the main window and you have to keep moving windows around to get to the part you want at any given time, but I guess because of the Dock issue there's no real way around that.
I still don't understand what you're trying to describe. What is "the Dock issue" exactly, and how does that relate to the app's main window being obscured by other windows?

If you mean apps with tool palettes/inspectors/whatever hovering over the app's main window and obscuring it, then I understand what you mean by that, but that really doesn't have anything to do with the dock. You just make a so-called "all-in-one" interface design, where tool palettes and stuff are integrated into your document window, not as floating utility windows.

Since you're running in windowed mode, definitely DO NOT touch the dock. Let the user deal with the dock as they please.

And again, don't rely on the user having their monitor set to anything or being compatible with a 1024x768 display because you simply cannot rely on that fact. You'll either have to allow the interface to grow and shrink and use scroll bars if it's obscured, or you can simply do hardware scaling (using a fixed aspect of 1.333), as I suggested above, for your main view in your main window.
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #7
Reading your posts some more, I think maybe I might get what you're saying a little better.

The modern user interface design is flexible so that it fits in whatever screen space is available. You have to ignore the Dock and just take what you get. Cocoa windows automatically scale themselves to fit inside the users screen space initially and during zoom, which means the windows will initially scale to be within the area not covered by the Dock. The all-in-one design I mentioned above will keep tool palettes organized in your window alongside your main view. And your main view must either be scalable or inside a scroll view. There is no real practical way of "forcing" the system or the user to deal with your insistence of having 1024x768 of space available just for your app. Flexibility is key here. It's not hard to do at all.
Quote this message in a reply
Member
Posts: 104
Joined: 2007.01
Post: #8
Agreed. There's no reason a windowed mode application shouldn't be resizeable - let the user decide how much real estate to give it. If you need a window client area of a certain size, then use scroll bars or allow the user to otherwise pan the window contents (like a hand grab tool, or whatever makes sense for your application).

The only time a windowed mode application doesn't necessarily need to be resizeable is if the window is fairly small, like 640x480 or maybe 800x600, where you know it will fit comfortably in most common desktop resolutions. Of course, a resizeable window is always preferred by users.
Quote this message in a reply
Post Reply