Resolution and Aspect Ration Independent 2D Game Engine Design

[pstudio]

So I'm prototyping a 2D game engine to test out some concepts. One of the issues I have to deal with is the multiple resolutions and aspect ratios computer screens come in today.
How do you ensure that a game looks good on different resolutions such as 800 X 600 and 1600 X 1200? And what to do about different aspect ratios where more horizontal screen place is suddenly available?
How do you tackle this problem (This is one of those times where it would be easier to do 3D)? What thoughts have you done on this issue? Or do you just ignore this and't care at all?

These are some of the thoughts I've done so far:
Regarding resolution:

A) Choose a resolution and stick with it. Then change the screen's resolution to match your game's resolution. Personally I think this is a no-go. I curse programmers when they change my resolution.
B) Choose a minimum resolution and make the game windowed. This sucks as well. Works ok for small resolutions but the game will likely be to small on large resolution screens.
C) Choose a (high) resolution and render to a buffer. Then render the buffer scaled so it fits the screen's resolution. This is the way I'm thinking about going right now. I'm going to render multiple layers to multiple rendertargets and combine them in the end anyways so it would be easy to scale them in the end.
D) Create assets for different resolutions. Will give the best result for supported resolutions but it requires a lot of work creating the assets. The issue still exists for the resolutions not supported.
E) Use vector art. Vectors can be rasterised at the beginning or during loading. I'm not sure how much expensive it will be do this conversion. Vector art has great potential but there are some images that can't practically be created by vectors.
F) Use procedurally generated content. Like vectors it can be created at runtime for the specific resolution. However it is time consuming to design algorithms for generating images and it obviously won't work in all cases.

Regarding the aspect ratio:
A) Choose 4:3 ratio. Stretch the canvas for wider aspect ratios. The drawback is obvious. The wider aspect ratio the wierder distortion.
B) Choose 4:3 ratio and draw black bars around the sides. Better than A) in my oppinion but we're wasting screen estate.
C) Show more of the game world depending on the aspect ratio. For some games this will work. For other games it can completely destroy gameplay.

Are there more possible solutions or do you any additional thoughts on the ones listed by me?

[Super Vegeta]

I think that in most games, keeping the same experience despite the resolution is crucial, so there goes either fixed resolution or scaling. Scaling has the problem that, oh well, it takes some time and must be done such way that the result is this likeable.

Showing more of the game world will work only for... how to say it? not much action-packed? games. I mean, yes, you can show more space in a shooter, but this will allow the player to see more, making the game easier for him. And if we are talking about multiplayer, perhaps... That is an absolute no-go, as it gives one player advantage over the other. Although this will work fairly for puzzle, or turn-based strategy games, where the gameplay is not affected by one's speed of reaction and ability to tonice things quickly.

My only other idea than showing more of the game world, in case of additional screen space, would be a bigger UI; possibly providing more detailed information (but rather not more information, in terms of quantity) and maybe some additional buffer/shortcut space.

[LP]

How do you ensure that a game looks good on different resolutions such as 800 X 600 and 1600 X 1200? And what to do about different aspect ratios where more horizontal screen place is suddenly available?

First, you should not think of "resolution" concept while working on your game, which I once discussed here (http://afterwarp.net/forum/topic/26-using-full-screen-mode-in-asphyre-sphinx-2/).

Specifically, switching resolution on today's machines is a bad practice for end users as it will mess up with user's desktop, reorganize gadgets and so on; in any case, the end user is probably using the best possible resolution on the screen, which is typically the native screen of LCD display.


A) Choose a resolution and stick with it. Then change the screen's resolution to match your game's resolution. Personally I think this is a no-go. I curse programmers when they change my resolution.
A very bad idea considering what I've said above.


B) Choose a minimum resolution and make the game windowed. This sucks as well. Works ok for small resolutions but the game will likely be to small on large resolution screens.
The game may still get clipped on ultra-portable computers where resolutions can be as small as 800x480. On other machines with high DPI displays your game will look tiny.



