HUD goes off the screen in fullscreen mode on non-16:9 monitors #87
Comments
|
Since this is a non-standard resolution, it would be hard to reproduce the issue in our end, but if I recall correctly we have received a few issues regarding this and there was a fix for it. @enumag should be able to help you better, I think he has the resources needed in hand. |
|
This can be fixed by tweaking some values in init.txt. The problem is that I no longer have a file that worked well with 16:10 because I've bought 16:9 monitor a year ago or so. I'll try to find it in my backups but I can't promise I will. |
|
Try this and let us know if it works: Old issue about this problem: 07th-mod/onikakushi#95 |
|
It does appear to work though it ends up cropping all the backgrounds instead of letterboxing. Resetting the Based on those changes I made a full fix: public void AutoSetWindowPosX(bool fullscreen) {
float aspectRatio = GameSystem.Instance.AspectRatio;
if (fullscreen) {
aspectRatio = Screen.currentResolution.width / (float)Screen.currentResolution.height;
}
float differenceFrom43 = aspectRatio - (4f / 3f);
int adjustment = Mathf.RoundToInt(differenceFrom43 * 375f);
ADVModeWindowPosX = -adjustment;
NVLModeWindowPosX = -adjustment;
NVLADVModeWindowPosX = -adjustment;
GameSystem.Instance.MainUIController.UpdateGuiPosition(adjustment, 0);
if (BurikoMemory.Instance.GetGlobalFlag("GADVMode").IntValue() == 1) {
ADVModeSettingStore();
} else {
NVLModeSettingStore();
}
}Then I added this to the end of MOD.Scripts.UI.MODMainUIController controller = new MOD.Scripts.UI.MODMainUIController();
controller.AutoSetWindowPosX(fullscreen: IsFullscreen);And finally, I couldn't figure out how to add a new custom command to the script system so I added this to the end of the MODMainUIController mODMainUIController = new MODMainUIController();
mODMainUIController.AutoSetWindowPosX(fullscreen: Screen.fullScreen); |
|
@TellowKrinkle Nice! Does it work with our normal init.txt or is the edited file still necessary? |
|
The edited file is no longer necessary though if you do make public void AutoSetWindowPosX(bool fullscreen) {
float aspectRatio = GameSystem.Instance.AspectRatio;
if (fullscreen) {
if (!Screen.fullScreen || Application.platform == RuntimePlatform.OSXPlayer) {
aspectRatio = Screen.currentResolution.width / (float)Screen.currentResolution.height;
} else if (PlayerPrefs.HasKey("fullscreen_width") && PlayerPrefs.HasKey("fullscreen_height")) {
aspectRatio = PlayerPrefs.GetInt("fullscreen_width") / (float)PlayerPrefs.GetInt("fullscreen_height");
}
}
float differenceFrom43 = aspectRatio - (4f / 3f);
int adjustment = Mathf.RoundToInt(differenceFrom43 * 384f);
ADVModeWindowPosX = -adjustment;
NVLModeWindowPosX = -adjustment;
NVLADVModeWindowPosX = -adjustment;
GameSystem.Instance.MainUIController.UpdateGuiPosition(adjustment, 0);
if (BurikoMemory.Instance.GetGlobalFlag("GADVMode").IntValue() == 1) {
ADVModeSettingStore();
} else {
NVLModeSettingStore();
}
} |
|
Does the code you added for windows work for mac too or do we really need the if? Also any idea which implementation would work on linux? |
|
The added code should work for Mac as well, you could drop the check in the if. The |
|
I can test on Linux with multiple monitors having different resolution and aspect ratios, one 16:10 and other 16:9 (in expand desktop mode). However, I have no idea how you build from that source so a compiled library is appreciated. |
|
Ahh yeah here you go Assembly-CSharp.dll.zip |
|
@TellowKrinkle Just to be clear, which chapter is that DLL for? |
|
Watanagashi |
|
@TellowKrinkle The fix doesn't work for me on Linux even with single monitor having 2560x1600 resolution. HUD goes off the screen in fullscreen, just like with .dll from the release. Also, can you please check Onikakushi? The situation there is much more severe on my system (07th-mod/higurashi-assembly#133) with not just UI buttons but everything, including backgrounds being cut. |
|
So it doesn't work with a single monitor connected to your computer that's 2560x1600? Could you run the game with this DLL, go fullscreen at least once, and then open the log (somewhere around |
|
Weirdly, when I tried it in Ubuntu 18.04, the UI positioning worked properly but the game freezes for like 10 seconds on launch. When my friend tried it on his computer running Fedora 28, even without mods, it crashed his window manager and sent him back to the login screen. |
|
@TellowKrinkle The freeze on very first launch is normal and happens because it's compiling scripts. It happens on every OS and system. Running Fedora 28 here, AMD GPU, open source driver, no crashes at all. This is what in log: UI is cropped. Actually I somehow managed to make UI not look cropped, and the only way to do it is to force game to launch in fullscreen from the very start and never go to window mode. Then UI won't be cropped. However, when starting game normally (in window), then loading game or just starting a chapter (and skipping first few screens until text appears), then pressing "f" to go fullscreen - UI will be cropped. I'm attaching log files from both runs just in case (because lines above that you asked about seem to be the same): Main difference is vs (in the unrelated question, where do people get sysse05.ogg and how come I don't have it...) |
|
Oh I see the issue |
|
Try this one Assembly-CSharp.dll.zip |
|
@TellowKrinkle Regarding two displays, you are quite right, it's completely broken. On either screen, when going fullscreen roughly 1/3 of the screen on the left is black, and in 2/3 on the right you can see left part of the game window, the rest is completely cut. I tried going fullscreen both on left desktop (2560x1600) and the one to the right (1920x1080) and it looks the same on both. Here are all related lines from log: |
|
I couldn't find any good way to get the fullscreen resolution on Linux if you have multiple monitors, so here's the workaround: With this dll, if you set the keys |
|
@TellowKrinkle But when setting both overrides, they work just as expected for all kinds of fullscreen switching. |
|
Ahh yeah I guess it is common to have symmetric multi display setups. This one checks the overrides separately Assembly-CSharp.dll.zip |
|
@TellowKrinkle Any chance that you will merge this fix into all versions? I'm really interested in checking if Onikakushi background cropping bug (07th-mod/higurashi-assembly#133) can get fixed with this. |
|
The patch is coming 07th-mod/higurashi-assembly#1 |
|
Actually @vstax could you test this build with multiple monitors? I found a new way to get resolutions which might work on a linux multimonitor setup. Run the game, and then search the logs for |
|
@TellowKrinkle Thanks. (no "detected resolution" lines) Few things to note:
Additionally, regarding just a single monitor: issue 07th-mod/higurashi-assembly#133 got slightly better but is still present. To be precise, UI isn't cropped anymore and displayed correctly in fullscreen. However, backgrounds are still badly cropped and associated effects like vertical scrolling are broken as well. |
|
Are you sure you're not still looking at the Watanagashi debug log? The new dll shouldn't print |
|
@TellowKrinkle Relevant lines from log on the larger screen where UI is correct: Lines from the log on 1920x1080 screen, UI goes off the screen: The only difference between the logs is Here is full list after each "Detected Resolutions:" line: Regarding the bug with stretched backgrounds in Onikakushi, I've noticed something.. For some reason I have game window at very large resolution (2560 x 1525 apparently), and buttons to go 640x480 etc don't do anything. I'm unable to manually resize the window as well. When I go fullscreen from such window, the backgrounds are stretched. However, during the last experiment when going fullscreen on smaller display and back, on restart the game somehow launched in 1024x768 window (well not really, it was 16:9 aspect ratio window, but the game declares it as "1024x768" one). And when I was going fullscreen and back from that window, backgrounds weren't stretched anymore! Unfortunately, on the next launch the game went back to that oversized window and the bug has returned. Anyhow, the point it is that bugs with window being stuck up at near-fullscreen resolution and background stretch are related. |
|
I doubt this will fix it but could you try running this one? It should print out something like |
|
@TellowKrinkle And the window is still oversized. Also, if I press buttons "640x480" etc in the options, I can see that window switches to proper size very fast and then goes right back to oversized one (it happens instantly, like for single frame only. Maybe the window doesn't resize at all and only image in it does, for a single frame). Note that my "prefs" file contains Basically this bug happens like this. On the very first launch (or without prefs file), the screen is OK. I can also manually set "Screenmanager Resolution Height" to 768 and "Screenmanager Resolution Width" to 1024 and on the next run it'll start as 1024x768, almost instantly resizing to 1365x768. Going fullscreen and back - there will be no bug. If I exit game while in window, everything will be OK. However, if I exit it during fullscreen, the prefs file will look like this: On the next launch the game will be in fullscreen. If I go back to window at this point, I'll get that oversized window. And the background stretching bug will be here from now on. If I exit the game now (in window), the prefs will look like this: (EDIT: pasted a wrong file here at first) And there you go, no way to fix things without wiping or manually editing prefs file at this point, the bug will be always be present. Does this make any sense? I think if it could be changed that "Screenmanager Resolution Height/Width" would always at the same values as height/width and not change to "fullscreen_height/fullscreen_width" values the bug should be gone. |
|
Does this work? |
|
@TellowKrinkle E.g. first launch, then go to fullscreen, then quit. Prefs look like this: Launch again, switch to window - and you get 640x480 window with cropped contents. The original version avoids this by setting Also, the fix doesn't work if the bug has already occurred and "Screenmanager Resolution Height/Weight" is at high values like 1525/2560, but it's probably beyond the scope of this fix (I suppose that advice about removing prefs in FAQ or something would do fine). |
|
All right how about this one? Onikakushi Assembly-CSharp.dll.zip |
|
Oh I guess I should mention, the Screenmanager variables are Unity's, not ours, and it loads them and breaks itself before the game code has a chance to do anything. The fix works by changing them right as the app quits, so that the next time it loads they'll be fine, but that does mean that if the bug has already occurred and you update to this patch, you'll have to restart the game once to have the fix applied. |
|
@TellowKrinkle Yes, much better now, thanks. Other than this minor thing, it works very well now. The know remaining bugs are fullscreen on smaller screen in multi-monitor setup. In case you interested, here is what xwininfo output looks like when going fullscreen on first screen and second one Linux treats 2560x1600+1920x1080 multi-monitor setup as 4480x1600 screen, with black (invisible) 1080x520 area in the bottom right - it can be seen as black when taking screenshot, for example. However, when going true fullscreen or just maximizing borderless window (like unity does here, from what I can see) on the second screen, it correctly gets 1920x1080 size. It's just the game itself that renders internally at some higher resolution in that window and gets its image cut. |
|
@TellowKrinkle Second, I got backgrounds cropping bug even without going to window or other tricks. I had this config (seems perfectly normal, I didn't change anything in here, just quit the game): The game starts in fullscreen with it. After that, load or start game and backgrounds will be cropped. ADV window as well: I'm attaching Player.log: Player.log Also note that this bug was present originally, before any of your changes and it was present on Windows as well (07th-mod/higurashi-assembly#133). Switching to window and back fixes background crop, but it will return on the next launch as long as the game was exited while in fullscreen. |
|
Onikakushi Assembly-CSharp.dll.zip |
|
@TellowKrinkle
Right, this way everything is correct on both platforms. Note that on Linux I can always see briefly see game window and then it switches to fullscreen. On Windows, during first stages there are no window (just icon in the task bar), then game starts in fullscreen. Or at least I can see no window at all. On Windows, the very first screen showing ADV mode UI (that appears briefly before the logo) is already cut, and the menu is cut as well. Maybe this output.log will be of help? Config in registry looks like this: Basically that's 2880x1920 which is screen native 3:2 resolution in both "screenmanager" and just fullscreen options. I've tried wiping it, it always returns to these values with the latest .dll. Numbers in value names are random or something, I think; they change each time I remove the option. |
|
Could you report the debug log from this one? |
|
Here you go: output_log.txt |
|
Hmm okay |
|
No, unfortunately new version has no improvement. Few lines disappeared from log: output_log.txt but the problem is the same. What do you mean by "smaller monitor"? I suppose I can find some other windows setup, including multi-monitor one, but it will have to wait some. |
|
(I just meant similar to how you when you tried on the linux multi-monitor and it broke on the smaller of the two monitors, try the same thing in Windows) |
|
Alright try this one @vstax |
|
@TellowKrinkle Regarding multi-monitor on windows. The main problem is that the window switches monitor when going fullscreen. Normally (nearly always, the only exception are some very rare games that have special setting in options to pick not only fullscreen resolution but also the monitor to go fullscreen on), applications go fullscreen on the same monitor where the window was. However, here fullscreen window always appears on the monitor specified as main one when pressing "f", even when the window was on the different one - which is a bug. This works correctly on Linux, btw. Anyhow, there are no displays bugs when it goes fullscreen on that main monitor - regardless the monitor where the window was. However, if trying to trick the game into going fullscreen on the required monitor by switching "main monitor" after the game launched, the game will go fullscreen on the monitor we need it to be, but if it's a different one, UI will be broken. E.g. launching game in window when smaller 1920x1080 monitor was the main one. Switching main one to larger 2560x1600 one. Going fullscreen - the game will show 2560x1600 window on larger monitor but everything will be rendered inside 1920x1080 area. Launching game in window when larger 2560x1600 was main one. Switching main one to smaller 1920x1080 one. Going fullscreen - the picture will be cut as it's rendered at 2560x1600 internally. For the later case, only lines like (no mention of 1920x1080 at all) will be in logs. It's up to you to decide if this is worth fixing or not... However, at least the first part - where fullscreen image always appear on the main monitor, not the one with the window - is certainly unexpected behaviour. |
|
Hmm... |
If you fullscreen on a non-16:9 monitor, for example, the (16:10, 2880x1800, though the game treats it as 1440x900) internal display of a MacBook Pro, the main background and text letterboxes as you would expect, however the HUD (part which supplies buttons for quick save, quick load, menu, log, skip, and auto) positions itself as if the game had been zoomed in to fill the display, putting the four right-edge buttons (menu, log, skip, auto) completely offscreen. Watanagashi is the first game I noticed this on (since it's the first game I played patched) but I would guess it also happens on the other games.
Screenshot:
The text was updated successfully, but these errors were encountered: