Whenever I launch my game in standalone mode or packaged, the game doesn't go fullscreen even if I press F11 (shortcut to fullscreen / windowed mode).
Here's a demo of the problem : youtube link
If I put in the console r.SetRes 1920x1080, then the game goes fullscreen (for a 1080p screen). But end-users can't access console.
What do I do to make it go fullscreen?
The problem lies within window's screen settings (tested on windows 10 & 11).
One option in window is called "resolution scaling". When this is not 100%, then the game will not cover the screen (if scale > 100) or zoom too much in the game (if scale < 100).
In UE, there's an option to automatically ajust the game to window's scale setting.
It's the "Allow High DPI in Game Mode" in the project settings (under Engine - User Interface). Check that to true and problem solved.
Related
I'm trying to create a window that is on the same level as the accessibility keyboard and notifications on High Sierra. My desired result is to get a window that will appear above all other windows, including the screensaver and lock screen.
In el cap/sierra I was able to use window.level = NSWindow.Level(Int(CGWindowLevelForKey(.maximumWindow))) but now in High Sierra my code does not work and I cannot see my window over the screensaver or lock screen.
After some experimenting I noticed that notifications and the accessibility keyboard DO show up over the lock screen/screensaver and was wondering if it is possible to create a window on the same level.
I've included two pictures, one of the lock screen showing both the keyboard/notification. The second image shows what happens when I transition from one window to another - my demo window stays on the desktop but the keyboard/notification is shown above the desktops and transitions over the dividing bar from one to another.
Anyone know of a way I can create this type of behavior in my window?
I'd like to be able to force the keyboard to show on screen in my Metro app. My goal is to test out different layouts/controls and get a feel for the interaction. My problem is that I'm running Win8 on a MacBook Pro (Parallels) and I don't know how to override the physical keyboard and show it on screen instead.
Similarly, I'd like to be able to force rotation if possible.
You could run your app the Simulator. You can put the Simulator in "Touch Mode" and that will interpret mouse clicks as touch events in the on screen controls like Text Boxes and you can choose to rotate the Simulator into profile as well.
When you have an app in fullscreen mode (in a fullscreen space) the menubar is hidden unless you "nudge" the top of the screen. However if you hit the spotlight hotkey the menubar politely shifts down into the screen with the spotlight search bar. Excellent.
I am migrating a statusbar/faceless application that I wish to have emulate this spotlight's menubar handling. Under snow leopard the app responds to a system hotkey by displaying a menu (it has a NSStatusBar item and I call popUpStatusItemMenu). Under Lion when the app is in fullscreen mode/space however, the menubar remains hidden for the fullscreen app (note however that the hot key IS bringing up the statusbar item and using the keyboard I can activate individual actions on the menu -- I just can't see the menu pop up).
To reiterate - anyone know how spotlight (under lion) displays the menubar in response to a hotkey? Or should I be asking when a better way to handle my UI would be under Lion?
thanks,
I feel reasonably certain that Spotlight is using private interfaces to change the presentation mode of the login session. You can change the presentation mode for an application using -[NSApplication setPresentationOptions:] (or the deprecated-but-still-available Carbon equivalent SetSystemUIMode()), but these explicitly only propagate to the login session from the “frontmost faceful application”.
I suggest filing a suggestion for an API to request that certain UI elements (menu bar, dock) are shown if they’re currently in autohide mode from the background.
I'm teaching myself Android (using a book) and I've downloaded Tea Vui Huang's Droid X skin for the using with the Android SDK in Eclipse. When I run the emulator, the top of the window showing the Droid X's screen runs off the top of my laptop screen. Is there anyway to make the skin smaller? This happens with the WVGA854 skin that comes with Android, too. Is this just the fact that the real Droid X screen is 854 pixels high, and my laptop is 768 high, and there's no way to "shrink" the Droid X emulator display?
There is a Windows trick that lets you move windows who's control bar has moved off screen. I thought I could use it to slide the Window up and down so I could sequentially see the top and bottom, e.g. to access the app-tray button at the bottom of the screen. Windows won't let me do this...once I start this trick, it won't let me leave the top of the window off-screen.
Any advice appreciated. Thanks.
You need to run it with -scale command line option.
I want to create a full Screen Cocoa application, however my app is slightly different from a conventional fullscreen app.
This app would be below everything else, so underneath the menu bar and the Dock, etc. It would have a large image covering up the Desktop and icons, with a custom NSView in the middle with a table view, etc. If this concept is hard to understand then here is an image:
http://img10.imageshack.us/img10/6308/mockupo.png
The only part that might be a bit confusing is the background image. This background image is NOT the wallpaper of the computer, but part of the app. So when the app is launched, it goes into full screen mode and puts itself underneath the dock and the menu bar, and underneath all other windows too. So it draws the background image to cover the screen (including Desktop and icons). Then has a custom NSView in the middle containing my controls.
What's the best way to go about doing this?
Thanks
Make a borderless window, the size of the menu-bar screen (screen 0—not [NSScreen mainScreen]), positioned at 0,0, with window level kCGDesktopWindowLevel.
Remember that you will need to observe for screen frame-change notifications (when the user changes the screen dimensions), and that you should correctly handle the case of no screen at all (headless Mac).
I think #Peter Hosey’s solution should work, but to make other windows go on top, you will probably need to change the window level to something else.
But, I implore you, do not do this. This will be the most bugly application the Macintosh has ever seen. There are a lot of really good user interface paradigms that you can use, and "replicating" the main desktop interface of Mac OS X is generally not one of them. That is, unless you are reimplementing Time Machine or something like that.