How does scaling work in a game with Pixel sprites?

[Gil]

OS resolution scaling can blur certain things. I don't think it's a problem for drawing tools, but I'm not sure. It's usually UI fonts that suffer most.

[Kepler4]

OS resolution scaling can blur certain things. I don't think it's a problem for drawing tools, but I'm not sure. It's usually UI fonts that suffer most.

OK thanks.

I have a few more questions about scaling.

Let's say I like the look of GBA pixel art which is 240x160. Does that mean I should make everything at 240x160 and have the game scale to screen size?  (Example: http://i.imgur.com/CMgSs.jpg)

(Another example of the resolution I am considering: http://33.media.tumblr.com/91268f51edbe017edac635157a1c333d/tumblr_nlaq8aGXw61qze3hdo1_500.gif)

Is it just counting pixels to make sure your sprites are the right size for your background?

[questseeker]

OS resolution scaling can blur certain things. I don't think it's a problem for drawing tools, but I'm not sure. It's usually UI fonts that suffer most.

Let's say I like the look of GBA pixel art which is 240x160. Does that mean I should make everything at 240x160 and have the game scale to screen size? 

As usual, things aren't so simple: game art is meant to look "good", whatever your intent is, only at a certain resolution (on any modern device, vastly higher than on the GBA), in a certain range of viewing distances (comparable to the GBA on a similarly handheld smartphone, larger on a computer screen, much larger in a TV and couch console setup), and with specific technology (current LCD displays are likely to have better contrast and brightness than the GBA). Anything else means your art won't look as intended: confusingly small at excessive distance, jagged and noisy if the display is too sharp and/or close, possibly too dark or too bright or with strange colours.

GBA art was as detailed as the small and close GBA screen allowed; assuming you have GBA-like sprites to adapt, if you want a similarly detailed appearance you have to scale everything up with adequate antialiasing and retouch anything that was simplified (redrawing from scratch using the original as a reference might be a better idea), while if you want a blocky retro appearance many combinations and compromises of nearest-neighbour scaling, palette-respecting interpolation tricks like HQ2x and hand-retouched antialiasing are possible.

[Gil]

GBA art was as detailed as the small and close GBA screen allowed; assuming you have GBA-like sprites to adapt, if you want a similarly detailed appearance you have to scale everything up with adequate antialiasing and retouch anything that was simplified (redrawing from scratch using the original as a reference might be a better idea), while if you want a blocky retro appearance many combinations and compromises of nearest-neighbour scaling, palette-respecting interpolation tricks like HQ2x and hand-retouched antialiasing are possible.

Or you just do what we've been talking about in this thread and find a good, simple scaling algorithm? I wouldn't recommend anything that "smartly" adapts the pixels like HQ2x, you want to always go for nearest-neighbor.

[Ai]

Well anyway, 'I like 240x160, I'll target that' is not quite sensible thought process. The feel of the final result is really about size of each 'pixel'; if you like 240x160 you need to think about how large the pixels will need to be on phone, using information about the respective PPIs of the GBA and of the phone screen. There is also stuff relating to different contrast ratios of displays which can heavily effect color quality.

In your position I would be making up some sample images, with different numbers of real pixels per seen 'pixel' -- 1x, 2x, 3x, 4x.. uploading them to the phone, figuring out some way to view them at exactly 100% zoom, and getting a feel for how the different scale factors look on phone. As well as the cosmetic conditions affecting it -- glare and cut-down display technology. Preparing some color gradient and texture samples to compare computer screen vs phone would be smart too, now that I think of it..

Then you would be in a position to make an informed decision about art design for your game.

(OT-ish: yeah, HQ2x, scale2x, 2xsai etc all, from experience, have this 'levels of detail' problem: The art was made at X level of detail and semi-smart guessing about implied shapes will only ever resolve those shapes more clearly, not change the design to give you 2x more detail / expression -- which is what naturally happens when you have more pixels to work with. They all have a 'coarse' feel as a result.)

[RedSuinit]

Well anyway, 'I like 240x160, I'll target that' is not quite sensible thought process. The feel of the final result is really about size of each 'pixel'; if you like 240x160 you need to think about how large the pixels will need to be on phone, using information about the respective PPIs of the GBA and of the phone screen. There is also stuff relating to different contrast ratios of displays which can heavily effect color quality.

In your position I would be making up some sample images, with different numbers of real pixels per seen 'pixel' -- 1x, 2x, 3x, 4x.. uploading them to the phone, figuring out some way to view them at exactly 100% zoom, and getting a feel for how the different scale factors look on phone. As well as the cosmetic conditions affecting it -- glare and cut-down display technology. Preparing some color gradient and texture samples to compare computer screen vs phone would be smart too, now that I think of it..

Then you would be in a position to make an informed decision about art design for your game.

(OT-ish: yeah, HQ2x, scale2x, 2xsai etc all, from experience, have this 'levels of detail' problem: The art was made at X level of detail and semi-smart guessing about implied shapes will only ever resolve those shapes more clearly, not change the design to give you 2x more detail / expression -- which is what naturally happens when you have more pixels to work with. They all have a 'coarse' feel as a result.)

What I did is create a PC version of the game and tested it at every resolution. The only method is to build in that buffer of sprites with "useless" filler. If you are targeting a wide range of devices, it's the only option for a pixel perfect picture at every resolution.

[Ai]

I'm not disagreeing; That's one of the strategies that you can employ once you have a feel for what exactly the problem you're dealing with is.

My post really was just meant to point out that 'I like 240x160 GBA' is actually relatively meaningless for art direction purposes; any aesthetic choice needs to be grounded in a concrete experience of the metrics and display characteristics of at least some of the devices involved, not vague impressions of a single device.

[Kepler4]

OS resolution scaling can blur certain things. I don't think it's a problem for drawing tools, but I'm not sure. It's usually UI fonts that suffer most.

Let's say I like the look of GBA pixel art which is 240x160. Does that mean I should make everything at 240x160 and have the game scale to screen size? 

As usual, things aren't so simple: game art is meant to look "good", whatever your intent is, only at a certain resolution (on any modern device, vastly higher than on the GBA), in a certain range of viewing distances (comparable to the GBA on a similarly handheld smartphone, larger on a computer screen, much larger in a TV and couch console setup), and with specific technology (current LCD displays are likely to have better contrast and brightness than the GBA). Anything else means your art won't look as intended: confusingly small at excessive distance, jagged and noisy if the display is too sharp and/or close, possibly too dark or too bright or with strange colours.

GBA art was as detailed as the small and close GBA screen allowed; assuming you have GBA-like sprites to adapt, if you want a similarly detailed appearance you have to scale everything up with adequate antialiasing and retouch anything that was simplified (redrawing from scratch using the original as a reference might be a better idea), while if you want a blocky retro appearance many combinations and compromises of nearest-neighbour scaling, palette-respecting interpolation tricks like HQ2x and hand-retouched antialiasing are possible.

I'm not moving things form a GBA size to a PC screen size. I'm trying to understand how I decide how big the sprites are because there are multiple resolutions that a game could be played at.

GBA art was as detailed as the small and close GBA screen allowed; assuming you have GBA-like sprites to adapt, if you want a similarly detailed appearance you have to scale everything up with adequate antialiasing and retouch anything that was simplified (redrawing from scratch using the original as a reference might be a better idea), while if you want a blocky retro appearance many combinations and compromises of nearest-neighbour scaling, palette-respecting interpolation tricks like HQ2x and hand-retouched antialiasing are possible.

Or you just do what we've been talking about in this thread and find a good, simple scaling algorithm? I wouldn't recommend anything that "smartly" adapts the pixels like HQ2x, you want to always go for nearest-neighbor.

But where and how? Are we talking about an in-engine thing or something like Rotsprite?

Well anyway, 'I like 240x160, I'll target that' is not quite sensible thought process. The feel of the final result is really about size of each 'pixel'; if you like 240x160 you need to think about how large the pixels will need to be on phone, using information about the respective PPIs of the GBA and of the phone screen. There is also stuff relating to different contrast ratios of displays which can heavily effect color quality.

In your position I would be making up some sample images, with different numbers of real pixels per seen 'pixel' -- 1x, 2x, 3x, 4x.. uploading them to the phone, figuring out some way to view them at exactly 100% zoom, and getting a feel for how the different scale factors look on phone. As well as the cosmetic conditions affecting it -- glare and cut-down display technology. Preparing some color gradient and texture samples to compare computer screen vs phone would be smart too, now that I think of it..

Then you would be in a position to make an informed decision about art design for your game.

(OT-ish: yeah, HQ2x, scale2x, 2xsai etc all, from experience, have this 'levels of detail' problem: The art was made at X level of detail and semi-smart guessing about implied shapes will only ever resolve those shapes more clearly, not change the design to give you 2x more detail / expression -- which is what naturally happens when you have more pixels to work with. They all have a 'coarse' feel as a result.)

OK that makes sense to me. So I would make some test are and see how it looks on my monitor in fullscreen. But what happens if I want the game to support 4k? Does it need to scale up?

Well anyway, 'I like 240x160, I'll target that' is not quite sensible thought process. The feel of the final result is really about size of each 'pixel'; if you like 240x160 you need to think about how large the pixels will need to be on phone, using information about the respective PPIs of the GBA and of the phone screen. There is also stuff relating to different contrast ratios of displays which can heavily effect color quality.

In your position I would be making up some sample images, with different numbers of real pixels per seen 'pixel' -- 1x, 2x, 3x, 4x.. uploading them to the phone, figuring out some way to view them at exactly 100% zoom, and getting a feel for how the different scale factors look on phone. As well as the cosmetic conditions affecting it -- glare and cut-down display technology. Preparing some color gradient and texture samples to compare computer screen vs phone would be smart too, now that I think of it..

Then you would be in a position to make an informed decision about art design for your game.

(OT-ish: yeah, HQ2x, scale2x, 2xsai etc all, from experience, have this 'levels of detail' problem: The art was made at X level of detail and semi-smart guessing about implied shapes will only ever resolve those shapes more clearly, not change the design to give you 2x more detail / expression -- which is what naturally happens when you have more pixels to work with. They all have a 'coarse' feel as a result.)

What I did is create a PC version of the game and tested it at every resolution. The only method is to build in that buffer of sprites with "useless" filler. If you are targeting a wide range of devices, it's the only option for a pixel perfect picture at every resolution.

"The only method is to build in that buffer of sprites with "useless" filler." What do you mean by this?

EDIT: Basically my question is, does the art in a pixel game work like a movie? The movie's resolution does not change but it stretches to the screen size. One pixel becomes several pixels. Since it is pixel art it does not become blurry unless you're screen size to distance is all wrong.

[Ai]

Redsuinit is talking about a situation where, if you scaled the pixel art to fit the screen, the scale factor wouldn't be an integer. For example, supposing you made the art for a 240px 'screen'. Then supposing your phone screen is 640x800. 640 / 240 = 2.66; 800 / 160 = 5.0. This means you would need to a) use the scaling factor 2, and b) occupy (640 - (240*2))  (=160) pixels of space with 'filler' art rather than playfield.

There is a lot of room for adaptation there, especially if you think carefully about your design, but the basic point holds: If you're supporting multiple devices, some of them will be an imperfect fit to the metrics of your art, which means you have to find some way to use what would otherwise be blank space.


re:scaling:
You should *always* scale in-engine if you possibly can; it saves you memory and storage, simplifying any updates to art, and also potentially reduces CPU and GPU usage (less data to transfer).

[RedSuinit]

Redsuinit is talking about a situation where, if you scaled the pixel art to fit the screen, the scale factor wouldn't be an integer. For example, supposing you made the art for a 240px 'screen'. Then supposing your phone screen is 640x800. 640 / 240 = 2.66; 800 / 160 = 5.0. This means you would need to a) use the scaling factor 2, and b) occupy (640 - (240*2))  (=160) pixels of space with 'filler' art rather than playfield.

There is a lot of room for adaptation there, especially if you think carefully about your design, but the basic point holds: If you're supporting multiple devices, some of them will be an imperfect fit to the metrics of your art, which means you have to find some way to use what would otherwise be blank space.


re:scaling:
You should *always* scale in-engine if you possibly can; it saves you memory and storage, simplifying any updates to art, and also potentially reduces CPU and GPU usage (less data to transfer).

I refer back to the first post I made in this thread. It explains it perfectly well. You (Kepler4) would need to create a script that basically said this:

if (current.screen.resolution/design.resolution < 1.5)
pixelart.scale = 1;

else if(current.screen.resolution/design.resolution >= 1.5)
pixelart.scale = 2;

else if(current.screen.resolution/design.resolution >=2.5)
pixelart.scale = 3;

repeat this until you have covered all of your scale sizes for all screen sizes. This is not the actual script you would need, but I don't know what language you code in or what engine you are using. If you want to understand what I mean about the "usless filler" refer back to my first post in this thread, with this bit of psuedocode in mind.