C) Choose a (high) resolution and render to a buffer. Then render the buffer scaled so it fits the screen's resolution. This is the way I'm thinking about going right now. I'm going to render multiple layers to multiple rendertargets and combine them in the end anyways so it would be easy to scale them in the end.
This is the new DPI approach of Windows Vista and later. Honestly, it's just another way of using option (A) with exactly the same result but more complex implementation. A very bad idea if you ask me as your game will look blurred, degrading visual quality and increasing eye strain.



D) Create assets for different resolutions. Will give the best result for supported resolutions but it requires a lot of work creating the assets. The issue still exists for the resolutions not supported.
E) Use vector art. Vectors can be rasterised at the beginning or during loading. I'm not sure how much expensive it will be do this conversion. Vector art has great potential but there are some images that can't practically be created by vectors.
F) Use procedurally generated content. Like vectors it can be created at runtime for the specific resolution. However it is time consuming to design algorithms for generating images and it obviously won't work in all cases.

These solutions are not elegant and will either require a lot of work without achieving proper result on all configurations, or will degrade the visual quality of your application.



Regarding the aspect ratio:
A) Choose 4:3 ratio. Stretch the canvas for wider aspect ratios. The drawback is obvious. The wider aspect ratio the wierder distortion.
B) Choose 4:3 ratio and draw black bars around the sides. Better than A) in my oppinion but we're wasting screen estate.
C) Show more of the game world depending on the aspect ratio. For some games this will work. For other games it can completely destroy gameplay.
Thinking about aspect ratio is actually a move in the right direction, but you shouldn't really be thinking of aspect ratio per se, rather than the overall layout. My suggestion is the following.

First, try not to think of resolutions. Think of the screen layout and how many layouts you will support. If you have iPad, try to look at it vertically and horizontally.Try to imagine if iPad was shorter but longer (e.g. being a widescreen). Try to draw the organization layout on paper thinking where you will put your game's elements depending on the screen orientation and shape (e.g. closer to 4:3 or closer to 16:9).

Once you have the proper organization strategy, one important issue is how will you handle different DPI settings. For instance, you may want to include large icons and resize them to smaller versions on the fly to take advantage of high DPI displays and make the game look similar on different devices. Another alternative would be putting more elements with higher DPI settings, so instead of bigger icons, the user will see more of them. You can even try some hybrid approach as well.

If you plan your game's conceptual organization on different layouts (vertical/horizontal) and shapes (4:3, widescreen), properly handling different DPI settings, you will make the majority of your users happy. As you can see, this way you are not thinking of resolutions and aspect ratios, and you are not using vectors, procedural content and other stuff, which is not related here anyway. This is the best non-intrusive approach, which in many ways is enforced when you develop for iPhone/iPad, even though it perfectly applies to Windows/Mac OS systems.

