HUD goes off the screen in fullscreen mode on non-16:9 monitors about watanagashi HOT 46 OPEN

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.

from watanagashi.

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.

from watanagashi.

Try this and let us know if it works:
https://gist.githubusercontent.com/enumag/9881c28436039928a5bac13bdbe538e3/raw/fdebf05a7184f1d9325a44a03ee19d9b47dcc281/init.txt

Old issue about this problem: 07th-mod/onikakushi#95

from watanagashi.

It does appear to work though it ends up cropping all the backgrounds instead of letterboxing. Resetting the SetScreenAspect call fixes that but messes up the positioning when not fullscreen.

Based on those changes I made a full fix:
I added this function to MOD.Scripts.UI.MODMainUIController:

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 Assets.Scripts.UI.Config.ScreenSwitcherButton.OnClick():

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 OperationSetGuiPosition command (it should probably get its own though):

MODMainUIController mODMainUIController = new MODMainUIController();
mODMainUIController.AutoSetWindowPosX(fullscreen: Screen.fullScreen);

from watanagashi.

@TellowKrinkle Nice! Does it work with our normal init.txt or is the edited file still necessary?

from watanagashi.

The edited file is no longer necessary though if you do make AutoSetWindowPosX its own command it would need to be run from the init (it should be compatible with any aspect ratio)
Also I just did a bit more testing and it looks like the scaling number should be 384f, not 375f
Finally, I just checked and it looks like due to Screen.currentResolution working differently on Mac vs Windows, this code breaks on Windows. Use this instead for the large function:

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();
	}
}

from watanagashi.

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?

from watanagashi.

The added code should work for Mac as well, you could drop the check in the if. The !Screen.fullScreen check is to catch the case where the user fullscreens for the first time, since the PlayerPrefs may not be set yet at that point (and Screen.currentResolution works as expected on Windows as long as the window isn't already fullscreen). If this website is correct, the code (both implementations) might break on linux if you have multiple monitors, though the entire fullscreen system might also be broken there so if someone could test it that would be great.

from watanagashi.

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.

from watanagashi.

Ahh yeah here you go Assembly-CSharp.dll.zip

from watanagashi.

@TellowKrinkle Just to be clear, which chapter is that DLL for?

from watanagashi.

Watanagashi

from 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/onikakushi#177) with not just UI buttons but everything, including backgrounds being cut.

from watanagashi.

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 ~/.config/unity3d/MangaGamer/Watanagashi Full Game Name/player.log or something like that) and find the lines that say Detected Screen Resolution: ***x*** and Using Resolution ***x*** to set window position and report what it says?
Assembly-CSharp.dll.zip

from watanagashi.

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.

from watanagashi.

@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:

Detected Screen Resolution: 2560x1600
Fullscreen Resolution: 2560, 1600
Using Resolution 2560x1600 to set window positon
Using Resolution 2560x1600 to set window positon

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):
fs-from-start-no-crop.log
window-then-fs-crop.log

Main difference is

requesting resize 2560 x 1600
requesting resize 640 x 480
requesting resize 2560 x 1600

vs

requesting resize 2560 x 1525
requesting resize 2711 x 1525
requesting resize 2560 x 1600

