Hi,
I posted a widget that I am working on and got feedback that the sides of the game are getting cut-off when in full-screen mode on some monitors. I have attempted a fix at that and would like to know if it is working or not. If people could test it and let me know if it looks right that would be great!
It should look basically the same in fullscreen as in regular mode, so like the picture below.
If you are experiencing a cut-off play area or other problem, I’d be very grateful if you would let me know that and what you monitor’s full screen resolution is.
Thanks!
it works fine here (imac) - i imagine its the 4:3 that’s the issue.
i didn’t get to post in your last thread but just wanted to say the UI tweaks you added work look great ; )
one other thing - at the end of the levels there’s something going on where the text image is sporadic sometimes - IMO i’d make it so you don’t have to click for that screen to come up - when the last arrow hits maybe have it appear automatically.
Bummer. Well, I have added a hack to hopefully solve the problem, though not in the most ideal way. In full screen mode, the user should now be able to adjust the size of the game window by using the + and - keys. Please let me know how this works.
Certainly, thanks. It will be in a few days hopefully. It won’t be as polished as I’d like it to be, but I have got a bit of a time crunch with other things and want to get it done for the initial release soon.
Thanks for the feedback. The level end text is time-based. Changing that to work as you suggested is on my list but might not make it into the first release.
Unfortunately it doesn’t…the keys have no effect. However I do get the alert sound when I press them, so I wonder if the focus is getting lost when switching to full-screen. But the other controls work even though I get the alert sound with the space bar as well (but not the arrow keys…odd). I can see just enough of the archer to see that the aiming movement is apparently frame-rate dependent, as moving the bow up/down is way faster in full-screen mode compared to windowed mode. Also I discovered that pressing the space bar before the game has begun gives me an unexpectedly quit dialog, even though the widget continues to run fine. I’m guessing that’s a null reference exception.
Big bummer. Back to the drawing (or maybe by the now “beating my head on the diplay”) board. Just to be clear, do you mean that the arrow keys don’t do anything or they don’t cause the alert sound? Nice find on the space key. I’ll see if I can figure out what’s going on there.
Thank you for being full of good testing!!!
OK. I’ve found most of the keys cause the alert in a Unity widget in fullscreen mode. I changed the shoot key to control which does not cause the alert.
Also, I THINK (HOPE?!!) I have the issue fixed with zooming the screen in fullscreen (still using the ± keys though which cause the alert sound).
Eric, would you mind giving it yet another test?
BTW, I also added some ambient sound and a personalized widget back.
Not only do the + and - keys work now, but amazingly enough the sides aren’t cut off anymore so maybe they’re not even necessary. (But probably a good idea to keep them just in case…)
The only remaining problem I could find is that I got another instance of “level ends for no apparent reason right after starting”. I think that was after level 3. Other than that it seems quite solid now.
Yikes!!! Does that mean it restarted automatically? Sounds dangerous - and I was getting ready to release it once the levels issues was fixed…
Here’s the script on the camera. Anyone know what might be causing StarManta’s hard reset? Something volatile in the script below? Some undiscovered Unity bug? Aliens conspiring against my widget release?
BTW, I hope the hard reset didn’t do any damage or cause you to lose any work!
var camOSize1 = 15.0;
//these are all set manually in the editor
var camOSize2 = 10.0;
var camOSize3 = 10.0;
var camOSize4 = 10.0;
var camOSize5 = 10.0;
var camOSize6 = 10.0;
function Update () {
if (Screen.width < 800) {
camera.orthographicSize = camOSize6;
if (Input.GetKey("=") || Input.GetKey("[+]")) {
camOSize6 -= 0.2;
}
if (Input.GetKey("-") || Input.GetKey("[-]")) {
camOSize6 += 0.2;
}
}
if (Screen.width > 800) {
if (camera.aspect > 1.5 camera.aspect <= 1.6) {
print ("16:10");
camera.orthographicSize = camOSize2;
if (Input.GetKey("=") || Input.GetKey("[+]")) {
camOSize2 -= 0.2;
}
if (Input.GetKey("-") || Input.GetKey("[-]")) {
camOSize2 += 0.2;
}
}
if (camera.aspect > 1.6) {
print ("16:9");
camera.orthographicSize = camOSize3;
if (Input.GetKey("=") || Input.GetKey("[+]")) {
camOSize3 -= 0.2;
}
if (Input.GetKey("-") || Input.GetKey("[-]")) {
camOSize3 += 0.2;
}
}
if (camera.aspect > 1.35 camera.aspect <= 1.5) {
print ("3:2");
camera.orthographicSize = camOSize4;
if (Input.GetKey("=") || Input.GetKey("[+]")) {
camOSize4 -= 0.2;
}
if (Input.GetKey("-") || Input.GetKey("[-]")) {
camOSize4 += 0.2;
}
}
if (camera.aspect > 1.25 camera.aspect <= 1.35) {
print ("4:3");
camera.orthographicSize = camOSize5;
if (Input.GetKey("=") || Input.GetKey("[+]")) {
camOSize5 -= 0.2;
}
if (Input.GetKey("-") || Input.GetKey("[-]")) {
camOSize5 += 0.2;
}
}
if (camera.aspect > 1.0 camera.aspect <= 1.25) {
print ("5:4");
camera.orthographicSize = camOSize6;
if (Input.GetKey("=") || Input.GetKey("[+]")) {
camOSize6 -= 0.2;
}
if (Input.GetKey("-") || Input.GetKey("[-]")) {
camOSize6 += 0.2;
}
}
}
if (Screen.width == 800) {
if (Screen.fullScreen == false) {
camera.orthographicSize = camOSize1;
}
if (Screen.fullScreen == true) {
camera.orthographicSize = camOSize6;
if (Input.GetKey("=") || Input.GetKey("[+]")) {
camOSize6 -= 0.2;
}
if (Input.GetKey("-") || Input.GetKey("[-]")) {
camOSize6 += 0.2;
}
}
}
}
I have an idea that it might be the viewport of the camera. When you set it to not use the full screen, there still should be something behind it to render, or else you can get graphical junk in certain circumstances instead of black, and apparently worse than just graphical junk in StarManta’s case. So make a full-screen camera with a black background and a culling mask of nothing (so it doesn’t waste time rendering anything), and put this on a layer behind the main camera. You can also make the clear flag of the main camera be “don’t clear”, which seems to increase the fps a little.
Thanks for the tips! I don’t understand too much about the camera issues. I am trying this stuff out but won’t be able to test it unless I am able at some point to run the game on a Mac that is similar enough to StarMantas to have the same problem. I have tested the widget on two macs (Intel iMac and G3 iBook) without a problem and will hopefully be able to test on a couple more today.
One thing though, when I set the main camera’s clear flag to “don’t clear” I get a fun little effect as shown below but not something I am looking for.
Thanks again for the advice. Hopefully a second camera will fix things.
You only want to set the flag to “don’t clear” if you’re using another camera behind (which is not set to “don’t clear”), or else you get results like that.
Sorry, two questions.
By a “fullscreen” camera, do you mean I should have the extra camera set to fullscreen through scripting(Screen.fullScreen = true)?
By “on a layer behind the main camera”, do you mean have it in a layer with a higher number than the main camera (the main camera is in the “default” layer so I would put the extra camera in Layer 9 or something) or do you mean give it a lower “depth” number? I haven’t done much with cameras but the obvious so I am kind of clueless here.
Thanks for taking the time to help me with this!
