• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
noatom

How do you achieve resolution independence?

13 posts in this topic

Say I have this:

My resolution is 800x600.I make a game that has a sprite at 400,300,that means the middle of the screen.I give that game to a friend,that has a resolution of 1920x1080.

 

What will happen? the sprite will appear very far from the middle of the screen,but very close to the left side of the screen.

 

So how can I solve this?

0

Share this post


Link to post
Share on other sites

Hi.

I'd say save the screen resolution in some class member (Variable), and when creating the sprite, make it "screenwidth/2" with "screenheight/2". I'm assuming now that you're working in fullscreen mode and the user can select a screen resolution. If yet set the 800x600 resolution hard in your code, then there won't be an issue, only the window will appear smaller since he has a higher resolution :)

good luck

0

Share this post


Link to post
Share on other sites

Just store the x,y position in the [0...1] range and scale it to the display. It's not the entirety of it, as you'll need to handle different aspect ratio's. But thats the basics.

 

n!

1

Share this post


Link to post
Share on other sites

cozzie..that doesn't make any sense.What will happen when I'll have 90 sprites? the same goes for nfactorial...

0

Share this post


Link to post
Share on other sites

cozzie..that doesn't make any sense.What will happen when I'll have 90 sprites? the same goes for nfactorial...

nfactorial's suggestion does make sense. You can make your rendering window so it's scaled to be a size of 1x1, so that if you want to put something in the center, it's position is (0.5, 0.5). If you want the top left, it's (0, 0). If you want the bottom right, it's (1, 1). Like he mentioned, if you want different aspect ratios to be supported, you might have to be a bit more clever than that.

1

Share this post


Link to post
Share on other sites

clever how?! I can't believe there is nothing on google about this subject!

Edited by noatom
-1

Share this post


Link to post
Share on other sites

Basically what you do is, you have all your game objects positioned using a custom coordinate system.

 

Then you can lets say create 2 objects, both 1*1 units, even if the first one is 10*10 pixels and the second 256*256. All you need to do is scale them. Though you probably will want the same precision on all objects.

 

Now, with your custom coordinate system, you can say that 1 unit = 1 screen height. So if you have a 256*256 sprite, and you have it 1*1 units in your game coordinates, it will always be scaled to be 1 screen height regardless of how many pixels the screen has. Same with position (eg. 0.333 will always be 1 third of the screen)

 

On different aspect ratios you will have different amount of objects visible because 1 screen shows more of your world on the X axis than another (unless you use a black border of some type, or decide that 1 unit=1 screen width, so bigger aspect ratio would show LESS of the world on Y axis)

 

Of course, what this means that if you have your 16*16 sprite, it will not be 16*16 pixels, which might produce visual artifacts. You may try to avoid that by scaling so that its always some multiple of the real size (so 1 unit= some multiple of lets say 16 pixels, so 16, 32, 48, 64...) and choose the best scaling for the screen (so it always shows approximately the right amount of the world, sometimes less sometimes more)

 

For GUIs you might want something different, because you might not want them to be the same scale on all screens. A GUI might might look ok on a 800*600 screen might look blurry and hard to read on a 1920*1080 screen. What ive seen often used is a system where the positions and sizes are combinations of (Unit, Pixel offset) so (0.5,100) would be "100 pixels from the center". The values can be negative so you can start the count from either side of the screen.

0

Share this post


Link to post
Share on other sites

Did you take a look at the solution i posted. That is the easist way to go about doing it without having to change any of your code. And it will work with any resolution

1

Share this post


Link to post
Share on other sites

you have 2 basic approaches to choose from, both of which have been mentioned:

 

1. virtual coordinates.  you code everything using virtual coordinates, such as 0 to 1.0 by 0 to 1.0 or   10,000x10,000 or whatever.   

everything you draw, each time you draw, you convert the coords to the current hardware resolution.

 

2. stretchblit.   you code everything at one resolution (such as your 800x600), draw to an offscreen surface, then strechblit the offscreen surface to the screen.

 

the first method, you have 1 float mul (or one int mul and one int div) for each coordinate and scale to be converted.

 

the second method you have the overhead of an offscreen render, and a stretchblit every frame.

 

You'd have to test to determine which would be faster. method #1 i suspect, as its just int mul's and div's in fast system ram, vs a strechblit in slow vidram.

 

However, method 2 is easier to implement, especially since you didn't address this issue when you first started your project (as you should have, but hey, now you know, right?).

1

Share this post


Link to post
Share on other sites

The way i have handle that in my 2d engine i wrote 2 years ago whas to rendered the whole screen into an texture. then Create a Screen aligned quad that is the same size as the display you want. Then apply the texture to fit the whole quad. That way you can always render your game in an 800x600 resolution and you can upscale or downscale with that technique.

That will still cause you to have aspect ratio artifacts when it changes from 4:3 to 16:9 or 16:10 or anything else though. Your best bet is to render into a -1..1 range for your render target and then use the projection matrix on the rendertarget and final render to correct how square the pixels in each step need to be.
1

Share this post


Link to post
Share on other sites

Or apply the aspect ratio to the width or height (depending on whether you rely on horizontal fov or vertical) to correct it. For example if (like most games these days) your 16:9 image sees more on the sides than a 4:3 image, apply w/h to h to get a correct, square result.

0

Share this post


Link to post
Share on other sites

Why not just use an ortho projection?  Build the correct projection matrix, load it, draw.  There's no rule that says that the inputs to such a projection must be the same as your screen resolution, so you can use this to achieve a virtual coordinate system entirely on the GPU.  Dear old Quake did it in 1996, you can do it today.

 

@NormanBarrows : video RAM is not slow.  Transfers between the two different types of memory (system and video) can be slow, but if everything is kept in video RAM all of the time it is not slow.  Why else do you think vertex buffers, texture objects, etc exist?

0

Share this post


Link to post
Share on other sites

The way i have handle that in my 2d engine i wrote 2 years ago whas to rendered the whole screen into an texture. then Create a Screen aligned quad that is the same size as the display you want. Then apply the texture to fit the whole quad. That way you can always render your game in an 800x600 resolution and you can upscale or downscale with that technique.

That will still cause you to have aspect ratio artifacts when it changes from 4:3 to 16:9 or 16:10 or anything else though. Your best bet is to render into a -1..1 range for your render target and then use the projection matrix on the rendertarget and final render to correct how square the pixels in each step need to be.

That makes no sense, because first of all when you render your quad to be screen aligned you will need to set up an orthographic projection which will use the screen resolution. So when you create your quad that is the same Width and Height as your resolution it will be an 1:1 representation, so when you apply the texture it will mapped 1:1 as well. So i do not see the scale issue you are talking about.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0