(in the unrelated question, where do people get sysse05.ogg and how come I don't have it...)

from watanagashi.

Oh I see the issue
I didn't realize there were more ways to fullscreen than going into the config and pushing the fullscreen button. f doesn't run the repositioning code

from watanagashi.

Try this one Assembly-CSharp.dll.zip

from watanagashi.

@TellowKrinkle
Thanks, this one works correctly when just single display is connected.

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:

$ grep -i -e resolution -e resize Player.log
requesting resize 2560 x 1525
Detected Screen Resolution: 4480x1600
Fullscreen Resolution: 4480, 1600
Using Resolution 2560x1600 to set window positon
Using Resolution 2560x1600 to set window positon
requesting resize 2711 x 1525
Using Resolution 4480x1600 to set window positon
requesting resize 4480 x 1600
Using Resolution 4480x1600 to set window positon
requesting resize 1365 x 768
Using Resolution 4480x1600 to set window positon
requesting resize 4480 x 1600
Using Resolution 4480x1600 to set window positon
requesting resize 1365 x 768
Using Resolution 4480x1600 to set window positon
requesting resize 4480 x 1600
Using Resolution 4480x1600 to set window positon
requesting resize 1365 x 768

from watanagashi.

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 fullscreen_width_override and fullscreen_height_override in your config file (should be in the same folder as the log), the game will use that as the fullscreen resolution so if you have multiple monitors you can do that to get the desired resolution.
Assembly-CSharp.dll.zip

from watanagashi.

@TellowKrinkle
Thanks. This fix works (just to be clear, I don't have a need to run it with multiple monitors, just wanted to help with testing). The only catch I noticed is that code checks for fullscreen_height_override (or maybe both options) to be present, so setting only fullscreen_width_override doesn't work. Even through logically it's the only one that needs to be overridden, since nearly everyone would have displays side-by-side and thus only width would be incorrect, not height.

But when setting both overrides, they work just as expected for all kinds of fullscreen switching.

from watanagashi.

Ahh yeah I guess it is common to have symmetric multi display setups. This one checks the overrides separately Assembly-CSharp.dll.zip

from watanagashi.

@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/onikakushi#177) can get fixed with this.

from watanagashi.

The patch is coming 07th-mod/higurashi-assembly#1
You can test it now with this OniAssemblyCSharp.zip

from watanagashi.

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 Detected Resolutions: and post that. This DLL is for Onikakushi.
Onikakushi Assembly-CSharp.dll.zip
Edit: The game should print that once each time you fullscreen in addition to once at startup, so try full screening on each monitor to see if it actually figures out which monitor it's running on.

from watanagashi.

@TellowKrinkle Thanks.
The new patch doesn't work on multiple monitors; UI gets to large, relevant lines from log are:

requesting resize 2560 x 1525
Fullscreen Resolution: 4480, 1600
Using Resolution 2560x1600 to set window positon
requesting resize 2711 x 1525
Using Resolution 4480x1600 to set window positon
requesting resize 4480 x 1600
Using Resolution 4480x1600 to set window positon
requesting resize 1024 x 768

(no "detected resolution" lines)

Few things to note:

1. No changes to the old behaviour if launching directly in fullscreen, or going fullscreen right when first logos appear (before menu) - same left part of screen is black, UI in the middle. I suspect that your code doesn't activate yet for this case. Actually, it's more like image is "shifted" to the right, I need to move mouse cursor over black area and hotspot areas and clicks register way to the right to where cursor is actually showing.
2. When switching to fullscreen when some chapter is running (with "f" key) - as per log above - left part is no longer black and mouse cursor is fine. UI, however, is greatly stretched (like around 2X maybe), seemingly both in horizontal and vertical direction.

Additionally, regarding just a single monitor: issue 07th-mod/onikakushi#177 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.

from watanagashi.

Are you sure you're not still looking at the Watanagashi debug log? The new dll shouldn't print Using Resolution ###x### to set window position at all

from watanagashi.

@TellowKrinkle
Ooh, I'm really sorry, I was testing the first version you posted for Onikakushi, not the later one with the fix.
I've tested the correct version now and UI in fullscreen is fixed for the larger 2560x1600 screen but is still wrong when going fullscreen on 1920x1080 screen.

Relevant lines from log on the larger screen where UI is correct:

requesting resize 2560 x 1525
resizing window to 2560 x 1525
Desktop is 4480 x 1600 @ 60 Hz
Detected Resolutions:
(a very long list here that lists resolutions up to 3440x1440)

Using resolution 2560x1600 as the fullscreen resolution.
Fullscreen Resolution: 4480, 1600
requesting resize 2711 x 1525
resizing window to 2711 x 1525
Desktop is 4480 x 1600 @ 60 Hz
Detected Resolutions:
(a very long list here that lists resolutions up to 3440x1440)

Using resolution 2560x1600 as the fullscreen resolution.
Detected Resolutions:
(a very long list here that lists resolutions up to 3440x1440)

Using resolution 2560x1600 as the fullscreen resolution.
requesting resize 2560 x 1600
Desktop is 4480 x 1600 @ 60 Hz
Changing real window size to 2560 x 1600
Ignoring window size change to 2560x1600 : waiting for fullscreen at 2560x1600
requesting resize 1024 x 768
resizing window to 1024 x 768
Desktop is 4480 x 1600 @ 60 Hz

Lines from the log on 1920x1080 screen, UI goes off the screen:

requesting resize 1024 x 768
resizing window to 1024 x 768
Desktop is 4480 x 1600 @ 60 Hz
Detected Resolutions:
(same very long list)

Using resolution 2560x1600 as the fullscreen resolution.
Fullscreen Resolution: 4480, 1600
requesting resize 1365 x 768
resizing window to 1365 x 768
Desktop is 4480 x 1600 @ 60 Hz
Detected Resolutions:
(same very long list)

Using resolution 2560x1600 as the fullscreen resolution.
Detected Resolutions:
(same very long list)

Using resolution 2560x1600 as the fullscreen resolution.
requesting resize 2560 x 1600
Desktop is 4480 x 1600 @ 60 Hz
Changing real window size to 1920 x 1080
Ignoring window size change to 1920x1080 : waiting for fullscreen at 2560x1600
requesting resize 1024 x 768
resizing window to 1024 x 768
Desktop is 4480 x 1600 @ 60 Hz

The only difference between the logs is

-Changing real window size to 2560 x 1600
-Ignoring window size change to 2560x1600 : waiting for fullscreen at 2560x1600
+Changing real window size to 1920 x 1080
+Ignoring window size change to 1920x1080 : waiting for fullscreen at 2560x1600

Here is full list after each "Detected Resolutions:" line:

Detected Resolutions:
640x480
720x480
768x480
800x480
854x480
960x540
1024x576
800x600
1024x600
960x640
1024x640
1136x640
960x720
1152x720
1280x720
1024x768
1152x768
1280x768
1366x768
1280x800
1152x864
1280x864
1440x900
1600x900
1280x960
1440x960
1280x1024
1600x1024
1400x1050
1680x1050
1920x1080
2560x1080
2048x1152
1600x1200
1920x1200
1792x1344
1856x1392
1920x1440
2160x1440
2304x1440
2560x1440
3440x1440
2048x1536
2560x1600

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.

from watanagashi.

I doubt this will fix it but could you try running this one? It should print out something like Requesting window size ###x### based on config file if you start the game non-fullscreen. Does that request 1365x768 as you'd expect?
Onikakushi Assembly-CSharp.dll.zip
Edit: Also it'll no longer print the giant list of resolutions so don't expect that to be there

from watanagashi.

@TellowKrinkle
No, unfortunately it doesn't help. The log is like this:

Requesting window size 1024x768 based on config file
Using resolution 2560x1600 as the fullscreen resolution.
Fullscreen Resolution: 2560, 1600
requesting resize 1024 x 768
resizing window to 1024 x 768
Desktop is 2560 x 1600 @ 60 Hz
requesting resize 1365 x 768
resizing window to 1365 x 768
Desktop is 2560 x 1600 @ 60 Hz

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

	<pref name="Screenmanager Resolution Height" type="int">1525</pref>
	<pref name="Screenmanager Resolution Width" type="int">2560</pref>

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:

<unity_prefs version_major="1" version_minor="1">
	<pref name="Screenmanager Is Fullscreen mode" type="int">1</pref>
	<pref name="Screenmanager Resolution Height" type="int">1600</pref>
	<pref name="Screenmanager Resolution Width" type="int">2560</pref>
	<pref name="UnitySelectMonitor" type="int">-1</pref>
	<pref name="fullscreen_height" type="int">1600</pref>
	<pref name="fullscreen_width" type="int">2560</pref>
	<pref name="height" type="int">768</pref>
	<pref name="width" type="int">1365</pref>

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)

<unity_prefs version_major="1" version_minor="1">
	<pref name="Screenmanager Is Fullscreen mode" type="int">0</pref>
	<pref name="Screenmanager Resolution Height" type="int">1525</pref>
	<pref name="Screenmanager Resolution Width" type="int">2560</pref>
	<pref name="UnitySelectMonitor" type="int">-1</pref>
	<pref name="fullscreen_height" type="int">1600</pref>
	<pref name="fullscreen_width" type="int">2560</pref>
	<pref name="height" type="int">768</pref>
	<pref name="width" type="int">1365</pref>

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.

from watanagashi.

Does this work?
Onikakushi Assembly-CSharp.dll.zip

from watanagashi.

@TellowKrinkle
It's better and gets rid of the fullscreen bug, however introduces a new window bug. The values are now locked e.g. at 640x480, despite 16:9 aspect ratio requesting different resolution. So on the next launches window will be 4:3 and the all window content is cropped - it will be resized if it's launched in window, but if launched in fullscreen and going back to window, it will be cropped.

E.g. first launch, then go to fullscreen, then quit. Prefs look like this:

<unity_prefs version_major="1" version_minor="1">
	<pref name="Screenmanager Is Fullscreen mode" type="int">1</pref>
	<pref name="Screenmanager Resolution Height" type="int">480</pref>
	<pref name="Screenmanager Resolution Width" type="int">640</pref>
	<pref name="UnitySelectMonitor" type="int">-1</pref>
	<pref name="fullscreen_height" type="int">1600</pref>
	<pref name="fullscreen_width" type="int">2560</pref>
	<pref name="height" type="int">480</pref>
	<pref name="width" type="int">640</pref>

Launch again, switch to window - and you get 640x480 window with cropped contents. The original version avoids this by setting

	<pref name="Screenmanager Resolution Height" type="int">480</pref>
	<pref name="Screenmanager Resolution Width" type="int">853</pref>

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).

