next »

[Mega]

For a game that runs fullscreen, what are the pros and cons of having screen resolution lower than 640*480. Not in terms of quality or L.O.D but interms of technical issues.

I know a few but what are all the ones you've encountered.

[pgil]

How many monitors even support resolutions below 640x480?  I think you're better off staying at the native resolution and scaling up. 

[Netsu]

How many monitors even support resolutions below 640x480?  I think you're better off staying at the native resolution and scaling up. 

I think today it's not up to the monitor but to the driver and graphics card. They scale and stretch the video output. But regarding the original question, I don't know of any technical arguments FOR using resolutions lower than 640x480. Support for mobile devices and antique hardware (that most probably won't run the game anyway)?
But aren't you just better off letting the user decide what resolution he wants his game to run in?

[st33d]

Heh, at home I'm working at a 320x240 resolution (scaled) and at work I'm making an experimental game at 50x50 resolution (actual size with a scaling option).

Since rendering it is very cheap, the only real issues are up-scaling the result in a professional manner and visual communication.

On the 50x50 I'm already seeing a variety of communication issues such as the inability to use text (no we really can't expect the player to wait through a ticker of text) and giving elements enough contrast. Not the least to say that everything must be intuitive from the start.

However, I will say that I find working at low resolution extremely interesting. The restrictions are a welcome challenge and encourage spartan workflow.

[Richard Kain]

For my part, I really, really despise letting a monitor or TV screen handle scaling on its own. I think the developer should always plan on handling their own scaling. If I'm planning on having a game in a more "retro" resolution, I like to detect the resolution of the monitor, and then scale the graphics of the game accordingly, to the closest integer value. Scaling by integer values, as opposed to decimal values, helps to preserve the look of the original graphics. I'm okay if the game graphics don't fit precisely to the monitor, some blank space on the sides or top and bottom is acceptable, so long as the original aspect ratio and appearance are consistent.

[PompiPompi]

I think he asked about setting the monitor\GPU to a low resolution. Not the graphical design issues with lower resolution.
But that was already answered, if you want your GAME to have a low resolution just use any native SCREEN and just draw bigger pixels.
So for instance if your GAME resolution is 320x240, and your SCREEN resolution is 640x480, you choose 640x480 as your screen resolution but instead of drawing your sprite as is, you draw each pixel of the sprite as a 2x2 pixels square.

[Rob Lach]

Right now I'm coding something at 160x90 res.

Your biggest technical issue would be text. I hacked around that by rendering text post scaling but some positioning bugs emerge because everything needs to be placed on a float based grid. Eventually I'll decouple the UI from the window resolution which should fix that.

[Mega]

I think he asked about setting the monitor\GPU to a low resolution. Not the graphical design issues with lower resolution.
But that was already answered, if you want your GAME to have a low resolution just use any native SCREEN and just draw bigger pixels.
So for instance if your GAME resolution is 320x240, and your SCREEN resolution is 640x480, you choose 640x480 as your screen resolution but instead of drawing your sprite as is, you draw each pixel of the sprite as a 2x2 pixels square.

Sorry , if I wasn't clear. It was a general question, though you're right I was more worried about that aspect of it. I've done some tests and decided similar to what you're saying. I'm concerned mainly that there might be some hardware that would not work with such low ratios for whatever technical reasons.

I guess so long as I keep the aspect ratio the same it doesnt matter the values.
I even tried 64x48, The environment didn't scale it full screen instead it was centered and padded with black border.

[PompiPompi]

I don't understand why you are saying there are hardware limitations?
You just pick a resolution the hardware support, and do some scaling\cropping\matching to match the real resolution you want.
The hardware limitation is that you can't pick whatever HARDWARE resoution you want. But the good thing almost all hardware will support a resolution bigger than the resolution you want, so you can work it out to emulate the resolution you want.

[Richard Kain]

Once upon a time, CRT monitors were the norm, and there was never really any problems with scaling. CRT monitors are able to display any number of resolutions, and do so capably. These days, however, it's all about fixed-resolution flat-screen displays. As many advantages as flat-screen displays provide, resolution switching isn't one of them. So these days you have to take whole slew of varying resolutions into account.

[Trevor Dunbar]

Use a Scaling Matrix (just an identity matrix with 2's, 3's, etc in place of the ones) on a simple rectangle textured with your native sized drawing surface/render target/whatever you want to call it.

You could even do effects like using a shader on your render target or using a rotation matrix to rotate the entire screen plane if you wanted.

This is assuming you actually are writing/making a game in an environment capable of this, but you should be able to.

Also-
Most modern graphics cards won't let your program go below a specific resolution ( like < 800 by 600) for a full-screen application and that's just the way it is. Just scale-up your graphics or use a window.

Also-
It's not really a giant problem unless you want to run old windows games with those resolutions and when they use palleted colors and stuff.
It gets really nasty trying to run Space Quest 4/5/6 for example without like patches or DOSbox or something.

[PompiPompi]

Once upon a time, CRT monitors were the norm, and there was never really any problems with scaling. CRT monitors are able to display any number of resolutions, and do so capably. These days, however, it's all about fixed-resolution flat-screen displays. As many advantages as flat-screen displays provide, resolution switching isn't one of them. So these days you have to take whole slew of varying resolutions into account.

You either do a best fit of the GAME resolution to the hardware resolution. Like using 320x240 if you know the HARDWARE resolution is 640x480, ir you use what available scaling there is in the device(usually done on the GPU). You can also do cropping if the resolution don't match by only scaling. It's not that difficult, and there arn't reall many other options.

[Mega]

@Trevor why do the modern cards not allow rsolutions below a minimum.
so you're saying scaling up the assets is the safest way to go..?

The main benifits were blit speed and less required Detail in artwork

scaling up the sprite achieves the detail part.
But a lower resolution is simply faster...no?


Considering that the 'Steam' gaming site has a minimum resolution of 800x600.
What does that mean exactly? and does it apply to a fullscreen game?

[Richard Kain]

But a lower resolution is simply faster...no?

It really depends on what rendering method you are using, and how you are intending to scale. If you are using OpenGL, then a popular method would be to do your actual rendering using a Framebuffer Object, and then draw the framebuffer object into a texture that you then stretch across a quad. Once you've reached that point, you can scale and reshape the quad however you please, and you're drawing calls will still be fairly well optimized. Even though your application would be rendered at a higher resolution, your actual drawing would be at a lower resolution, and you would reap the benefits of that.

If you were dealing with a purely blitting solution, running at a higher resolution might not result in any performance savings.

[PompiPompi]

GPUs nowadays are pretty fast, even on mobiles.
I don't think you need to worry about GPU related performance on a sprite game, unless you intend to do a lot of sprites on a very high resolution(which you don't).
You are more likely to have CPU performance issues rather than GPU. Unless you are doing something funky with the visuals.
My advice is to choose what is easiest to implement, and if afterwards you have GPU related performance issues(unlikely), then you can refactor a different solution or improve it.