How to deal with higher resolution images?
BlitzMax Forums/BlitzMax Programming/How to deal with higher resolution images?
| ||
| In this progressing world of increased technological evolution, screen resolution continues to rise. What used to be a high resolution 640x480 is now the bare minimum resolution and most hardware doesn't even support 320x240/320x200 anymore. 1024x768 is now the more popular web browsing resolution with over %50 of people using it. Furthermore, 1024x768, 1280x1024 and 1600x1200 are now the most popular general use resolutions, particularly popular with modern gamers. Now we have 1920x1200 as high definition displays for next gen consoles. Windows Vista and OSX Leopard both now have fully resolution independent interfaces and it seems like the resolutions just keep going up. One problem for us game developers is how to provide support, graphically, for these higher resolutions. When you start to think about supporting more than one resolution, rather than just picking 640x480, 800x600 or 1024x768, not only do you get into aspect ratio issues, both in the display and then in turn in the bitmaps you create, but also issues with how to scale or represent the graphics clearly and with the best detail in all resolutions. 1) How do you do it? 2) Do you have one high resolution set of graphics that you scale down to fit the resolution? 3) How do you scale it so the low-resolution displays aren't over-antialiased looking? 4) Do you rely solely on computer-generated realtime graphics like 3D or vector-line based graphics? 5) Are we moving away from pregenerated bitmaps? 6) If we are to have pregenerated bitmaps in a game, with handdrawn art, how can this best be made to work with these increasingly high and optional resolutions all within the same game? 7) And finally, what resolution(s) is the highest that your current project intends to support? |
| ||
| 1) With the projection matrix. Force the screen to a 4:3 ratio and leave borders on widescreen. Then whatever your screen needs to look like, it will be the same at all resolutions, as long as you scale accordingly. 2) Yes, more or less. I tend to design for 1024x768 and scale up/down as necessary. 3) I don't think you can really avoid this to an extent. Because I design for a medium resolution, it lessens the impact of scaling a little. 4) No. I have a lot of bitmap images for my GUI. 5) Somewhat, but I think there's still a place for bitmap images. GUI's and HUD's being good examples. 6) Erm.. see 1,2,3,4,5 and 7? 7) Officially, the highest one my monitor supports when I release. Unofficially, the combination of projection matrix and scaling ought to support any resolution. At least that's the theory. |
| ||
| So you ignore the widescreen format alltogether? Interesting that you use a medium-res graphics set. So in, say, 1600x1200, you scale the graphics up, but still allow them to be positioned at whole pixel coords? I'm wondering whether to do a hires bitmap because if I were trying to make it 1600x1200 that's a lot of detail to have to draw. |
| ||
| So you ignore the widescreen format alltogether? Yep. You pretty much have to decide on an aspect ratio and stick with it. That means letterboxing 4:3 to go widescreen or the opposite if you stick with 4:3. Even XBox360 and digital TV has to decide on one or the other and black out areas of the screen or leave users unable to see some areas. Leaving users unable to see certain areas just doesn't work on most types of games. I've heard a lot of arguments from people who don't fully understand the problem that it's not necessary, but it is if you want to be completely consistent. Anything else and you're either stretching square objects into rectangles or your nicely aligned GUI has gaps in it. Interesting that you use a medium-res graphics set. So in, say, 1600x1200, you scale the graphics up, but still allow them to be positioned at whole pixel coords? I'd have to double check, but I think I'm using floating point drawing coordinates. I'm wondering whether to do a hires bitmap because if I were trying to make it 1600x1200 that's a lot of detail to have to draw. Yep, another reason I went the mid-resolution route. |
| ||
| Why did you choose 4:3, because it's the native aspect ratio of your monitor? I have a widescreen monitor which is 16:10 so it would be `easiest` for me to draw gfx in that format and then stretch it. I'm not sure though why you have to stick to one aspect ratio? I am thinking to support multiple aspect ratios. The graphics files with have an aspect ratio of their own which is based on their resolution and how they were generated to look normal. Then I think I'm going to have that data scaled in x/y to fit the aspect of the display if the pixel coverage is different. I want to be able to support widescreen and plan to make my game adjust to use all of the available pixels. I think widescreen support is a good selling point. Not sure why you'd have gaps in your gui though? Because you use bitmaps for gui elements and don't scale them? I think I might go with a 1600x1200 sort of resolution for the bitmaps in 5:4 or 4:3 aspect and then size accordingly. Did you find any troubles with scaling images down to 640x480? I tried different scaling algorithms in a graphics package and they seemed to give varying results. The lanczos scaling is pretty okay, as is a `smoothing` resample. I also think it helps to sharpen the scaled image a bit to undo some of the over-antialiasing and give the same textural sharpness feel of the higher resolution. Also at the wikipedia the page on `display resolution` is pretty interesting. I think it would be a good idea to have a `database` of common display sizes and their known aspect ratio's, there's only really a few aspects to detect - 16:10, 16:9, 5:4, 4:3. If the user then picks a given resolution you can probably guess which aspect ratio it fits best into, otherwise blitzmax has no way of telling you what the aspect is. One problem I have though is stretched displays which throws that all out the window, e.g. 1024x768 stretched to a 16:10 aspect. I guess the other part of what I'm asking is how relevant will pre-generated graphics be in future since it is something of a struggle to support multiple resolutions and aspect ratios and especially high resolutions. Who is going to spend time hand-drawing art at 2560x2048, or even have it be generated by a 3d app at a high resolution? |
| ||
| I'm not sure though why you have to stick to one aspect ratio? For a simple game, you don't. It just depends how your GUI/HUD is designed. If you've got a health bar, a few score indicators and a crosshair in the middle of the screen, you can do whatever you please. When you have a complex painted GUI which fills the width and/or height of the screen ( and to look good NEEDS to do that ) you're snookered one way or the other. Not sure why you'd have gaps in your gui though? Because you use bitmaps for gui elements and don't scale them? Picture a complex GUI which goes right along the top and right down the left hand side of the screen. It appears to be one big bitmap image, but it's probably made out of smaller pieces aligned carefully. Let's say you're in 1024x768. And it looks beautiful. Put that into a different aspect ratio ( let's say 1280x768 ) and what do you do? You scale it up to match the new resolution, right? So the screen is wider now, right? But not longer? So you scale your bitmaps in width, but not height.Now - oops - those lovely perfectly circular buttons which are embedded into the GUI are now elliptical. Ok, that won't work. So you scale disproportionately to keep your ratios even, right? You scale the height as well to keep the aspect ratio of your bitmaps the same. Ah, but - oops - now you scaled your images in both dimensions but the resolution is no higher than it was before and now the bottom of your GUI is off the bottom of the screen. So all you've got left to do is see which dimension scaled the least and scale in both dimensions by that ratio. So in this example, the height hasn't changed at all, so you can't scale at all in the width without losing your perfect aspect ratio. So now you've either got a gap on the left, a gap on the right or a gap somewhere in the middle. A gap on the left won't work because the GUI needs to go down the left side of the screen. A gap in the middle won't work because it leaves a honking great hole in your painted GUI/HUD. So you have to leave a big area of blank space in the top right corner which wasn't there at 1024x768. Is it tolerable? I guess, but it's not ideal, is it? For simpler games, it won't matter and you can do as you please. But for games with a complex, painted GUI ( google some pictures of Company of Heroes for a perfect example of a complex GUI that would cause the problem I'm describing ) you just can't do it perfectly. On the plus side, be glad that you're taking this seriously. A lot of commercial games, big-ass retail games don't take this seriously and half the GUI stuff is squished to the point where you can't read it in some less standard aspect ratios. |
| ||
| I see, thanks for the explaination. Reminds me of the problem with website as well where if you want to draw a nice graphic you're pretty much stuck with it when the user has a larger desktop, leaving a big gap at the side. I made a website for a company I worked for and this was inevitably the problem. It had nice graphics n'all but it couldn't scale. Part of that is the limitation of browsers and html but partly also this same resolution issue. I didn't even consider aspect ratio at the time so I'm sure it looks warped on some displays. I appreciate that you recognize also this is in important thing to consider. If I add some kind of feature to a game or whatever I want to be sure that it is fully and completely implemented and supported and consistent and done properly, not just some half-*** job which detracts from the quality. I understand the issues with a GUI, thanks for describing it. I had forgotten about how fixed gfx have a problem when filling a screen. I am going to try to make a scalable gui setup so some parts are sort of fixed or will scale in proportion, while other parts stretch or allow bits to rearrange to fill the space or just ad some kind of `attractive gaps`. Ultimately though I'd like it to look good and play good in whatever resolution or aspect is thrown at it. To me that makes it `solid` and reliable. I also want to be able to provide increased graphical glory to the people with the gfx cards that can handle it, without requiring excess unused texture space for people running at a lower res. Gotta appeal to the niches. I guess some of the fortunate things these days with hardware accelerated graphics is you can composite things and build textured buttons and such on the fly in realtime which at least gives some opportunities to have it scale well. It's just mainly the handdrawn art that is a problem. I suppose one final option is to try going with fully scalable vector graphics, but the rendering time increases a lot and it's harder to make detailed art that can render realtime. The questions I asked above aren't really "I don't know how to do it" questions, it's more that I just wanted to find out how everyone else is doing it and get some discussion going. Anyone else have some input? |
| ||
| Hello. Gotta appeal to the niches Gotta appeal to the inches :o) Goodbye. |
| ||
| You could make a high resolution set say for the largest supported resolution 1600x1200 or something. But then your still constrained to certain display modes. |
| ||
| Fortunately I'm thinking there isn't a large amount of difference between the aspect ratios which is the main thing that changes the proportions of the layout on-screen. Of course widescreen aspects have extra space at the sides but it's not as if it's hugely different. I guess graphics should be targetted at a given aspect ratio more than at a given resolution because there are multiple resolutions with the same ratio. 640x480, 800x600, 1024x768, 1600x1200 all are the same aspect so there would be no distortion in the graphics at any of those modes, gfx can be scaled horizontally and vertically to fit in the same proportion. You only really get a problem when you introduce a new aspect ratio, more than a new resolution. That's where the gaps start to appear. So maybe I should go with a different graphics set for each aspect ratio, ie 5:4, 4:3, 16:10 and 16:9 should cover almost all modes. I think I also have to find out what exactly is the physical aspect ratio of my screen because even if it says its a given resolution that doesn't mean it's at a particular aspect physically. If I then go creating what I think are `normal` looking shapes graphically, they may turn out stretched and wierd at other aspect ratios. |
| ||
| Fortunately I'm thinking there isn't a large amount of difference between the aspect ratios which is the main thing that changes the proportions of the layout on-screen. Of course widescreen aspects have extra space at the sides but it's not as if it's hugely different. I guess graphics should be targetted at a given aspect ratio more than at a given resolution because there are multiple resolutions with the same ratio. 640x480, 800x600, 1024x768, 1600x1200 all are the same aspect so there would be no distortion in the graphics at any of those modes, gfx can be scaled horizontally and vertically to fit in the same proportion. You only really get a problem when you introduce a new aspect ratio, more than a new resolution. That's where the gaps start to appear. So maybe I should go with a different graphics set for each aspect ratio, ie 5:4, 4:3, 16:10 and 16:9 should cover almost all modes. I think I also have to find out what exactly is the physical aspect ratio of my screen because even if it says its a given resolution that doesn't mean it's at a particular aspect physically. If I then go creating what I think are `normal` looking shapes graphically, they may turn out stretched and wierd at other aspect ratios. I can see that if you start out with a nice menu system which spans the screen width, drawn in 800x600, then you raise the resolution to 1600x1200 you're going to have to double the width and height. I can also see if you jumped up to 1440x900 (widescreen res) you now would have a gap needed or otherwise that part of the screen has to take up more space vertically to maintain the proportion. So the amount of gap we're dealing with here is the amount of difference introduced by the aspect ratio, not the resolution. |
| ||
| My project, a 360 space shooter, is designed to handle strange resolutions. The ship images are simply scaled up on a higher resolution computer, the view area is based on the vertical screen-height, so if you have a wide-screen you can see more on the edges. I used some openGL commands to set the screen-size, so it deals with different resolutions. The GUI components don't scale, and are locked not to absolute positions but to positions relative to each other and to the screen's edges. |
| ||
| Good idea about the relative positioning. I think what I'm going to go with is one graphics set at 1600x1200 native resolution in normal 5:4 aspect ratio (or whatever is normal, 4:3?) ... then this will be smoothly scaled down (linear filter or something) for any resolution down to 801x601. Then at 800x600 the graphics data will be sampled as half height and width with no smoothing or resampling (just nearest neighbor) and then anything lower will be smoothly scaled down from 800 size. I would sort of like to include 1024x768 as the `half scaled` resolution but that would mean the graphics would be in 2048x1536 which is pretty high, but then anything above 1024x768 will get better graphics detail. Since 1024 is the most popular resolution I want it to look good. It's a possibility I suppose. Some numbers: A bitmap at 1024x768 in 32-bit color is 3,134,728 bytes (3 megs!), and so the default gfx set at 2048 would be 12,582,912 bytes (12 megs!). Do I really want a 12 meg file for a title screen or a cut-scene? A bitmap at 1600x1200 in 32-bit color is 7,680,000 bytes (7.7 megs) - better than 12? And at such a size, how to store it with good detail so it doesn't lose the whole point of being high-res, while keeping a small file and loading fast? |
| ||
| AngelDaniel, I think it would make more sense not to use that linear filter, check this code out (your free to use it, etc): This is what I'm using, it makes it pretty much invisible to the rest of the game code, but i think it will be faster than scaling everything down. |
| ||
| Hmm, okay, so you're saying to use the projection matrix to scale down in real time? The only problem there is you get liner interpolation plus you are accessing textures that are larger than they need to be, thus more memory required and it's also slower. ???? I need to scale it down, I don't want 1600x1200 image for a 640x480 display. |
| ||
| Question: Let's say you have an aspect ratio of 4:3. For every 4 pixels across you have 3 pixels down. If you multiply that up, you get to something like 1024x768. On my monitor, 1024 across is exactly 12 inches physically measured, and 768 down is exactly 9 inches measured. 12/9 is 1.33. Also 1024x768 is 1.33, and 4/3 is 1.33. Why is the physical size of the display (12" x 9") the exact same ratio as the ratio of the pixels? Why didn't they make a perfectly square monitor 9" x 9" with 4:3 aspect for the pixels? Does this mean the pixels are perfectly square? I did try to draw a 100x100 rectangle and measured it and it was perfectly square. Are all resolutions always perfectly square regardless of the aspect ratio, and is the aspect ratio then just the ratio of total width to total height or is there sometimes (in computer displays) a difference? I suppose here's a comparison: 640x480 is 4:3 aspect 640x512 is 5:4 aspect They probably consume the same *physcal* screen space? So if you draw a 100x100 rectangle in the 640x512 screen it will look more like a rectangle than a square? So not all resolutions have square pixels? *getting confused* Would it be because I have an LCD display, and LCD displays have a fixed pixel shape, so the pixels are always *physically* the same aspect ratio, so 1024x768 has to be letterboxed? So.... non-LCD displays probably don't have a fixed pixel shape? How does one determine the pixel shape if it has nothing to do with the width and height in pixels? |
| ||
| I'm on a cinema display, and I know its capable of filling the whole screen with different aspect ration resolutions, here's the list: 1280x800 1280x960 1344x840 1344x1008 1600x1000 16080x1050 I think there is some sort of stretching that goes on. |
| ||
| I was also thinking about on the Amiga, you could do 320x256 or 320x200, different vertical hz rates, but both filled the whole screen the same physical amount of space. So I guess the ratio you get from width/height is not the same thing as the actual `aspect ratio` of the pixels themselves. In 320x200 the pixels are taller. I am guessing that LCD displays have a fixed pixel shape/size, that some gfx cards do hardware scaling to make a resolution and is totally unpredictable, and that CRT monitors could probably do all kinds of different resolutions at different amounts of stretching, so using width/height has no real reliable bearing on whether or not something drawn will be exactly square or a perfect circle physically. For that we probably need to know the dot pitch or the physical dimension of the resolution. So I'm not sure how to offer aspect ratio support. I want to support widescreen and other aspects. I suppose I could assume that for the most part width/height would work for 4:3 ratio e.g.640x480, 1024x768 and just hope that most of the time this means I know the size of the display and its ratio. But sometimes this won't work. e.g. on my widescreen, 1024x768 can appear in 4:3 aspect AND in 16:10 aspect stretched. No way to tell between them. So we probably have to just offer some kind of manual `x stretch` and `y stretch` within the game, that the user can and has to tweak for each display mode? I just wish there were ways to make it more automated so the user doesn't have to fiddle with it to make it look right. I suppose for most modes you could offer 5:4, 4:3, 3:2, 16:10 and 16:9 as default settings and try to guess the closest one based on the width/height ratio, then if the user has something out of the ordinary, let them tweak it? |
| ||
| You're trying to be too user-friendly. Just assume that everyone is using an aspect ratio that uses true square pixels on their display of choice. So... 640x480, 800x600, 1024x768, 1280x960, 1600x1200, etc = 4:3 aspect ratio, so user is probably using a CRT or TFT/LCD. 1280x1024 is 5:4, which is typical for a TFT/LCD display. Anyone using this res on a CRT should be aware that their pixels are slightly squashed and are willing to put up with it. Any widescreen ratios are fitting for the display in use, which is likely to be a TFT/LCD or large screen LCD/Plasma. Keep it simple and you'll cover just about anyone. As for those few using an odd resolution for their display, then it's their fault and they'll have to tweak their settings - if that bothered about a slightly odd looking square! As for what to do with the GUI/HUD side of things, I would devise a floating system that expands into the 'unused' portion of a widescreen set-up (provided you were writing a game with 4:3 in mind), or have two different layouts for 4:3 and 16:9, which should cope with pretty much most of the market. It's impossible to cater for everyone, so just make sure you cover the majority. The rest will cope, and will probably not even notice. |
| ||
| Hi JazzieB. Thanks for your comments. I agree with most of what you said. I think what I'm going to do is assume that the aspect ratio, as derived by Width/Height, gives square pixels and that pretty much most displays will be approximately the same physical proportion. I will detect some of the more common aspect ratios and resolutions and create an automatic adjustment as close as predictably possible and then provide a manual adjustment within the game in realtime to tweak the x and y stretching. The gamer might want to stretch the display even when it's meant to be normal and might `like` a wide stretched look & feel. I remember liking the 640x256 mode on the Amiga since the fonts changed shape. I think this will be the best way to go and is pretty much what you said minus it being too user friendly. For the rest of em I will have a calibration screen or mode where they can tweak the stretching. |
   |