In order to properly solve a problem, instead trying to fix the problem itself, you should change the conditions accordingly so the problem ceases to exist. You may want to check this article (http://www.i-choose-self-improvement.com/problem-solving-techniques.html), which is more of philosophical nature, but still applies here.

[User137]

OpenGL is good in that you can scale the coordinates. For example if you use Ortho style drawing, you can do something like:

glLoadIdentity;
glScalef(ClientWidth/100, ClientHeight/100, 1);
And now your coordinates will be 100 x 100 regardless of window size. Any graphics drawn with these will at all times be drawn in full window area, and you don't need to care if it's actually 1024x768 or 640x480. But often times you don't want to do that, because fonts or certain graphics will bend and look bad. Still, it's much faster than drawing to a buffer and scale it.

[pstudio]

I think that in most games, keeping the same experience despite the resolution is crucial, so there goes either fixed resolution or scaling. Scaling has the problem that, oh well, it takes some time and must be done such way that the result is this likeable.

Showing more of the game world will work only for... how to say it? not much action-packed? games. I mean, yes, you can show more space in a shooter, but this will allow the player to see more, making the game easier for him. And if we are talking about multiplayer, perhaps... That is an absolute no-go, as it gives one player advantage over the other. Although this will work fairly for puzzle, or turn-based strategy games, where the gameplay is not affected by one's speed of reaction and ability to tonice things quickly.

My only other idea than showing more of the game world, in case of additional screen space, would be a bigger UI; possibly providing more detailed information (but rather not more information, in terms of quantity) and maybe some additional buffer/shortcut space.

I pretty much agree. I many games it's important to keep the same experience across resolutions and for that reason I'm not keen on just showing more of the game world. At least not without careful consideration. Different UIs for different resolutions could be a solution.


OpenGL is good in that you can scale the coordinates. For example if you use Ortho style drawing, you can do something like:

glLoadIdentity;
glScalef(ClientWidth/100, ClientHeight/100, 1);
And now your coordinates will be 100 x 100 regardless of window size. Any graphics drawn with these will at all times be drawn in full window area, and you don't need to care if it's actually 1024x768 or 640x480. But often times you don't want to do that, because fonts or certain graphics will bend and look bad. Still, it's much faster than drawing to a buffer and scale it.

I don't see this will solve the problem in an elegant way. The game will ultimately be designed for one resolution and the game will look distorted on other resolutions.


Thinking about aspect ratio is actually a move in the right direction, but you shouldn't really be thinking of aspect ratio per se, rather than the overall layout. My suggestion is the following.

First, try not to think of resolutions. Think of the screen layout and how many layouts you will support. If you have iPad, try to look at it vertically and horizontally.Try to imagine if iPad was shorter but longer (e.g. being a widescreen). Try to draw the organization layout on paper thinking where you will put your game's elements depending on the screen orientation and shape (e.g. closer to 4:3 or closer to 16:9).

Once you have the proper organization strategy, one important issue is how will you handle different DPI settings. For instance, you may want to include large icons and resize them to smaller versions on the fly to take advantage of high DPI displays and make the game look similar on different devices. Another alternative would be putting more elements with higher DPI settings, so instead of bigger icons, the user will see more of them. You can even try some hybrid approach as well.

If you plan your game's conceptual organization on different layouts (vertical/horizontal) and shapes (4:3, widescreen), properly handling different DPI settings, you will make the majority of your users happy. As you can see, this way you are not thinking of resolutions and aspect ratios, and you are not using vectors, procedural content and other stuff, which is not related here anyway. This is the best non-intrusive approach, which in many ways is enforced when you develop for iPhone/iPad, even though it perfectly applies to Windows/Mac OS systems.

In order to properly solve a problem, instead trying to fix the problem itself, you should change the conditions accordingly so the problem ceases to exist. You may want to check this article (http://www.i-choose-self-improvement.com/problem-solving-techniques.html), which is more of philosophical nature, but still applies here.

I find this interesting. Right now I'm mostly thinking in classical 2d action games/platformer etc. where the spatial relations between game objects are important. As I see it the layouts will primarily describe different UI layouts. You can't change the game world presentation because this will result in different experinces of the game. The extra space gained using wider aspect ratios can mostly be used for HUD display and insignificant parts of the game world. Or do you disagree with this statement?

Regarding properly DPI handling. What do you think properly DPI handling means? I was thinking of using assets of a high resolution and then downscale. I know resolution doesn't equal DPI or PPI but we typically only use resolution in pixels when talking about graphics in computer games. Is it that important to think in DPI instead? I can imagine that you could possibly gain from increasing font size on high DPI screens but does this the mean you'll have to create layouts for different aspect ratios and different DPI?

[paul_nicholls]

This thread makes some interesting reading, especially as I am thinking of making an Android game, but I not sure how to make a 800x600 game work with the various resolutions/DPI on different Android devices!

[LP]

I find this interesting. Right now I'm mostly thinking in classical 2d action games/platformer etc. where the spatial relations between game objects are important. As I see it the layouts will primarily describe different UI layouts. You can't change the game world presentation because this will result in different experinces of the game. The extra space gained using wider aspect ratios can mostly be used for HUD display and insignificant parts of the game world. Or do you disagree with this statement?
You may not be able to change game world presentation, but you can use it in different layouts (e.g. world on top, hud on bottom, etc.). You can also design HUD with dynamic elements so that it can be presented in a variety of shapes to accommodate for different world positions.



Regarding properly DPI handling. What do you think properly DPI handling means? I was thinking of using assets of a high resolution and then downscale. I know resolution doesn't equal DPI or PPI but we typically only use resolution in pixels when talking about graphics in computer games. Is it that important to think in DPI instead? I can imagine that you could possibly gain from increasing font size on high DPI screens but does this the mean you'll have to create layouts for different aspect ratios and different DPI?
DPI and PPI are exchangeable, so it's the same thing really. One issue is that not all high-DPI displays are properly configured in Windows, so you can see poor users reading tiny text on their 14'' laptop with 1920×1080 resolution, which is mainly due to poor application support. Properly handling different DPI scenarios requires having images in different sizes, or as you said, using larger images and downsizing them on the fly while drawing (use proper mipmapping and antialiasing settings for this). You don't need to create separate layout rather than using a dynamic layout where you automatically specify the size for each of the layers and the elements inside each layer are also automatically accommodated.

[Eric]

This thread makes some interesting reading, especially as I am thinking of making an Android game, but I not sure how to make a 800x600 game work with the various resolutions/DPI on different Android devices!

DPI in itself isn't so much an issue, if you have high/low resolution assets for the high/low DPI cases, you can just scale everything.

However much more problematic are:
* aspect ratio (4:3 vs 16:9 vs every variation that exists), leaving the unused space black works, but isn't too satisfying...
* device size, the ergonomics of a phone and a tablets are different (in terms of real world hand and fingers), and even amongst tablets, you don't handle a 7" tablet in the same way you handle 10"

I'm afraid that some radical UI redesign are necessary in many cases, just like console gamepad UIs don't match desktop mouse+keyboard UI.

[paul_nicholls]

DPI in itself isn't so much an issue, if you have high/low resolution assets for the high/low DPI cases, you can just scale everything.

However much more problematic are:
* aspect ratio (4:3 vs 16:9 vs every variation that exists), leaving the unused space black works, but isn't too satisfying...
* device size, the ergonomics of a phone and a tablets are different (in terms of real world hand and fingers), and even amongst tablets, you don't handle a 7" tablet in the same way you handle 10"

I'm afraid that some radical UI redesign are necessary in many cases, just like console gamepad UIs don't match desktop mouse+keyboard UI.

hmm...all interesting points Eric, thanks! :)

[SilverWarior]

I don't think there is an easy solution to this.
I do think that you should design the game engine acording to targeted audience. So you should optimize your game engine acording to the most comon aspect ratio used on your targeted platforms.
I don't think making different UI's for different aspect ratios is a solution. For instance if you make a bigger UI for users with widescreens you won't achive the same gameplay expirience with those who use standard monitors and would have smaler UI. Especialy if widescreen UI contains more information. So becouse using differen UI won't offer the same gaming expirience showing more world would be much easier solution to do.
But if you do intend for all of your players to have the same gaming expirience then you should lock your games aspect ratio so that only resolutions of that aspect ratio are posible. Also in this case you should take care so that all ingame object are drawn the same size regardles of the screen resolution.

Now as for using different resolutions (DPI's) you should use several instances of your graphics optimized for several different resolutions. Using only graphics optimized for high resolutions and scaling them donwn will make them look blured an lose some importand detailes. (slowly scale down any of your photos in your popular photo editing tool and you wil quickly inderstand what I mean). Also using grapphics optimized for small resolutions and caling them up will make them look pixelated (each pixel will look like smal square).
Offcourse you don't have to make graphics optimized for every posible resolution, you should make your graphics optimized for most oftem used resolutions and then scale them for other always using the one wich are the closest to the target resolution (les scaling means better results).

The best way is to use vectored graphics but as it has been sad not all of the graphics can be vectorised. So this means that the grephics must be developed acordingly from the verry start.

@Little offtopic
Widescreens could be easily used for making games with hotseat multiplayer by splitscreen method (verticaly spliting the scren into wto parts).

[LP]

Now as for using different resolutions (DPI's) you should use several instances of your graphics optimized for several different resolutions. Using only graphics optimized for high resolutions and scaling them donwn will make them look blured an lose some importand detailes. (slowly scale down any of your photos in your popular photo editing tool and you wil quickly inderstand what I mean).
Below in your post you suggest using vectored graphics. Now, if the artwork is rendered using vectored approach in the first place (e.g. Flash, 3D Studio Max, Maya, etc.), then using proper downsampling/multisampling will not make the graphics blurred. In fact, an antialiasing technique that is properly made should work with the image in such way that you will not perceive any visual artifacts or even realize that the image has been downsampled.

Putting cheap/crappy editing software (which may include popular software products such as Photoshop, by the way) as an example does not support your argument.

There is an entire area of sciences that deals with such issues, called Colorimetry. The proper downsampling needs to be made in perceptually uniform color spaces, including but not limited to CIELAB, CIELUV, DIN99, ATD95, CIECAM among many others.

[Cybermonkey]

Speaking of vector graphics, has anyone ever used AggPas to do a game? (Sorry, for being slightly off-topic ...;D)

[pstudio]

You may not be able to change game world presentation, but you can use it in different layouts (e.g. world on top, hud on bottom, etc.). You can also design HUD with dynamic elements so that it can be presented in a variety of shapes to accommodate for different world positions.


DPI and PPI are exchangeable, so it's the same thing really. One issue is that not all high-DPI displays are properly configured in Windows, so you can see poor users reading tiny text on their 14'' laptop with 1920×1080 resolution, which is mainly due to poor application support. Properly handling different DPI scenarios requires having images in different sizes, or as you said, using larger images and downsizing them on the fly while drawing (use proper mipmapping and antialiasing settings for this). You don't need to create separate layout rather than using a dynamic layout where you automatically specify the size for each of the layers and the elements inside each layer are also automatically accommodated.

Ok, I think we're on the same page then. I like this concept as it tries to eliminate the problem (which is basically what the link in your previous post was about). It may require some more work in the design phase of the game but at least this tackles the multiple aspect ratio problem.


I don't think there is an easy solution to this.
I do think that you should design the game engine acording to targeted audience. So you should optimize your game engine acording to the most comon aspect ratio used on your targeted platforms.
I don't think making different UI's for different aspect ratios is a solution. For instance if you make a bigger UI for users with widescreens you won't achive the same gameplay expirience with those who use standard monitors and would have smaler UI. Especialy if widescreen UI contains more information. So becouse using differen UI won't offer the same gaming expirience showing more world would be much easier solution to do.
But if you do intend for all of your players to have the same gaming expirience then you should lock your games aspect ratio so that only resolutions of that aspect ratio are posible. Also in this case you should take care so that all ingame object are drawn the same size regardles of the screen resolution.

As I see it UI is not the only thing that can be changed when using different layouts (though I wrote that in my previous post). If you commit to using several layouts you'll also commit to to think about if anything in your game can change across different layouts.
E.g. when writing console games you have the full tv screen area you can draw on. However there's also a safe area. This is the area all important gameplay and huds should be placed in. This is due to the fact that some tv sets covers up parts of the screen border. The safe area is guarenteed to show up on all tv sets. Likewise you could possibly define a "safe area" in your game that must be displayed exactly the same across all screens. The area outside can then be used differently for each layout. Some will show extre gui stuff. Others will maybe just show extra parts of the game world that doesn't have influence on gameplay.

The point about ensuring the same display size of assets across resolutions is however a good point.



Now as for using different resolutions (DPI's) you should use several instances of your graphics optimized for several different resolutions. Using only graphics optimized for high resolutions and scaling them donwn will make them look blured an lose some importand detailes. (slowly scale down any of your photos in your popular photo editing tool and you wil quickly inderstand what I mean). Also using grapphics optimized for small resolutions and caling them up will make them look pixelated (each pixel will look like smal square).
Offcourse you don't have to make graphics optimized for every posible resolution, you should make your graphics optimized for most oftem used resolutions and then scale them for other always using the one wich are the closest to the target resolution (les scaling means better results).

The best way is to use vectored graphics but as it has been sad not all of the graphics can be vectorised. So this means that the grephics must be developed acordingly from the verry start.

I believe that you can use just one asset and then downscale and still get good results. Sure if you're porting a pc game to a smartphone then it could make sense to create new assets optimised for smaller screens. But it all depends on the game in then end. For a pixel perfect result downscaling obviously wouldn't be a good way to go.
Regarding vector art. Yes in some cases vectors will do, but in many cases it won't.

[SilverWarior]

I believe that you can use just one asset and then downscale and still get good results. Sure if you're porting a pc game to a smartphone then it could make sense to create new assets optimised for smaller screens. But it all depends on the game in then end. For a pixel perfect result downscaling obviously wouldn't be a good way to go.

Have you tried what I sad in my post about downscaling (slowly scale down any of your photos in your popular photo editing tool and you wil quickly understand what I mean).
You should understand that highres graphics would use much more memory for storing them. So if you have a lot of graphics you could soon find out that your game won't be able to run on most older computers, becouse they would lack the necessary graphic memory to store all of those highres graphics in it. Also using higres graphics requires more procesing power from the graphics card especialy when using scaling as this requres even more procesing. So it is posible that many older computers wont have graphics cards wich would be capable of renderning your game with decent FPS.
Yes you could downsample your graphics at the verry start of the game, but this will increase the games loading time quite a bit. And noone likes wating long for the game to load.

Anywhay if it would be so easy ass you think everyboddy would be using this aproach. How many games have you ever seen using this aproach. I don't recal any of them.

[paul_nicholls]

Have you tried what I sad in my post about downscaling (slowly scale down any of your photos in your popular photo editing tool and you wil quickly understand what I mean).

This is only going to cause an issue if an image is repeat-ably down-scaled, thus reducing the quality by lots. Only being down-scaled once is going to be just fine.


You should understand that highres graphics would use much more memory for storing them. So if you have a lot of graphics you could soon find out that your game won't be able to run on most older computers, becouse they would lack the necessary graphic memory to store all of those highres graphics in it. Also using higres graphics requires more procesing power from the graphics card especialy when using scaling as this requres even more procesing. So it is posible that many older computers wont have graphics cards wich would be capable of renderning your game with decent FPS.
Yes you could downsample your graphics at the verry start of the game, but this will increase the games loading time quite a bit. And noone likes wating long for the game to load.

I can see the memory and loading times being an issue, but it might work...


Anywhay if it would be so easy ass you think everyboddy would be using this aproach. How many games have you ever seen using this aproach. I don't recal any of them.

How could you tell if a game used the down-scale approach anyway?

[SilverWarior]

How could you tell if a game used the down-scale approach anyway?

I have a tendacy to dig trough the games files to see which components do they use (sometimes can be easily seen from various dll files wich ship with game). I try to identify resource files containing graphics, sounds, etc. Many times I need to use various unpackers so I can actualy see ingame resources like graphics and sounds.
Do mind that I don't do this with intention of stealing any of theese resources, but seeing them can usualy tell you a lot about the way how game works. This is actialy the way how I learned most about game mechanics up till now.
And NO I don't do revesre enginering of the games code.

[paul_nicholls]

ok, cool :)

[LP]

I have a tendacy to dig trough the games files to see which components do they use (sometimes can be easily seen from various dll files wich ship with game). I try to identify resource files containing graphics, sounds, etc. Many times I need to use various unpackers so I can actualy see ingame resources like graphics and sounds.
Do mind that I don't do this with intention of stealing any of theese resources, but seeing them can usualy tell you a lot about the way how game works.
Note that if such game content is encrypted, you'll be breaking the law in some countries just by using the quoted approach. In either case, you are not making a sound argument here. Many 3D games (FPS/RPG/etc) use rather huge textures, which are later downsampled.

In addition, if you load all graphical resources to system memory, even legacy computers with 256 Mb of RAM (plus another 1 Gb of swap file) will handle it since graphics typically has relatively low footprint compared to sound, music and video files. Nowadays, a typical low-end machine will have at least 1 Gb of RAM, so you don't need to worry about loading hi-res graphics at all. If you are worried about video memory, then you should know that both Direct3D and OpenGL load/unload managed resources to/from video memory on the fly, so only the stuff that is being drawn is usually stored in video memory.

[SilverWarior]

Note that if such game content is encrypted, you'll be breaking the law in some countries just by using the quoted approach.

Yes I know that. I never bother decryptic any content, if I can see some content by using some easy unpacker (usualy found on the web) I do otherwise I don't bother too much.


In either case, you are not making a sound argument here. Many 3D games (FPS/RPG/etc) use rather huge textures, which are later downsampled.

Yes but most of them requires computer with quite powerfull hardware to run.
Also 3D graphic engines sometimes use huge textures wich are actualy colections of smaler graphics (theese are not to be considered as high resolution graphics) and then only portions of theese are used as different 3D models textures. This aproach is usualy used to speed up the thexture lodaing into graphic memory. Also if theese colections are properly organized they can use les graphic memory that it would be used if all of the small textures would be loaded one by one.


In addition, if you load all graphical resources to system memory, even legacy computers with 256 Mb of RAM (plus another 1 Gb of swap file) will handle it since graphics typically has relatively low footprint compared to sound, music and video files.

256 Mb of ram won't alow you to load much graphics in it especialy if we're talking about some highres graphics.
As for the swap file it's size varies a lot. On Windows based system the size of a swapfile or. pagefile as named by Microsoft is 150% of the size of RAM by default. So if you have computer with 256 Mb of RAM the size of the swap file would be 384 Mb. Loading any graphics from the swapfile to graphic memory would be werry slow due to slow hard drive acces. This will result in lots of slowdowns or some graphic content not being drawn when it is suposed to.
Take GTA San Andreas as an example. If you play this game on a low end computer and do some flying with the planes you could sinply crash into the tree before it would be even rendered (texture for the tree isn't loaded into graphic memory fast enough).
Also you should take into consideration that you would ned RAM for other data to. So unless you have smal levels, a few of ingame objects, you can forget about having any higres graphics on pre mentioned computer with only 256 Mb or RAM.


If you are worried about video memory, then you should know that both Direct3D and OpenGL load/unload managed resources to/from video memory on the fly, so only the stuff that is being drawn is usually stored in video memory.

Partly true. But nowadays when there is posible to exploit graphics card processing power to do other things besides just drawing graphics you should note that theese operations also use video memory.

[User137]

On topic of aspect ratio, not sure how much of this is said already, but many games let user himself choose how he wants to scale the UI. Most 3D games support this now. For example imagine someone with imaginary 2400x1800 resolution. You can't know how big or small he wants the UI to look. Maybe he is used to look small things possibly because his display is huge. So just because resolution is big, it's not *always* the right choice to scale things up. Depends on what you're drawing...

Also as i mentioned OpenGL earlier, even if it's 2D game its all vector graphics (polygons). Texture size doesn't matter (well, low/med/high settings for performance can be good always), bi-linear filtering is smooth to look at. They can also be drawn pixel-perfect without scaling. Vector graphics have speed benefit where you don't have or need your own doublebuffer, to get effect of "stretching" graphics.

[SilverWarior]

Also as i mentioned OpenGL earlier, even if it's 2D game its all vector graphics (polygons). Texture size doesn't matter (well, low/med/high settings for performance can be good always), bi-linear filtering is smooth to look at. They can also be drawn pixel-perfect without scaling. Vector graphics have speed benefit where you don't have or need your own doublebuffer, to get effect of "stretching" graphics.

Offcourse the texture size matters. Polyon is actualy just an surface on witch the texture is being drawn. So if you have small texture and larg polygon you will have to upscale the texture so it can be drawn on whole polygon (just like increasing picture size). If you have big texture and small polygon on other hand the texture itself would be scaled down so that it could be properly drawn on the polygon (just as if you would reduce the picture size).
The only difference is that when using polygons the texture scaling is done by the graphic card itself. And since most graphics cards have hardware support for textre scaling there is a considerable performance boost.