Bows Widget Game Fullscreen Fix - Please Test!

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 on my monitor. I went fullscreen and nothing was cut off.

 

Still cut off here. I'm using a 4:3 CRT...looks like it's using 640x480 when it switches to full-screen though I'm not completely sure.

--Eric

 

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.

 

Perfect on my iMac as well. Nice updates btw. I'll be more than happy to post it on WMG when you feel it's ready for public consumption.

 

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.

Just full of good news, aren't I?

--Eric

 

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!!!

 

They don't cause the alert sound...at least they work fine.

--Eric

 

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.

--Eric

 

.......UM.


I was playing with the widget. The instant I clicked the fullscreen button, my Macbook hard reset.

I've never had any program do that to a Mac before; hell I didn't think it was even possible. Thoughts?

 

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!

Code (csharp):

1. var camOSize1 = 15.0;
2. //these are all set manually in the editor
3. var camOSize2 = 10.0;
4. var camOSize3 = 10.0;
5. var camOSize4 = 10.0;
6. var camOSize5 = 10.0;
7. var camOSize6 = 10.0;
8.  
9. function Update () {
10.         if (Screen.width < 800) {
11.                 camera.orthographicSize = camOSize6;
12.                 if (Input.GetKey("=") || Input.GetKey("[+]")) {
13.                     camOSize6 -= 0.2;
14.                 }
15.                 if (Input.GetKey("-") || Input.GetKey("[-]")) {
16.                     camOSize6 += 0.2;
17.                 }
18.             }
19.         if (Screen.width > 800) {
20.             if (camera.aspect > 1.5  camera.aspect <= 1.6) {
21.                 print ("16:10");
22.                 camera.orthographicSize = camOSize2;
23.                 if (Input.GetKey("=") || Input.GetKey("[+]")) {
24.                     camOSize2 -= 0.2;
25.                 }
26.                 if (Input.GetKey("-") || Input.GetKey("[-]")) {
27.                     camOSize2 += 0.2;
28.                 }
29.             }
30.             if (camera.aspect > 1.6) {
31.                 print ("16:9");
32.                 camera.orthographicSize = camOSize3;
33.                 if (Input.GetKey("=") || Input.GetKey("[+]")) {
34.                     camOSize3 -= 0.2;
35.                 }
36.                 if (Input.GetKey("-") || Input.GetKey("[-]")) {
37.                     camOSize3 += 0.2;
38.                 }
39.             }
40.             if (camera.aspect > 1.35  camera.aspect <= 1.5) {
41.                 print ("3:2");
42.                 camera.orthographicSize = camOSize4;
43.                 if (Input.GetKey("=") || Input.GetKey("[+]")) {
44.                     camOSize4 -= 0.2;
45.                 }
46.                 if (Input.GetKey("-") || Input.GetKey("[-]")) {
47.                     camOSize4 += 0.2;
48.                 }
49.             }
50.             if (camera.aspect > 1.25  camera.aspect <= 1.35) {
51.                 print ("4:3");
52.                 camera.orthographicSize = camOSize5;
53.                 if (Input.GetKey("=") || Input.GetKey("[+]")) {
54.                     camOSize5 -= 0.2;
55.                 }
56.                 if (Input.GetKey("-") || Input.GetKey("[-]")) {
57.                     camOSize5 += 0.2;
58.                 }
59.             }
60.             if (camera.aspect > 1.0  camera.aspect <= 1.25) {
61.                 print ("5:4");
62.                 camera.orthographicSize = camOSize6;
63.                 if (Input.GetKey("=") || Input.GetKey("[+]")) {
64.                     camOSize6 -= 0.2;
65.                 }
66.                 if (Input.GetKey("-") || Input.GetKey("[-]")) {
67.                     camOSize6 += 0.2;
68.                 }
69.             }
70.         }
71.         if (Screen.width == 800) {
72.             if (Screen.fullScreen == false) {
73.                 camera.orthographicSize = camOSize1;
74.             }
75.             if (Screen.fullScreen == true) {
76.                 camera.orthographicSize = camOSize6;
77.                 if (Input.GetKey("=") || Input.GetKey("[+]")) {
78.                     camOSize6 -= 0.2;
79.                 }
80.                 if (Input.GetKey("-") || Input.GetKey("[-]")) {
81.                     camOSize6 += 0.2;
82.                 }
83.             }
84.         }
85. }
86.  

 

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.

--Eric

 

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.

--Eric

 

Ahh. OK, so only the main camera is set to "don't clear." Thanks. My bad. Back to work on 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!

 

Sorry, I wasn't clear...I meant a camera with a viewport rect of 0,0,1,1. So it covers the entire screen.

Yep, a lower number. Higher numbers are "on top" of lower numbers. This is actually the "Depth" option for cameras rather than the layer. Layers are for what cameras see, and the camera depth is like layers for cameras. Boy my explanation is confusing.

So for example you'd have your main camera with depth 0, with a viewport rect of 0, .2, 1, .8 (or something), clear flags set to "depth only." And then another camera with depth -1, with a viewport rect of 0, 0, 1, 1 and clear flags set to "solid color" and a culling mask of "nothing". You can leave the clear flags at "solid color" for both if you want, but my testing was consistently giving me a little higher fps with the main camera at "depth only". Hope this helps!

--Eric

 

Thanks for clarifying. I am sure if I were less ignorant about cameras I would have understood it better the first time. I have implemented these changes (the pics below show the two camera settings) and tested the file on a couple of computers. I can see no difference in the behavior from the testing but it seems to run fine.
StarManta, I really don't know how bad the hard reset was - if it did damage or was just a temporary annoyance. If it was not anything serious that happened, would you mind giving this a go and seeing if it fixes the problem?
[edit]Sorry - I forgot to do the same treatment to the camera in the intro section. That's fixed in the build below.