Wide Screen Monitor Stretching
BlitzMax Forums/BlitzMax Programming/Wide Screen Monitor Stretching
| ||
| I recently went to my local store to check out the latest pc's available. On some computers / laptops using wide screen monitors, I noticed some games (and screensavers) are coming up stretched horizontally. I can only guess the requested graphics mode returned an ok, but the system somehow is going into another virtual res and stretching it full screen, staying in wide screen mode. I would of thought the system would center the virtual screen on the wide screen so the aspect is still the same? Can anyone shed any light on this? Thanks. |
| ||
| On my old laptop, you can set whether the screen is stretched or centred. This is done through the control panel and I don't think its something you can do or check for in code. |
| ||
| This is a setting of: 1. Either the Graphic card driver (on desktop systems normally this one) 2. The BIOS (on notebooks normally this one) In both cases, it only happens when you go fullscreen, in windowed, you won't have the problem. At best you read out the desktop resolution and create a virtual window ... just create graphics with the desktop size and restrict the viewport etc to a specific ratio ... |
| ||
| I have a widescreen monitor and my Blitz game stretches to fill the screen. The ideal solution is to recognise a widescreen and take appropriate action. I haven't figured out how to do this yet. |
| ||
| But it sounds as if this is happening... 1) In your BlitzMax program you request 800x600 2) Everything is returned ok so you proceed. 3) System runs the game in wide screen stretched mode, but internally Blitzmax thinks it's still in 800x600 mode so all checks for resolution still report 800x600. If the above is the way it's happening, there's not a whole lot we can do. The only thing I can think of is, query the available graphics modes, see if widescreen modes are available, if they are then select one of the widescreen modes and self center your game if needed at run time. |
| ||
| 1) Get the desktop resolution 2) Calculate the Aspect Ratio 3) If ratio is not 4:3 then take steps making good use of our old friend the projection matrix. |
| ||
| As Indiepath said, calculate the aspect ratio and use the projection matrix to adjust accordingly. You could use black borders if the aspect ratio is not the same as your internal resolution, but I'm not fond of black borders so in the game I'm currently working on I adjust the width of my internal resolution to match the aspect ratio of the display. |
| ||
| And how are you handling the sprites to still get drawn correctly? anti-scale them against the screen scalling? |
| ||
| And how are you handling the sprites to still get drawn correctly? anti-scale them against the screen scalling? You don't need to worry about this when using the matrix. |
| ||
| In many ways it is not possible to tell for sure whether the display is a stretched resolution or not. For example on the Mac with widescreen displays there are typically many normal-aspect resolutions e.g. 800x600, 1024x768 etc in the 4:3 ratio. But then there are also the same resolutions in the aspect of the display which is 16:10 or 16:9. This stretches the pixels. Now, in the operating system, on the desktop where you choose a desktop resolution, it will tell you which mode is `stretched` and which is normal. But BlitzMax has no awareness of the difference. All Blitz can do is give you a full list of screen modes possible and you can get the dimensions and depth but it has no clue about whether it is a stretched mode, or anything to do with aspect ratios. It cannot tell the difference between 1024x768 stretched and 1024x768 normal. So it then probably comes down to how the game is choosing which screen mode to use. The games you're seeing, BlitzMax or otherwise, are probably getting a full list of screen modes from the operating system and then going through them to find which mode matches the dimensions and depth they want. They probably do not care what the aspect ratio is or whether it is stretched. And on some systems they probably find the stretched mode before finding the non-stretched mode with the same dimensions. Voila - stretched game. You can correct this for your own software, to some degree, by giving the user options to change the aspect ratio, which means changing the projection matrix. You could then narrow the used area of the display when it is a stretched mode, albeit having to do so manually since Max cannot tell you which modes are stretched. Possibly though once they've chosen a different aspect for the mode they choose you can store this as a default aspect to use and then next time they choose that mode it won't be stretched out. OR, you can also make use of widescreen modes by utilizing a combination of the correct proportion-preserving aspect ratio and making extra use of the available screen width. But then of course you get into problems such as how to dynamically size the graphics, how to stretch your heads-up-display, how to deal with GUI stretching, how the game can be fair when a user with a widescreen sees more of the play area, etc. |
| ||
| >>1) Get the desktop resolution >>2) Calculate the Aspect Ratio >>3) If ratio is not 4:3 then take steps making good use of our old friend the projection matrix. I AM using a projection matrix. (I believe I'm using your code btw.) But how would that solve the widescreen stretch? Doesn't the code just virtually scale the game area to the size of the render device? (resulting in stretch) Or are you saying a projection matrix can also somehow create a render area preserving the orginal requested aspect ratio? "which means changing the projection matrix. You could then narrow the used area of the display when it is a stretched mode..." Rendering a 4:3 aspect onto a 16:9 aspect, somehow preserving the 4:3 aspect accordingly? ? ? I'm a noob on the proj matrix stuff, any help in how to set the matrix for this scenario would be awesome. ;) Right now the proj matrix code I use just seems to scale the renders to the width/height of the screen, resulting in stretch if aspect is not the same as original. It sounds like the problem is already capable of being solved! If a proj matrix is capable of taking consideration of a 4:3 game and rendering it aspect correct on a 16:9 mode problem solved, right? All we need is code to properly setup the matrix then. ! ! |
| ||
| What you're aiming to do in preserving an aspect ratio, is to preserve your game graphics to be in the same *proportions* that they were in when you designed them, ie so that no matter what resolution you are in and no matter what size things get stretched to, visually the width and height of the graphic is in exactly the same proportion so all your circles still look like circles and your squares don't become rectangles, etc. That's what you're aiming for. So it slightly depends, to begin with, in what resolution you create your source graphics. If you do all your design in a 4:3 screen format then you need to take that aspect ratio into account when deciding whether stretching needs to occur in order to maintain proportion. You might, for example, develop your graphics in an app running on a 1440x900 widescreen 10:9 display and then try running your game in a 1024x768 4:3 aspect. Obviously, by default, this would make your graphics stretch out in an unwanted way. And vice versa, if you create gfx in 4:3 and display at 16:9 then obviously they will stretch. What you are trying to compensate for is the *difference between* the graphic's native aspect ratio and the ratio of the display. If you made for example a title screen that is 800x600 in 4:3 aspect, and the user wants to run in widescreen 16:9, then to maintain proportion you're going to have to have black bars at the sides of the screen. Since the 800x600 mode's pixel aspect ratio (shape) is the same as for the widescreen mode, this is pretty easy to do - just draw the graphic in the center of the display and no more changes are needed. See, if you have a widescreen display in 16:9 and you display a 1024x768 mode on it, which is non-stretched, the 1024x768 mode will show at 4:3 aspect ratio. But if they choose a stretched mode which stretches out the 1024 across the whole display, then now you have a problem because the aspect ratio of the *pixels* has changed - they've become elongated and the number of pixels across the screen is now out of proportion to the *physical width* of space that it takes up on the display. This is where you need to know the physical dimension or aspect ratio of the display mode. If you know how much physical space it takes up you can adjust your aspect. The projection matrix basically creates an elongated rectangular camera in 16:9 mode rather than one in 4:3 mode so that instead of the left and right edges of the screen being, say, -1 and 1 in world coordinates, they'd be something like -1.2 and 1.2, so the graphics at -1 or 1 are in the right position and not all the way to the edge of the screen. It means that all drawing/texturing etc will be automatically `sampled` at a higher horizontal resolution. This stuff can really get quite complicated. In the most ideal situation you would know the physical dimensions of how much screen space a given display modes consumes, regardless of whather that is all of the available hardware screen space or not, so that you can then determine what the aspect ratio really is to the user, and so that you can then adjust your internal aspect ratio to keep the right proportions. The way I figured it, there are three scenarios for types of screen resolution. 1) The resolutions are proportional to each other, so a 1024x768 mode leaves black stripes at the sides on a 1440x960 widescreen display. Aspect ratio is kind-of automatically maintained because the hardware manufacturers made sure the aspects between multiple modes are in proportion. These modes need a projection matrix that creates a `wider camera` for wider modes, ie the camera size is directly related to the aspect ratio. 2) The resolutions are not proportional because the all use the same physical amount of screen space, ie 1024x768 gets stretched out horizontally to use all available `pixels` that the hardware display can show. The physical aspect ratio is the same for each display mode but the amount of pixels within that screen space varies, so needs projection matrix adjustment in software - the camera size needs to be dynamic to scale from the physical screen size to the number of pixels within that area. 3) The user (or hardware) has adjusted each display mode differently to use different amounts of physical screen space, as well as having who knows what amount of pixels to fill that space. This happens on crt monitors more than lcd screens and basically is because the monitor has adjustments to change the size and shape of what is displayed. So any resolution, even if it's some basic 1024x768 can get all stretched about so that it's not, technically, actually at exactly a 4:3 ratio. The width might be a bit wider, or the height might be stretched. These kind of modes are the difficult ones, where they could have all sorts of wierd resolutions like 1280x256 on the Amiga (super hi-res) which was at a 4:3 ratio. Even if the o/s could tell you the default aspect ratio of that display it would not be able to tell you the monitor's adjustments to the size/position/scale of the output, so who the heck knows what the user is seeing or in what aspect. In this situation you need to adjust the projection matrix dynamically but probably would only be accurate if you can get the user to tell you the physical measurements of the display mode (ie get a ruler out and measure it). In some of these situations, maybe the best solution would be to provide some kind of in-game `tweaking` of the resolution, ie changes to the projection matrix, so the user can stretch out what is displayed (perhaps within reasonable limits) to get `what looks to them` to be the right proportions. A sort of `calibration` screen or some key you press to adjust it, just like if you had on-screen controls on your monitor to adjust these. You could also ask the user whether all their screen modes fill the whole display, but then you're getting technical. The user shouldn't have to do things that the software should do automatically. One further tip is that you can *usually* detect `common` aspect ratios by dividing the width by the height, in pixels. Then if this boils down to being like 4:3 or 16:10 or whatever, you can identify that mode as that aspect ratio. But you still don't know for sure that you have accurate information. I know some people are grouping display modes by aspect ratio, or hiding modes that don't seem to have a 4:3 ratio ie just the 640x480 800x600 1024x768 etc modes show and no widescreen stuff. While you can see what the desktop resolution is not everyone uses their highest or native resolution for the desktop display. It is unreliable. You also can't always depend on the number of pixels being displayed horizontally or vertically matching up with or being a multiple of the aspect ratio. You could have more pixels in the same amount of physical screen space, in either of the dimensions separately. PixelWidth/PixelHeight is not accurate enough. Unfortunately there is no totally automated solution without making some decisions on behalf of the user. BlitzMax cannot detect aspect ratios and probably neither can the o/s properly, unless maybe the driver can provide some details, but I doubt the driver can tell you if the user stretched their display manually. What you're left with is trying to come up with as close an approximation as possible, to cover most of the situations and provide enough options that things can be tweaked if they are off. |
| ||
| I'm just gonna read desktop res and decide if I can show 800x600 OR and 800x600 area with black borders on a wider screen. |
| ||
| This Post sounds really cool |
| ||
| Above Nomen describes his games "filling the whole screen" but I would be worried if it didnt fill the whole area. |
| ||
| My 4:3 aspect ratio CRT died recently, and I replaced with a 16:10 aspect ratio LCD. That's led me to understand how unsettled the situation currently is. Depending on your monitor/videocard combo, it may or may not be possible to use pillarboxing* (the inverse of letterboxing) which displays 4:3 images with black bars at the sides on a 16:9 or 16:10 display. In my case, my monitor tries to be "helpful" at standard VESA resolutions by stretching the 4:3 display to 16:10 (whereas I'd prefer the black bars). As a result, all 800x600, 1024x768, etc. resolutions are stretched out with no way to avoid it. This is an issue with fullscreen only. With a windowed display, any resolution/aspect ratio is possible and the pixels are always square, so it's not a problem. But my videocard only supports "standard" (4:3) fullscreen resolutions below 1280 horizontal, and there's no way to tell my monitor not to stretch. From what I've read, some other LCDs allow this to be turned on/off via their controls, and some more-modern videocards allow stretching to be controlled via their drivers. This was less of a problem when using a standard, analog cable (which I did the first couple of weeks). In that case, I was able to manually squish the aspect ratio somewhat. But when I went with a DVI cable (which produces a better-looking image in several ways), that ability was lost since it's purely digital. * windowboxing is where there are black bars on all four sides (thanks for the correction, Gav). |
| ||
| I think i need to see these screens to understand these posts, I dont think you mean the picture is stretched out beyond the sides do you? |
| ||
| I think i need to see these screens to understand these posts, I dont think you mean the picture is stretched out beyond the sides do you? It's like this:  There are widescreen display modes available which display fine on a widescreen monitor (and would appear either letterboxed or squished on a 4:3 monitor). But the above are the two possibilities when a 4:3 display mode (like 800x600 or 1024x768) is displayed at 16:10. how come 52inch plasma screens are ok, they really make the picture wider but console makers dont try and rememdy it by making skinny mode games A standard 4:3 TV signal displayed on a widescreen TV is either going to be pillarboxed or stretched like the above. A widescreen TV signal will fill the widescreen TV screen correctly but will be letterboxed (have black bars at top and bottom) on a 4:3 TV screen. The same applies to console games: if it's an old title that only supports 4:3, it's either pillarboxed or stretched on a widescreen TV. But newer console games have both 4:3 and widescreen display modes available and so can use the appropriate one. |
| ||
| Is aspect ratio critical? Notebooks come out with several different wide displays, |
| ||
| I can change between modes on my winfast pvr |
| ||
| It looks to me that its not up to us programmers, its up to the user, if you want 4:3 then get a 4:3 screen, likewise if you dont mind widescreen like me then get widescreen, if its out of this world bad then I will go back to standard size monitors I want wide screen ,not pillars So you want pictures which are supposed to be perfectly square to be retangular? Text which is supposed to be square and readable to be short and fat and barely legible? If so, I suspect you're in the minority. When I had a 16:10 monitor, I found games which insisted on using 4:3 extremely unpleasant to play as they were stretched badly. If they couldn't adjust the aspect ratio and use all of the screen ( as any game with a complex HUD clearly cannot ) then I would have preferred it if they had just used the portion of the screen they could. |
| ||
| yeah like Gabriel says, I'd much rather have a "windowboxed" 4:3 game on a widescreen than have it all squashed out of proportion like having non-round circles etc. When I play my console games on my widescreen plasma I look for a widescreen option in the game options. If no such option exists I put the screen into 4:3 mode which has vertical bars either side of the game. The bars don't look great and may wear the screen down eventually (OK I now have a new plasma with a "special" 4:3 mode which is a teeny bit stretched AND zoomed and I use that now) but at least the aspect ratio is correct for the game. Playing a 3D platform game with precision jumps is hard when the game is stretched horizontally, errors can occur due to the weird aspect ratio. |
| ||
| My take on this is that it is a function of the person's laptop/scree. And more than likely is a setting in their driver. I don't think, as programmers, that we need to worry about this. If the user doesn't like it they can turn it off in their driver. It is not the job of the programmer to know what every video card might do and try to turn it off/on. Just like when I run an 800x600 game on my LCD. My PC can show it centered on the screen, or it can stretch it to fill the screen, but that is my choice, not yours as the programmer of the game. You are just wasting your time trying to accomodate every screen/mode on the market. There are way too many of them. |
| ||
| On the Mac, on the desktop the o/s lets you choose the various resolutions for your desktop display, and it will list some modes as being "Stretched" while others are not. I have a 1024x768 normal aspect which shows as a 4:3 aspect ratio on the widescreen display, with black bars at the sides, and then there is a 1024x768 stretched mode which shows the same number of pixels but at a 16:9 aspect ratio - ie stretched out. All the graphics in that mode are stretched horizontally, if they were originally meant to be 4:3 ratio. In BlitzMax there is no way to really detect which of the modes in the list of display modes are the stretched ones. Blitz sees the stretched mode just as a 1024x768 mode. There will therefore be two modes in the list, within Blitz, saying 1024x768. I will not know which one is stretched and which one isn't. If I choose the first one I may or may not get the stretched out version. Since Blitz doesn't seem to have any way to tell what the real aspect ratio is displaying as - ie the aspect of the display MODE, regardless of the projection matrix, it's impossible to know how to properly adjust the projection matrix to show the graphics at their proper intended proportions. Like someone else said, what it eventually boils down to is that at some point the user has to either use adjustment tools within your app to alter the projection matrix, or they have to enter the physical measurements of the visible display area so that you can calculate the ratio between the display size and the pixel size. It would help considerably if max could tell you which modes are stretched, in a cross-platform way. It would be even better if it could tell you the actual displaying aspect ratio of the physical display, plus the ratio of the hardware e.g. 10:9. You also need to know if the user's modes are in proportion *to each other*. On my widescreen display, the non-stretched modes are in proportion to each other - 1440x900 has a ratio of 10:9 in terms of pixels, AND consumes physical space which is in the ratio 10:9. A 1024x768 mode has a ratio 4:3 in terms of number of pixels, AND consumes physical space which is in the ratio of 4:3 - ie black bars are added at the sides. So in other words, the shape of the pixels remains the same across display modes. This is nice and easy to handle. As soon as you get stretched modes, OR you have a monitor which fills the same physical space regardless of the number of pixels, OR a monitor where each mode more or less is stretched manually by the user or by the monitor any kind of abnormal physical aspect ratio, then you're getting into some very uncharted territory and pretty much need the physical measurement of the display area in order to calculate the correct projection. |
| ||
| Here's how I get around all this... Brucey has some nice mods that return the desktop's width, height, depth and so on. Now as pretty much every one will be using a desktop resolution that matches their display's aspect ratio, I use his mod to get the width and height of the desktop and use this to calculate the aspect ratio of the display. I then choose an appropriate resolution for my game that matches this aspect ratio. So if a user has their desktop set at 1600x1200 (4:3), I know to use 800x600 in my game. If their desktop is 1440x900 (16:10), I use 800x500, and so on. If someone has an odd display and there isn't an exact match, then I pick the nearest. I then recalculate HUD placement and wot-not to make use of the available space. If you want your game to play at a fixed size, then simply draw the game in the centre of the display and slap some black bars where necessary. The other thing to do is just allow the user to be able to alter the display settings in game if they wish. |
| ||
| My take on this is that it is a function of the person's laptop/scree. And more than likely is a setting in their driver. I don't think, as programmers, that we need to worry about this. If the user doesn't like it they can turn it off in their driver. It is not the job of the programmer to know what every video card might do and try to turn it off/on. That's precisely the job of the programmer. I don't expect to have to change my monitor settings every time I play a different game to accomodate what some lazy programmer might have done. It's his game, he knows what it should look like, he should make sure it looks like that. I shouldn't have to guess what I need to do and how I need to do it. What if I want to play five different games in an evening? Change my monitor settings five times over? I don't think so. You are just wasting your time trying to accomodate every screen/mode on the market. There are way too many of them. You've missed the point. It doesn't matter if there are one or a hundred and one. If you do the right thing, you can handle all of them with the same piece of code. It's not like you have to manually change settings for each resolution. This is a very much a "one size fits all" solution, so long as you do it right. Just like when I run an 800x600 game on my LCD. My PC can show it centered on the screen, or it can stretch it to fill the screen, That's something completely different. If the user stretches a 4:3 aspect ratio to a different aspect ratio, there is nothing you *can* do. You cannot know it's happening. but that is my choice, not yours as the programmer of the game. But you're advocating just the opposite. You're advocating that the programmer should decide on an arbtitrary aspect ratio and to ignore what the user has decided they want. What I'm saying is that you *should* let the user choose, and adapt your game to look as good as it can on their choice. Not force them to use a resolution they don't like because the text is illegible and the graphics are ugly on the resolution they wanted. |
| ||
| I see your point, I think you and I are coming from different angles at this. Pop a list of possible resolutions and let the user choose then. There are a lot of things to consider here, there isn't just one topic in this thread. One problem I see is that a game should not offer more game real estate at different resolutions. Unless it is a single player game and there is no competition with other humans involved (like high score tables). If you allow one person to see more game world on their screen than another person, you are giving them an unfair advantage over a player who has less. |
| ||
| One problem I see is that a game should not offer more game real estate at different resolutions. Exactly. This is a common mistake with games on widescreen monitors, particularly with games with a minimal HUD where everything is 3D. The programmer just lets the user with the widescreen have a great field of view, and gives them an unfair advantage, particularly if it's a multiplayer game. |
| ||
| I think the wider gameplay area is okay so long as the game accomodates to make things fair - ie usually for 1 player games only unless all users have the same view. Or let the other players have the option to see the same shape display and to see the same amount of game world, perhaps with black bars at the top and bottom to do so. For something like a 1 player sidescrolling shootemup it would be fine, and for splitscreen modes it would be great to have a bigger screen area for each player. While I think the detection of the desktop resolution may work for a large percentage of cases I am not comfortable that it covers everyone or even as many as it might seem. I am guessing maybe 75-80% at most, which to me is not enough. Just detecting the desktop isn't accurate enough. How would you go about removing stretched modes from a list of display modes when you cannot tell which ones they are? And how do you know that the desktop resolution has anything whatsoever to do with the physical space it takes up no the screen? You can't. |
| ||
| Then you most likely never had a TFT running in anything but its native resolution I assume. Otherwise you most likely would know that there is only a very small minority of screens that do NOT destroy text in a way that gives you bad headache in less than 2 hours if you do not run the screen in native resolution (same aspect but smaller resolution does not solve that as well) Nobody ever would try to set his desktop resolution to something different than native TFT (and if he does then most likely for good reasons -> crap graphic card for example) In either way, the desktop resolution is the resolution the user wants to be in most likely, you can still offer an option menu afterwards in case he needs it. |
| ||
| I still dont get it |
| ||
| Oh BY THE WAY Wendellm, You incorrectly labeled your diagrams you say that your pic of pillar boxing is window boxing an example of window boxing is not shown in your diagram It appears to me that If a user prefers "Perfectly square" then they should stay with CRT, or if wide screen if desirable to you or you dont mind or like me even notice then just continue the way you are. |
| ||
| So If I hard program my game to work on 1024 x 768 the person with a wide screen will have more horizontal pixels?? Heavens, no. Sorry, I didn't mean to give that impression. I meant if you allow the users to select any resolution they want. If you pick 1280x720 and I pick 1024x768, and we play online, unless the game's programmer did *something* to make sure the displays are the same, you'll get a wider field of view than I will. Just detecting the desktop isn't accurate enough. How would you go about removing stretched modes from a list of display modes when you cannot tell which ones they are? And how do you know that the desktop resolution has anything whatsoever to do with the physical space it takes up no the screen? You can't. You're quite right. You can't do it. You have to assume that the aspect ratio of the resolution I pick is the aspect ratio of the monitor I own. If I choose to run my desktop at 1024x768 and have it stretched to fit a widescreen monitor, you cannot know that, and it's my own fault. Besides, if I do that, I'm going to be used to everything being stretched. And if I really don't like it, all I have to do is select another resolution. |
| ||
| I guess I could impliment a support for widescreen A user could select the Aspect Ratio of the Monitor they are viewing my software with, (Just One Selection). Then I Add WindowPillars to fix. |
| ||
| Oh BY THE WAY Wendellm, You incorrectly labeled your diagrams you say that your pic of pillar boxing is window boxing an example of window boxing is not shown in your diagram Thanks for that; you're indeed right. I've corrected that reference and my text references above from "window" to "pillar." |
| ||
| pillar box, OK brain updated. |
   |