Full Screen Issues = Rejection
by George Ison · in Torque Game Builder · 01/11/2013 (7:35 pm) · 5 replies
Hello all,
We are having an issue and for some reason its behaving differently on various machines. I had made a post on a similar topic before, but rather than revive that....I'll start anew with this one due to the specific nature that's brought it back up.
We just submitted our latest match 3 adventure game to one of our publishers, now we had submitted it to 2 others prior to and didn't have any issues (at least not yet). However, Big Fish is the hardest to deal with of them all. Fact is there very thorough, very helpful too, but super thorough; non the less this full screen issue has become a real problem now, because BFG's QA wont pass us this round on the count of the screen not behaving properly (doesn't maintain aspect) . So I been chomping at the bit trying to understand it, here's all I can figure out and for no reason unless its purely a graphics card issue in their machines.
I have found that on some machines/monitors it maintains aspect ratio like it should and fills in the unreachable areas with black (publisher acceptable), but on others it just stretches to the limit without regard to the graphics and this wont pass. I was able to produce the issue myself time and time again on hi-res widescreen monitors, yet my laptop is widescreen at 1920 x 1080p and it works in the acceptable way.
On monitors that are not widescreen this never happens either also we are not using anything special, standard t2d fullscreen option is all (wasn't under the impression we needed too...). We would definetly appreciate any help or ideas you could provide to eliminate this issue.
We are having an issue and for some reason its behaving differently on various machines. I had made a post on a similar topic before, but rather than revive that....I'll start anew with this one due to the specific nature that's brought it back up.
We just submitted our latest match 3 adventure game to one of our publishers, now we had submitted it to 2 others prior to and didn't have any issues (at least not yet). However, Big Fish is the hardest to deal with of them all. Fact is there very thorough, very helpful too, but super thorough; non the less this full screen issue has become a real problem now, because BFG's QA wont pass us this round on the count of the screen not behaving properly (doesn't maintain aspect) . So I been chomping at the bit trying to understand it, here's all I can figure out and for no reason unless its purely a graphics card issue in their machines.
I have found that on some machines/monitors it maintains aspect ratio like it should and fills in the unreachable areas with black (publisher acceptable), but on others it just stretches to the limit without regard to the graphics and this wont pass. I was able to produce the issue myself time and time again on hi-res widescreen monitors, yet my laptop is widescreen at 1920 x 1080p and it works in the acceptable way.
On monitors that are not widescreen this never happens either also we are not using anything special, standard t2d fullscreen option is all (wasn't under the impression we needed too...). We would definetly appreciate any help or ideas you could provide to eliminate this issue.
About the author
Love to engineer and develop just about anything. Our primary focus though is that of computer games and software tools.
#2
Thanks for the reply, BFG is one of the main folks we cater to and haven't yet run into QA issues with the others. I understand BFG's response toward quality, but you have no idea (maybe you do) how catered to these premium casual folks are. The hand holding alone is well.....I don't have words for it. I could preach on it all day, but I'll spare you. Fact is their the only hold up from our release date on this title and right now this aspect issue has become priority number one.
I understand exactly what your getting at, I'll implement it and report back.
**Update**
Ronny have you experienced any odd numbers coming from
getDesktopResolution() ?
I ask this simply because if I do this as a test:
I am currently working as I type at a resolution of 1920 x 1080p. I double checked windows as well, yet the output I get from above is this:
Desktop Width: 512
Desktop Height: 344
Needless to say this is wrong, question is why?
01/12/2013 (9:32 am)
Ronnie, Thanks for the reply, BFG is one of the main folks we cater to and haven't yet run into QA issues with the others. I understand BFG's response toward quality, but you have no idea (maybe you do) how catered to these premium casual folks are. The hand holding alone is well.....I don't have words for it. I could preach on it all day, but I'll spare you. Fact is their the only hold up from our release date on this title and right now this aspect issue has become priority number one.
I understand exactly what your getting at, I'll implement it and report back.
**Update**
Ronny have you experienced any odd numbers coming from
getDesktopResolution() ?
I ask this simply because if I do this as a test:
%desktop = getDesktopResolution();
%width = getWord(%desktop, 0);
%height = getWord(%desktop, 1);
echo("Desktop Width:" SPC %width);
echo("Desktop Height:" SPC %height);I am currently working as I type at a resolution of 1920 x 1080p. I double checked windows as well, yet the output I get from above is this:
Desktop Width: 512
Desktop Height: 344
Needless to say this is wrong, question is why?
#3
***Update***
I retract my previous statement. Its working but unfortunately I couldn't get it to work exactly as you indicated but never the less it put me on the straight and narrow. Only drawback is now I have to change the way full screen is turn on or off in the user interface now as I finally built a custom function to manage it. I appreciate the help!
01/12/2013 (10:34 pm)
Ronny Im not having any luck with that. Screen sizes get huge...I've evidently failed to see your instruction properly. I've messed with it most of the day to no eval. It doesn't want to adhere to the extent. It just sizes way up almost as if you camera is zoomed in.***Update***
I retract my previous statement. Its working but unfortunately I couldn't get it to work exactly as you indicated but never the less it put me on the straight and narrow. Only drawback is now I have to change the way full screen is turn on or off in the user interface now as I finally built a custom function to manage it. I appreciate the help!
#4
For example, on many modern monitors the on-device menu usually lets you configure behavior for displaying varying aspect ratios on it. You can usually configure them to scaled (may have bars or may chop of the ends), stretched (no bars but the proportions will be out of whack), and original (including black bars). You really can't rely on the user to have configured in any meaningful way.
If you play a game that sets the resolution to say 640x480, depending on the monitor and/or video card settings, it could be displayed as stretched OR in its original aspect ratio but scaled (with black bars), OR in it's original aspect ratio and resolution (small with big black bars) depending on those various settings.
There's also the fact that some monitors don't even have scalers in them (see Dell's older 30" monitors that don't, which rely on the video card to do it and can only display at resolutions of 1024x768 or 2560x1600; the video card must convert everything to one of these two resolutions itself).
tl;dr drivers/cards/monitors don't have a uniform standard of scaling/displaying content that's different from it's current aspect ratio/resolution.
As has been posted here, you almost always have to do this yourself.
For workarounds, you can base your aspect ratio on the resolution (assuming you didn't change it in the first place) and possibly place static graphics on either side of the 4:3 screen, you can change the resolution yourself, but you need to do so by find out what the monitor's aspect ratio is (for the reasons above).
One solution would be to force the user to select an aspect ratio (or resolution/aspect ratio) upon installation or execution.
01/13/2013 (6:49 am)
The original problem sounds familiar. I'm guessing you originally had an aspect ratio you developed for and let the video card/monitor sort out stretching or blocking. When you do that, you have to keep in mind that most video drivers and monitors have multiple methods of handling this.For example, on many modern monitors the on-device menu usually lets you configure behavior for displaying varying aspect ratios on it. You can usually configure them to scaled (may have bars or may chop of the ends), stretched (no bars but the proportions will be out of whack), and original (including black bars). You really can't rely on the user to have configured in any meaningful way.
If you play a game that sets the resolution to say 640x480, depending on the monitor and/or video card settings, it could be displayed as stretched OR in its original aspect ratio but scaled (with black bars), OR in it's original aspect ratio and resolution (small with big black bars) depending on those various settings.
There's also the fact that some monitors don't even have scalers in them (see Dell's older 30" monitors that don't, which rely on the video card to do it and can only display at resolutions of 1024x768 or 2560x1600; the video card must convert everything to one of these two resolutions itself).
tl;dr drivers/cards/monitors don't have a uniform standard of scaling/displaying content that's different from it's current aspect ratio/resolution.
As has been posted here, you almost always have to do this yourself.
For workarounds, you can base your aspect ratio on the resolution (assuming you didn't change it in the first place) and possibly place static graphics on either side of the 4:3 screen, you can change the resolution yourself, but you need to do so by find out what the monitor's aspect ratio is (for the reasons above).
One solution would be to force the user to select an aspect ratio (or resolution/aspect ratio) upon installation or execution.
#5
I understand what your saying and the system I have developed based off concepts from Ronny, but with my own methods of pulling aspect ratio seem to be working well. It is unfortunate there is no standard.
The casual world is hell bent on being the most user friendly base in the world to "the end user" so needless to say they don't want the end user to have to mess with much of anything nor do they want it to rely on platform specific distributables or anything of the like(install and go), so sometimes what's seemingly easy in the interim, becomes a little more problematic in the end once the rule base starts kicking you in the mud as this issues has me.
My problem is that I took for granted that T2D was handling this and while it does to a very basic extent its definetly something that needs attention if you plan to move into the casual world. That being said, lesson learned :-).
Although now the problem we are experiencing is the option to go from full screen to windowed and back. Before hand I was using the toggleFullScreen() function and this still works from Full to windowed, except now this needs to be encapsulated within another function in order to undo everything that was done during initial start up (ie, put extents back and window positions).
However, going from Windowed back to Full results in a crash with a mode not supported error message. What this is saying to me is the resolution mode is not supported, which obviously 1920 x 1080 is. The problem I believe comes from the getDesktopResolution() command which some how still seems flawed.
Originally it was reporting the wrong values altogether, completely obscure to what the actual settings where(see the update in my first post). I moved this very early on into the start phase (onStart()) in order to Capture the users desktop before Torque went crazy making things (which seemed to cause obscured values). Then I would pull apart the values returned (width, height, color depth). With a resolution of 1920 x 1080 the command returned 1920 x 1040. Scratching my head I thought I would set my desktop to a different resolution and run my test function again, it returned 1600 x 860! The height is being shaved by 40 pixels on all returns which causes an unsupported mode error when used with setScreenMode(),as a hack I simply added 40 to the pulled value to get an appropriate mode resolution which resolved the issues with the error. Now I'm getting this same error when trying to toggle back from full screen and I'm assuming this is due to the invalid height return somewhere in toggelFullScreen().....just not been a good weekend lol.
01/13/2013 (1:22 pm)
@KevinI understand what your saying and the system I have developed based off concepts from Ronny, but with my own methods of pulling aspect ratio seem to be working well. It is unfortunate there is no standard.
The casual world is hell bent on being the most user friendly base in the world to "the end user" so needless to say they don't want the end user to have to mess with much of anything nor do they want it to rely on platform specific distributables or anything of the like(install and go), so sometimes what's seemingly easy in the interim, becomes a little more problematic in the end once the rule base starts kicking you in the mud as this issues has me.
My problem is that I took for granted that T2D was handling this and while it does to a very basic extent its definetly something that needs attention if you plan to move into the casual world. That being said, lesson learned :-).
Although now the problem we are experiencing is the option to go from full screen to windowed and back. Before hand I was using the toggleFullScreen() function and this still works from Full to windowed, except now this needs to be encapsulated within another function in order to undo everything that was done during initial start up (ie, put extents back and window positions).
However, going from Windowed back to Full results in a crash with a mode not supported error message. What this is saying to me is the resolution mode is not supported, which obviously 1920 x 1080 is. The problem I believe comes from the getDesktopResolution() command which some how still seems flawed.
Originally it was reporting the wrong values altogether, completely obscure to what the actual settings where(see the update in my first post). I moved this very early on into the start phase (onStart()) in order to Capture the users desktop before Torque went crazy making things (which seemed to cause obscured values). Then I would pull apart the values returned (width, height, color depth). With a resolution of 1920 x 1080 the command returned 1920 x 1040. Scratching my head I thought I would set my desktop to a different resolution and run my test function again, it returned 1600 x 860! The height is being shaved by 40 pixels on all returns which causes an unsupported mode error when used with setScreenMode(),as a hack I simply added 40 to the pulled value to get an appropriate mode resolution which resolved the issues with the error. Now I'm getting this same error when trying to toggle back from full screen and I'm assuming this is due to the invalid height return somewhere in toggelFullScreen().....just not been a good weekend lol.
Torque 3D Owner Ronny Bangsund
Torque Cheerleaders
One of the GUI variables you're looking for is Extent. This is the screen/game resolution, normally. In my projects I set it to $Game::Extent, which is calculated earlier on.
If $pref::Video::Fullscreen is 1 I set $Game::Resolution to the result of getDesktopResolution(). From there calculate[1] the aspect, new size and position of the game extent(s). In my .gui file mainScreenGui has the full resolution as its extent, and each t2dSceneWindow has the calculated extent (larger than design resolution, possibly smaller than screen resolution).
All this is done in a modified common/canvas.cs so that the screen mode is set after these calculations. All the action should be in initializeCanvas(), and your GUI-file should just refer to the resulting two variables.
[1]Rough formula: aw = desktop width / game width, ah = desktop height / game height. Multiply extent width AND height by the larger of the two. Center this in position (dw - gw)/2, (dh - gh)/2. A 720p extent should fit neatly in a 1080p screen. Different resolutions will have borders as needed.