from watanagashi.

All right how about this one? Onikakushi Assembly-CSharp.dll.zip

from watanagashi.

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.

from watanagashi.

@TellowKrinkle Yes, much better now, thanks.
Somehow I managed to semi-break it once: with empty prefs, I switched fullscreen and back with "f" key before "07th Expansion" logo appears - you know, there is ADV mode UI displayed for a short time before the logo, and switching to fullscreen works. Well after doing that I somehow got oversized 2560x1600 window with UI going off screen in window. But the setting did not stick and it was OK on the next launch, also I wasn't able to reproduce this any more times.

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

xwininfo: Window id: 0x5c00002 "Higurashi When They Cry - Ch.1 Onikakushi"

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 2560
  Height: 1600
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x5c00001 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: Always
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -1920+0  -1920-0  +0-0
  -geometry 2560x1600+0+0

and second one

xwininfo: Window id: 0x5c00002 "Higurashi When They Cry - Ch.1 Onikakushi"

  Absolute upper-left X:  2560
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1920
  Height: 1080
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x5c00001 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: Always
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +2560+0  -0+0  -0-520  +2560-520
  -geometry 1920x1080-0+0

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.

from watanagashi.

@TellowKrinkle
Hm looks like I commented too early. Was toying with it a bit more and found few minor problems. First of all, I got that "oversized window" and associated bugs like backgrounds cropping once again. I'm not quite sure what I did, maybe it involved quitting while at fullscreen and then going fullscreen and back. However, this bug does not stick and on the next restart window will be just fine. Prefs looks like this during this bug:

<unity_prefs version_major="1" version_minor="1">
	<pref name="Screenmanager Is Fullscreen mode" type="int">0</pref>
	<pref name="Screenmanager Resolution Height" type="int">480</pref>
	<pref name="Screenmanager Resolution Width" type="int">853</pref>
	<pref name="UnitySelectMonitor" type="int">-1</pref>
	<pref name="fullscreen_height" type="int">1600</pref>
	<pref name="fullscreen_width" type="int">2560</pref>
	<pref name="height" type="int">480</pref>
	<pref name="is_fullscreen" type="int">0</pref>
	<pref name="width" type="int">853</pref>
</unity_prefs>

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):

<unity_prefs version_major="1" version_minor="1">
	<pref name="Screenmanager Is Fullscreen mode" type="int">0</pref>
	<pref name="Screenmanager Resolution Height" type="int">480</pref>
	<pref name="Screenmanager Resolution Width" type="int">853</pref>
	<pref name="UnitySelectMonitor" type="int">-1</pref>
	<pref name="fullscreen_height" type="int">1600</pref>
	<pref name="fullscreen_width" type="int">2560</pref>
	<pref name="height" type="int">480</pref>
	<pref name="is_fullscreen" type="int">1</pref>
	<pref name="width" type="int">853</pref>
