• 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
proanim

scaling sprites

11 posts in this topic

I remember playing F.E.A.R. when it came out, at the time this was not an issue but later when I was able to play at higher resolutions, I noticed that GUI was smaller and smaller on higher resolutions and fonts were scaled up (they were TTF font (I think) after all). I didn't notice this in other games, and I know there is a way to avoid this. How exactly should this be handled regardless of game? If I have a sprite that that has certain dimensions how can I make it cover same amount of screen on all screen resolutions?

0

Share this post


Link to post
Share on other sites

Either scale it, or provide multiple versions for the different resolutions. Or use vector art (which is how a font is able to scale) for which scaling is well-supported.

0

Share this post


Link to post
Share on other sites

When rescaling sprites can lose fidelity, I don't want that. Which format can be used for vector art so it is usable with OpenGL or SDL?

0

Share this post


Link to post
Share on other sites

There are several methods for dealing with sprite scaling (mipmapping and filtering immediately spring to mind).

 

Switching to vector graphics is a pretty significant change in your graphics design. Just be aware that it's not your only option.

1

Share this post


Link to post
Share on other sites

Sometimes, yes - depending on the details of the image itself. Also, it depends on what kind of scaling algorithm you use.

If it's a simple GUI element, it probably won't look too bad.

 

You could always make a high res one, save it. Resize it using a good algorithm in your image editor, manually correct any mistakes, save it as a Mid-res version. Repeat for the low-res one. Then just use the closest match, and add more versions between high, mid, and low, if needed.

 

But at that point, you might as well use a vector image - and use your vector image editor to generate the various resolutions of the image for you, and then ship the various images, but not the vector image itself, with your program.

0

Share this post


Link to post
Share on other sites
FYI, if you are using the rendering API in SDL2, there is a function SDL_RenderSetLogicalSize which allows you to program to a fixed resolution no matter the resolution of the display window. The entire output is scaled by the hardware (assuming the D3D or OpenGL renderer). This is a painless alternative to handling SVGs. I'm using it to good effect in a game I'm working on right now. It's a low-res game, so I'm rendering to an 800x600 logical size. For high-res graphics, you'd want to render to a higher logical resolution that would then be scaled down. I don't know for sure what sort of effect it would have on quality in that case, but it would certainly be worth looking into before going all SVG and scaling individual images.
0

Share this post


Link to post
Share on other sites

SDL2 isn't ready yet there is some better stuff in it, but I would still like to avoid it until it is officially released. I can scale my sprites using streching which appears to have good effect when downscaling. So, any advice on how can I calculate how much I should resize the sprite depending on screen resolution, so it covers 'the same' amount of screen? The problem that I currently see is that I can't exactly tell if the sprite is scaled up enough. I am currently testing with 640x480 and 800x600 resolutions.

0

Share this post


Link to post
Share on other sites

FYI, if you are using the rendering API in SDL2, there is a function SDL_RenderSetLogicalSize which allows you to program to a fixed resolution no matter the resolution of the display window. The entire output is scaled by the hardware (assuming the D3D or OpenGL renderer). This is a painless alternative to handling SVGs. I'm using it to good effect in a game I'm working on right now. It's a low-res game, so I'm rendering to an 800x600 logical size. For high-res graphics, you'd want to render to a higher logical resolution that would then be scaled down. I don't know for sure what sort of effect it would have on quality in that case, but it would certainly be worth looking into before going all SVG and scaling individual images.

 

I'm not familiar with SDL2, but SFML has something similar (using 'views'), and is an awesome by-product of the nature of the 3D APIs which SDL2 and SFML are built upon.

While nice and useful for most things (the game content itself)... if you use it with your GUI, still have to take into account the *ratio* of the resolution, or your GUI can get stretched in ways you don't want.

 

SDL2 isn't ready yet there is some better stuff in it, but I would still like to avoid it until it is officially released. I can scale my sprites using streching which appears to have good effect when downscaling. So, any advice on how can I calculate how much I should resize the sprite depending on screen resolution, so it covers 'the same' amount of screen? The problem that I currently see is that I can't exactly tell if the sprite is scaled up enough. I am currently testing with 640x480 and 800x600 resolutions.

 

The cheap and easy way is to use percentages (well, 0.0 to 1.0). If the GUI element is 20 pixels of a 800 pixel wide screen, that's 0.025f the screen. So for a 1024 wide screen, you might resize it to 26 pixels wide (1024 * 0.025 = 25.6). Bu you also want to keep the the element from being stretched out of it's shape, so you need to calculate the width of the element relative to it's height, then multiply.

float guiElementRatio = (NormalElementHeight / NormalElementWidth);
float elementRelativeWidth = (NormalElementWidth / NormalScreenWidth);

int currentElementWidth = (CurrentScreenWidth * elementRelativeWidth);
int currentElementHeight = (currentElementWidth * guiElementRatio);

I was resizing the elements based on the width of the screen - in retrospect, resizing the elements based off of the height of the screen is a better solution.

 

Anyway, you can do the same with the element's position. As mentioned, this is the cheap and easy way - a more difficult but superior solutions also have the elements morphing in the content they show, as more screen space becomes available or scarcer.

Edited by Servant of the Lord
2

Share this post


Link to post
Share on other sites

While nice and useful for most things (the game content itself)... if you use it with your GUI, still have to take into account the *ratio* of the resolution, or your GUI can get stretched in ways you don't want.

SDL's implementation will also take care of this for you. From the function documentation:

This function uses the viewport and scaling functionality to allow a fixed logical
resolution for rendering, regardless of the actual output resolution. If the actual
output resolution doesn't have the same aspect ratio the output rendering will be
centered within the output display.

As I said, I'm using it to good effect.

SDL2 isn't ready yet there is some better stuff in it, but I would still like to avoid it until it is officially released.

It's perfectly usable now. I've been using it for just about a year without any hassle at all. There's an occasional API change, but nothing drastic or difficult to keep up with. I can't imagine going back to 1.2. Do what works for you now, but I would definitely recommend giving SDL 2 a look over 1.2 for your next project whether it's officially released or not.

I can scale my sprites using streching which appears to have good effect when downscaling. So, any advice on how can I calculate how much I should resize the sprite depending on screen resolution, so it covers 'the same' amount of screen? The problem that I currently see is that I can't exactly tell if the sprite is scaled up enough. I am currently testing with 640x480 and 800x600 resolutions.

One way is to work with percentages. You pick a target resolution and the sprite size you want to show at that resolution becomes your 100% base. Then, as you scale the resolution down, you scale the sprite by a percentage relative to difference in resolutions. You'll have to account for aspect ratio in your calculation to avoid stretching.

Another approach is to preconfigure a scale factor for different resolutions. Implement some test code to manually cycle through different scale factors at different resolutions to see which look best. Save those off into an array/config file/script and at game startup or on resolution change, pick the appropriate value and use it as a global scale factor. If taking this route, you'll likely want to combine it with the percentage-based approach to cover the case when the user configures a resolution you didn't anticipate.
1

Share this post


Link to post
Share on other sites

You can render UI to a texture. So you can have a UI texture 1024x1024 in size regardless of the size of the rendered scene. Your UI will then be downsampled to fit a scene less then 1024x1024 in size and upsampled to a scene larger then 1024x1024 in size.

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