How do I render non-blurry Pixels on Mobile?

0 favourites
From the Asset Store
Vintage steam pixels for your UI! 125 unique assets in a single pack!
  • Hello people,

    my game looks pixel perfect on the desktop webbrowser, but on my smartphone (Galaxy S6) the graphics look blurred, even though I have these settings applied to the view:

    Fullscreen scaling: Low quality

    Use high-DPI display: No

    Enable WebGL: On

    Sampling: Point

    Downscaling: Low quality

    On PC:

    On Mobile:

    Am I missing something essential?

  • Are you by any chance forgetting pixel rounding?

  • Hey SirPumpAction,

    I have yet to build any games for mobile devices, so I'm not sure all of the potential causes, but one possibility comes to mind.

    "Crop" mode

    It may be that the "Full screen in browser" mode is rendering to an intermediate texture and then scaling it to fit the mobile's screen.

    To work around this you could try setting "Full screen in browser" to "Crop".

    The "Crop" mode means that your game will not be auto-rescaled regardless of the monitor dimensions.

    You'll then have exact control over how the game is scaled up to fit a monitor, but as a side effect you'll have to be a little careful with how you place hud elements, as object positions that work on a 16:9 aspect ratio display, might get cut off on a 4:3 aspect display.

    You may also need to zoom the layout with events, by detecting the monitor dimensions and scaling up by the best integer fit.

    Even if you don't plan to ultimately use Crop mode, you might want to at least try it to see if that suppresses the blurry bilinear filter effect you're seeing in the second image.

    Importantly, if your game displays at a 1-to-1 pixel scale (looks super tiny and zoomed out) when running in Crop mode, then you may want to temporarily add in an "On start of layout" >> "Set layout scale" to 3 or 4, so you can see if the pixels are coming out sharp when scaled up.

    Pixel Rounding

    One other option you might want to enable is "Pixel Rounding", though that isn't likely to fix the blur unless your entire title screen has pixel coordinates that are exactly half way in between integer pixel coords, (e.g. 0.5 by 0.5).

    That said, "Pixel Rounding" will ensure that all game objects will be rendered as if their origin points are snapped to integer pixel coords, though the internal game logic will still treat them as floating point coords.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Thanks for the quick replies! Pixel rounding is on, but on the menu screen I was already working with exact pixel values, so even if pixel rounding were to be off, it shouldn't have looked blurred.

    I just tried crop mode, but it doesn't look as if it fits my game at all, so I have to revert back to letterbox/integer letterbox. Any more ideas?

  • Try turning pixel rounding off, maybe. Worth a shot, fixed blurring for me, at least on desktop.

  • Hi, maybe your export settings: try to disable image compression.

  • Same without pixel rounding and the exported graphics look fine on desktop. I also created new projects and all face the same issue with pixel graphics.

  • Hey again,

    I suspected that Crop wouldn't fit the game correctly by default, which is why I mentioned the "start of layout" event that might be needed to see the pixels close up, but that said, did Crop mode fix the blurry pixel problem?

    The reason I'm curious is because Crop mode is (as far as I know) C2's most open-ended full screen display mode, and with some effort (and events) you can pretty much make it behave like any of the other modes, but with more control.

    The main thing that Crop mode will give you is that the game will not be rendered to an intermediate texture and then stretched to fit the target display. I'm not sure, but I suspect that might be the cause of the blur you're encountering.

    The Galaxy s6 has a res of

    2560 x 1440

    The image of the title screen you posted is

    1280 x 720

    And that title screen is a 2x scale-up of the pixel art, meaning its un-scaled res is

    640 x 360

    Out of curiosity, could your list you PC's monitor resolution?

    And most importantly, what is the game's "Window Size" property set to? If it's 640 x 360 that might help shed some light on the issue.

    Anyway, given the above, that means the pixel art is being scaled up exactly 4x to fit the Galaxy's screen, (from 640 x 360 to 2560 x 1440). Also is the image you posted from the Galaxy's screen scaled back down 2x, because it's not the full 2560 x 1440 res. No problem if it is, just curious.

    It looks to me like the 4x scaling being done on the Galaxy is using bilinear filtering. If I take your sharp title screen into Photoshop, scale it down (via Nearest Neighbor) to its 1x scale and then scale that up by 4x (via bilinear) to simulate the Galaxy's scaling, my re-scaled version is virtually identical to your blurry comparison image. (Note: I also scale my version back down by 2x to match the 1280 x 720 res of you're 2nd comparison image.)

  • All your assumptions are correct. Window size is 640x360, the title screen is 640x360, galaxy screep is 1440p, my desktop screen is 1080p, the title screen is x2 scaled just to show how sharp it looks and the galaxy s6 should scale every pixel by 4 as my desktop is scaling up every pixel by 3 (3x640, 3x360 = 1920, 1080 ; 4x640,4x360=2440,1440), so I would expect the same sharp image on my S6 as on my Desktop, but clearly something behaves differently and it looks terrible on my S6. (And yes, the S6's screenshot was scaled down by x2 because it still looks as blurry on 1440p as on 720p ) I have no problem with the game rendering to an intermediate texture and then scaling to the final resolution, this is what I was actually hoping for as it increases the performance, ESPECIALLY on mobile with it's limited rendering power, when you take into account how GLSL works on each and every pixel. When it works on the 640x360 it has significantly less work to do then on the proper 1440p resolution. Now my problem seems to be related to the fact that I would like to have a point interpolation scaling here and not a linear interpolation on the final image, but this doesn't seem to happen on the smartphone, while it works perfectly fine on the desktop :/

  • That's a good point. On a mobile device it would be ideal to render once at the pixel art resolution and then just scale up to full screen.

    When running the game on the Galaxy, are you running the game as an installed android app, or are you running it from within a browser like Chrome or Firefox?

    You might want to try running from a few different browsers on the Galaxy to see if there's a difference in the scaling behavior. It's possible that the bilinear blurring is a side effect of the environment the game is running in and not you're project settings, especially given that the games scales correctly on your desktop computer.

    It may be that, the method C2 uses to tell the target environment to use "point" interpolation scaling, doesn't work for all environments.

    Finally you said in your first post that "Fullscreen scaling" was set to Low quality, which would seem to make sense, given that you don't want any filtering, but you could try high quality, to see if that makes a difference on the Desktop and Galaxy versions.

    This one is a long shot, but mobile graphics hardware does some weird things in response to settings you would think would be consistent across platforms.

    I've vaguely recall seeing a very (very) few situations where a graphics property on low settings will defer to the discretion of the target hardware on how to handle things, while a high setting will force the hardware to do things a certain way. Mind you, I've never seen or heard of that kind of thing in C2, but mobile graphics hardware is weird that way. It seems to me like it was a floating point precision thing, so likely not related.

    For an interesting example of said weirdness, here's an article on floating point calculations that does a good job of showing the inconsistent internal computational spookiness of mobile GPUs. Note: I don't think the effect described in the article below is specifically related to your problem. I was just trying to remember some of the articles I'd come across that showcases some of the same kind of esoteric mobile GPU characteristics that can result in unexpected behavior.

    http://www.youi.tv/mobile-gpu-floating- ... variances/

    (Scroll down to see various devices render the same exact shader script in uniquely distorted and variably buggy ways.)

  • Thank you for your detailed responses fisholith, I will try this out and hopefully come back with a good outcome

    Just one question, how does construct 2 actually realize the scaling? Is the final canvas object in the DOM scaled to fullscreen or is the canvas always fullscreen and just the intermediary calculated texture upscaled inside webgl?

  • I think I found the problem. Apparently setting Use high-DPI display to yes solves the problem I have yet to see if this comes with any performance impact...

  • Interesting.

    So, from what I gather, "Use high-DPI display" forces the browser to ignore the "device-pixel-ratio" specified by the mobile device.

    For instance, the Galaxy s6 normally scales everything up by 4x (device-pixel-ratio of the s6) to make webpages readable, but with "Use high-DPI display" enabled, it will instead render everything at 1x scale, or more importantly, 1-to-1 pixel density with the display's native resolution.

    That kind of makes sense, as you were seeing the full screen view of your game rendered at exactly 1/4th the display resolution, and then scaled up by 4x (device-pixel-ratio of the s6) to fit the screen. By coincidence your game at 1x scale happened to also be exactly 1/4th the display's resolution, which perfectly hid what was going on. <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

    The device-pixel-ratio is a fixed scaling factor determined by the device manufacturer, but is different for different devices. This scaling factor came about as a way to scale websites to a reliably readable size across different devices and display resolutions.

    The description for the "Use high-DPI display" property is as follows,

    "Use high resolution display where available. If disabled, renders in low-res and upscales."

    So when enabled it renders directly at native resolution.

    Back towards the end of 2013 Construct 2 "r148" was released, and the high-DPI option became a project default. In the release notes Ashley explained the following:

    [quote:1jf7k7iy]"This build broadens support for any device with a high-DPI display, including modern Android phones and tablets, Tizen and Blackberry 10 devices, and Amazon tablets. Graphics can render at considerably better quality with high-DPI support, and especially text which can appear much crisper and more readable.

    Since high-DPI displays have many more pixels, using this mode can reduce performance since there is more rendering work for the GPU. So we've kept it as an option, but renamed from "Use iOS retina display" to "Use high-DPI display". It's on by default and we highly recommend using it whenever possible, but in some cases you may need to turn it off for performance to be acceptable."

    https://www.scirra.com/construct2/releases/r148)

    As he points out, it's theoretically possible to see a performance gain from turning it off, but it's essentially required for correct rendering on devices that use a scaling factor (device-pixel-ratio), and it's also worth noting that the performance effect was negligible enough back in 2013 to make it enabled by default. So in 2016 you should be pretty safe leaving it enabled, especially since it fixes the blur problem.

    [ edit ]

    Here's an interesting article on "device-pixel-ratio":

    http://juiceboxinteractive.com/ideas/a- ... e-devices/

  • Wow thank you for the thorough analysis! The other nice effect of enabling high dpi was that now finally the return values of touch.x are actually correct and I do not need to do some calculations where I had to divide by the actual rendering height vs the original rendering height etc. So if anyone is struggling with any of these issues -> enable high dpi

  • No worries. And thanks for sharing your findings, SirPumpAction. Very helpful to know.

    ... also I love your avatar.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)