</unity_prefs>

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/onikakushi#177 (comment)). 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.

from watanagashi.

Onikakushi Assembly-CSharp.dll.zip
How about this one?
BTW I assume the issue does not happen if you start non-fullscreen and then fullscreen?

from watanagashi.

@TellowKrinkle
The issue is fixed on Linux now! However, it's still present on Windows.

BTW I assume the issue does not happen if you start non-fullscreen and then fullscreen?

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?
output_log.txt
It has a strange line "Using resolution 314x189 as the fullscreen resolution."

Config in registry looks like this:

[HKEY_CURRENT_USER\Software\MangaGamer\Higurashi When They Cry - Ch.1 Onikakushi]
"Screenmanager Resolution Width_h182942802"=dword:00000b40
"Screenmanager Resolution Height_h2627697771"=dword:00000780
"Screenmanager Is Fullscreen mode_h3981298716"=dword:00000001
"width_h191264035"=dword:00000555
"height_h1581003770"=dword:00000300
"fullscreen_width_h4277028835"=dword:00000b40
"fullscreen_height_h3561643322"=dword:00000780
"is_fullscreen_h120221215"=dword:00000001

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.

from watanagashi.

Could you report the debug log from this one?
Onikakushi Assembly-CSharp.dll.zip

from watanagashi.

Here you go: output_log.txt

from watanagashi.

Hmm okay
This should fix that issue but it might cause issues with multi monitor setups
Onikakushi Assembly-CSharp.dll.zip
If it does fix that issue, could you try running it on the smaller monitor of a Windows multi monitor setup and tell me what it prints after Detected Resolutions?

from watanagashi.

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.

from watanagashi.

(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)
Also it's interesting that it still breaks even though it only ever requests 2880x1920. Let me see if I can reproduce it on my computer under Windows.

from watanagashi.

Alright try this one @vstax
Onikakushi Assembly-CSharp.dll.zip

from watanagashi.

@TellowKrinkle
Windows is fixed in single-monitor configuration now, thanks!

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

Using resolution 2560x1600 as the fullscreen resolution.
Fullscreen Resolution: 2560, 1600
Using resolution 2560x1600 as the fullscreen resolution.

(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.

from watanagashi.

Hmm...
It definitely is unexpected, but I can't think of anything that would cause this other than Unity being stupid (which admittedly has been the cause of almost all these issues). Unity does appear to have a Displays API, which lets you get a list of the displays connected to the computer, but has no way of indicating which one contains the game window. The docs for Unity 2018 indicate an active property, which might do what we want, but it doesn't appear to exist in our version of Unity so I guess it doesn't matter whether it does or doesn't do what we want.

from watanagashi.