• Advertisement
Sign in to follow this  

Draw game to texture, then scale it to desktop resolution?

This topic is 786 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi

Now my 2D games (uses a directx-based engine and c++) can be launched in some common resolutions and in fullscreen or windowed mode. But all buttons etc are placed with pixel-positions so scaling is a bit messy.

 

Would this work better? :

What if I instead always used a 1920x1080 texture and drew EVERYTHING in my game to this texture (right now i draw to screen buffer). Then I rescale this texture once (if desktop resolution of the player is other than 1920x1080) and send this texture to the screen buffer. It would mean that I dont need to worry about gameworld/ui scaling.

 

It will cost some performance I guess but might be worth it.

 

Thanks

Erik

Edited by suliman

Share this post


Link to post
Share on other sites
Advertisement

Technically there should be no problem in first render to texture an then render a fullscreen quad with this texture on it. Just thinking how this may look like....

 

If you optimize your game for 1920x1080 and got me thinking about my 30" 4k Resolution, i won't imagine how huge your UI will be on this screen. And possible how ugli this looks.

The otherway round if you got someone with smal display resolution (1024x768 for example) the whole ui will be very small und difficult to use.

 

I say it would be better to implement gameworld/ui scaling correctly.

Share this post


Link to post
Share on other sites
I do something similiar. The 3d world is rendered to according buffers, which will be upscaled to window size, whereas the gui is always rendered in the native resolution on top of this.

You should consider, to render only to a lower or same resolution and you should avoid to freely scale the GUI (maybe only 2x or 4x scaling). My gui system is not fix, it is very flexible and will rearrange to any resolution and aspect ratio. Therefor, when rendering to lower resolution, you should keep the aspect ratio of the native window resolution.

Share this post


Link to post
Share on other sites

I currently have similar issue with an Android App that I am working on. I defined everything in a sort of screen space (where the lowest dimension is always -1 to +1 and the longer direction is sized accordingly using aspect ratio). Scaling worked ok until I started using tablets at which point things looked too big. With that though I get metrics about screen density/size so I use that to limit the size.

 

you could use a similar approach but since you won't get metrics on density/size you could offer the scaling value in the options so users can tweak it. Your ui elements would be anchored to something, either top, left, right, bottom etc and then you would define their sizes/offsets using a unit independent of pixel size, where height is 0-1 and where width is 0 to aspect ratio. You could reasonably easily convert your 1920*1080 to that system just by dividing by 1080.

 

Now your values are independent of screen size, if a button is of height 0.25 then on a 1080 screen it becomes 1080*0.25=270 pixels heigh but on a 720 screen it becomes 720*0.25 = 180 high. Similar for larger screens. It'll always take up the same proportion of the screen. Of course as has been pointed out, on larger screens your ui might end up looking way too big, at that point you apply the scaling value from your options. If someone sets it to 50% (0.5) then : 1080*0.5*0.25 = 135 high.

 

Because you are anchoring the ui elements they will move correctly too, the entire ui won't shrink towards the top left but instead each element will move off towards it's anchor (elements on the left will stay left, elements on the right will shrink towards the right). It also accounts for screens of different aspect ratios, wider screens will just separate in the middle.

Share this post


Link to post
Share on other sites

I'm using only 2d.

As for 4K, I have no support for that now either:)

 

But why would anchorpoints be better than the method i describe? It would require MUCH more work as I need to go through all the code for everything placed. And each sprite would need to be scaled and positioned right?

 

I do mostly strategy/management games and such (plenty of panels, text, icons, buttons everywhere, VERY different from a 3D FPS which has a large main 3D-view and a just some meters/buttons along the borders).

Share this post


Link to post
Share on other sites

I was thinking 2D. It's all extra work and if the method you describe works then you should go for it. It does sound like the simplest way to deal with this. you would of course get slightly squashed looking UI is someone uses a smaller aspect ratio.

 

The anchoring I mentioned is just a way for you to be able to scale the ui such that it will shrink out towards the sides rather than towards one corner (which would mean things on the bottom/right moving away from the edge and towards the top right). You wouldn't get this issue with your scaling, only if you allowed UI to scale independently of the window resolution (such as if someone with a huge screen wants to make the ui smaller).  It also neatly deals with different aspect ratios. It is just food for thought. Your solution should certainly work and is the ismplest to implement. Worth trying before doing anything more extreme.

Edited by Nanoha

Share this post


Link to post
Share on other sites

three basic approaches possible:

 

1. stretchblit.  render to offscreen surface, then blit to current screen rez. can be slow. may not scale well, somewhat easier to implement.

 

2. modify your text and blit routines to convert hard coded positions and scales to the current screen rez.  extreme upscaling can still look bad.  for example, i started coding caveman at 1600x900. i later modified the text and blit routines to autoscale to the current rez. so i still code to 1600x900 and the modified routines do the rest. perhaps a little more work than #1 above overall.

 

3. create device independent text and blit routines based on a very high virtual screen resolution such as 10000x10000.  same idea as #2 above, but you code to a 10000x10000 screen instead of 1600x900 or whatever.  since you only scale down, not up, it always looks good. downside is you have to change existing calls to use 10000x10000 coordinates.  more work than #2 if you already started coding at a lower resolution. probably the best option for new projects.

Share this post


Link to post
Share on other sites

Scaling should be screen independent. Your windows resolution is usually 72dpi, which does well enough for most systems. The best way to work with this however is up to implementation. Usually big companies have Scaleform, which is vector based so they can get away with it.

But for raster based UI there are two approaches. The first one is similar to how Windows and Websites do it, which is by using a map of textures. So corners, sides, and then the middle, which must be tileable.

 

The another way to do it, is to use a larger UI image, and scale down. So you'd need to normalize your scaling to get it to work correctly.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement