Pixelation
General => General Discussion => Topic started by: Kepler4 on August 30, 2015, 10:58:46 pm
-
I'm new to pixel art and game design. I'm confused about how pixel art "scales" in a game played at 1080p to the same game played at 4k (or vice versa). Since pixel art is not like a 3D game texture which may have various resolution settings, and pixel art itself is bound to its own resolution, how does this work? Is it set to one resolution and the total picture just gets bigger or smaller depending on the screen resolution?
Am I thinking about this completely in the wrong way? ???
-
It's not particularly complex. If the resolution you're targeting is smaller than the resolution you are running at, a game can do one or both of:
a) Upscale the graphics by an integer factor (with no interpolation)
b) Expand the playing field to expose a larger area
Just doing a) is better from a game design perspective, IMO (but not always possible), since the amount you see onscreen does not change. The PC port of Pixel Dungeon is a good example of a game that does a) (on my system, the scaling factor appears to be 3)
Taking your specific example, 1080p is too high a resolution for a pixel art based game, so it's a reasonable presumption that the 1080p display was already upscaling the art by a factor of three (meaning that the resolution targeted was actually 640x320, a reasonable albeit somewhat high resolution for pixel art). Switching to a 4k resolution, a game might increase that scaling factor accordingly (to 6), or if that is considered too coarse, expand the playing field instead. It might also choose to do both (for example, use a scaling factor of 4+ a playing field that has been expanded to 150% of its original size (640 * 4 = 2560; 3840 / 2560 = 1.5).
Does that answer your question?
-
I'm new to pixel art and game design. I'm confused about how pixel art "scales" in a game played at 1080p to the same game played at 4k (or vice versa). Since pixel art is not like a 3D game texture which may have various resolution settings, and pixel art itself is bound to its own resolution, how does this work? Is it set to one resolution and the total picture just gets bigger or smaller depending on the screen resolution?
Am I thinking about this completely in the wrong way? ???
Basically what will happen is the game will be scaled by x amount based on the original design resolution. The actual mechanic that accomplishes this task will vary based on the design platform. Achieving pixel perfect resolution while maintaining the EXACT same scene within the frame is impossible unless you are locked into a single resolution, and your design resolution is an exact integer of your target resolution (i.e. target of 1920 x 1080, therefore a design resolution of 320 x 180). There has to be some kind of buffer around the border of your scene to accommodate either the increase in width, height, or both depending on the factor on which you are limiting your game.
Example:
Original design resolution: 256 x 144
Playing resolution: 1920 x 1080
Pixel Scale Factor: 1080/144 = 7.5 >> Round to 7 or 8
(The numbers used in the factor equation will be based on whether or not you want the height or width to remain constant, just in case your game needs to cover multiple screen layouts i.e. 16:9, 16:10, 4:3 etc.)
Therefore, at 1920 x 1080, the pixels will be distorted UNLESS you adjust what shows up in the window in order to hit a perfect round number, which in this case will be 7 or 8. So if you round up to 8 the amount of space you will LOSE is going to be 144 - 1080/8 = 144 - 135 = 9. So 9 pixels worth of information from the original frame will be lost. 4.5 pixels from the top, and 4.5 pixels from the bottom. (half pixel losses are possible in this case because when upscaled the actual pixels lost is 9 x 8 = 72, so 36 from the top and 36 from the bottom)
Therefore, that buffer must be built into the game. 4.5 pixels of information both top and bottom need to be practically useless. Black bars are a cop out in my opinion though. Just don't put any vital information in those 4.5 pixels top and bottom.
Another Example:
Original Design Resolution: 256 x 144
Display Resolution: 1366 x 768
Pixel Scale Factor = 768/144 = 5.33 >> 5
Rounding up in this case would be 144 - 768/5 = 144 - 153.6 = - 9.6 pixels; 4.8 top and 4.8 bottom (upscaled 24 top and 24 bottom). So you need to add 4.6 pixels worth of information beyond the original design resolution.
The point is that if you want pixel perfect graphics in a pixelated game, and you aren't going to force a specific resolution, this scaling factor must be built in to adjust the actual pixel size based on the screens current displayed resolution. This is a major factor in the design of a mobile game using pixel art.
IMPORTANT NOTE: Going SMALLER than your original design resolution is impossible for pixel art. It can't be done without distortion or loss of detail. Someone please correct me if I am wrong.
-
Nothing's bound by resolution just because it's 2D. Anything can be drawn bigger.
There's a bit distortion when, like, a 16x16 sprite is drawn to something like 19x19... and like.. some of the pixels will be doubled and some not. But scaling up to 1080 resolution isn't much of a problem there because those fine details are tiny.
-
Nothing's bound by resolution just because it's 2D. Anything can be drawn bigger.
There's a bit distortion when, like, a 16x16 sprite is drawn to something like 19x19... and like.. some of the pixels will be doubled and some not. But scaling up to 1080 resolution isn't much of a problem there because those fine details are tiny.
Having that distortion would completely defeat the purpose of doing pixel art for a game. In those instances just use vector graphics. For pixel art games resolution is EVERYTHING.
-
Not true RedSuinit. On 1080p resolution, the distortion is slightly iffy still, but way less noticeable than it used to be. If it's made for TV's I would go as far as to call it borderline acceptable. With 4k, that distortion is invisible and doesn't matter at all. The example given where you scale up by a factor 8, you can get away with it easily. Some pixels being 7/8 as wide as other pixels, you're probably not going to notice that at all.
So, instead of saying that games resolution is EVERYTHING, I'd say it's sometimes something to keep in mind. The best pixel art games have a scaling solution that works intelligently, going from cropping the playfield, to expanding it on certain resolutions and once they hit a certain PPI, just scaling it distorted.
-
Not true RedSuinit. On 1080p resolution, the distortion is slightly iffy still, but way less noticeable than it used to be. If it's made for TV's I would go as far as to call it borderline acceptable. With 4k, that distortion is invisible and doesn't matter at all. The example given where you scale up by a factor 8, you can get away with it easily. Some pixels being 7/8 as wide as other pixels, you're probably not going to notice that at all.
So, instead of saying that games resolution is EVERYTHING, I'd say it's sometimes something to keep in mind. The best pixel art games have a scaling solution that works intelligently, going from cropping the playfield, to expanding it on certain resolutions and once they hit a certain PPI, just scaling it distorted.
Depends on the size of the screen. At 1080P even upscaled with a factor of 8, on my 70" TV, I would see the distortion. For 4k, then you're right, it would be practically invisible. But that also depends on the design resolution. To just say carte blanch that once you get to XPPI the distortion doesn't matter is still incorrect. But it's semantics at this point. In most situation you're right, most people wouldn't notice.
-
An important factor is whether a single graphic (sprite) is smoothly moving :
Rendered without interpolation, if the magnification factor is not constant, it will be noticeable that the sprite is "crossing uneven terrain". As the viewer's eye follow the movement of the entire shape, he will notice that straight lines, single pixels and dither patterns shrink and grow rapidly as they oscillate between different sizes.
For non-moving shapes, there is the specific issue of the perceived lightness : Ex draw a white rectangle on a black background, with 1-pixel-wide lines. If this is rendered at a factor between 3 and 4, the lines rendered as 3 pixels wide will appear less luminous than the lines rendered as 4 pixels.
-
An important factor is whether a single graphic (sprite) is smoothly moving :
Rendered without interpolation, if the magnification factor is not constant, it will be noticeable that the sprite is "crossing uneven terrain". As the viewer's eye follow the movement of the entire shape, he will notice that straight lines, single pixels and dither patterns shrink and grow rapidly as they oscillate between different sizes.
For non-moving shapes, there is the specific issue of the perceived lightness : Ex draw a white rectangle on a black background, with 1-pixel-wide lines. If this is rendered at a factor between 3 and 4, the lines rendered as 3 pixels wide will appear less luminous than the lines rendered as 4 pixels.
Good point. I still believe that if you have to accommodate multiple screen resolutions, the best solution is to just build in the necessary buffer, even if you're doing a large up/downscale.
-
I'm not convinced you can notice it at 7 or 8 times scale. Maybe we should do the test? Here's a classic Pawige piece in 750%. Does anyone notice that not all pixels are equally big? I can't spot it.
(http://i.imgur.com/OFgKw6Q.gif)
-
I'm not convinced you can notice it at 7 or 8 times scale. Maybe we should do the test? Here's a classic Pawige piece in 750%. Does anyone notice that not all pixels are equally big? I can't spot it.
(http://i.imgur.com/OFgKw6Q.gif)
I notice it on some of the stand out pixels, such as the iron sight. But overall, you're right it is difficult to notice.
-
Here's an illustration of the problem I referred with moving sprites, here with a 450% zoom :
(http://oi62.tinypic.com/a0fpxg.jpg)
The non-zoomed version, as a comparison (use forum zoom to try various integer factors).
(http://oi60.tinypic.com/axmmow.jpg)
-
Here's an illustration of the problem I referred with moving sprites, here with a 450% zoom :
(http://oi62.tinypic.com/a0fpxg.jpg)
The non-zoomed version, as a comparison (use forum zoom to try various integer factors).
(http://oi60.tinypic.com/axmmow.jpg)
I just don't see the advantage of NOT building in the functionality for pixel art based games. It's not that difficult, and it can be very skillfully done. Getting that pixel perfect look on every resolution is 100% worth it in my opinion.
-
Of course it's not going to work at 450%, that was my whole point. I said it will only start working at around 7 to 8 times scale, probably more.
And yes, I personally wouldn't stretch/squash pixels, but then again, I said I was never going to rotate pixels and I'm doing just that for my latest game prototype.
-
I didn't mean to contradict you :) I provided illustration of a slightly different issue - at 450% because it's easier to notice the effect, at 750% it also becomes hard to notice.
-
Of course it's not going to work at 450%, that was my whole point. I said it will only start working at around 7 to 8 times scale, probably more.
And yes, I personally wouldn't stretch/squash pixels, but then again, I said I was never going to rotate pixels and I'm doing just that for my latest game prototype.
I also thought the same, but I too am rotating my characters arms and bow, because for me to model in that many angles would take far more time than I have.
-
I didn't mean to contradict you :) I provided illustration of a slightly different issue - at 450% because it's easier to notice the effect, at 750% it also becomes hard to notice.
Ah yeah, gotcha. You do have a point that perfectly linear motion is the bane of stuff like this.
-
I get it now. Thanks guys, I was really overthinking it.
The game is made in a low res to create the art style then those original pixels become "pixel shapes" created by several pixels on a higher res monitor. For some reason I'm not sure what I was thinking before but I'm glad I understand now.
I'm assuming if I use something like Paper2D this stuff will already be built into the engine, correct?
-
I'm assuming if I use something like Paper2D this stuff will already be built into the engine, correct?
Most engines these days DON'T have it built in, but there's usually quite a few ways to handle it. The texture filtering you want is nearest neighbor (doesn't blur pixels).
-
I'm assuming if I use something like Paper2D this stuff will already be built into the engine, correct?
Most engines these days DON'T have it built in, but there's usually quite a few ways to handle it. The texture filtering you want is nearest neighbor (doesn't blur pixels).
Well I guess I'll have to inquire about that when I get to it.
Does OS resolution scaling matter much? I'm looking into a new monitor with good color accuracy and I want to make sure I don't choose something with a very high DPI if that is going to mess with my work.
-
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.
-
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?
-
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.
-
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.
-
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.)
-
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.
-
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.
-
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.
-
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 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.