High-DPI display on layer-by-layer basis?

0 favourites
  • 8 posts
From the Asset Store
It has been developed from level 1 to level 5. (4K Hand Painting Assets) 3200x4200 size.
  • Hi. I've found that the most major performance hike for KlangM can be tracked down to the high-DPI display option. However I feel very conflicted turning it off, since it makes the main character look really, really blurry. 99 % of the other assets looks fine though. I do find it very regretable that I can't toggle this feature on and off during runtime, and that I can't chose which layers or objects to exclusively apply it to?

    Is it possible in any way to implement this in the future? If I could apply the high-DPI only to a certain family or layer I would get the best of both worlds, making me much more comfortable moving forward on mobile. This would also allow for saving resources on background assets that really doesn't need the sharpness in order to serve its purpose.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I think really you want a "quality" option per-layer so you can render at a (custom) smaller size and stretch up to fill the display, similar to how low-quality fullscreen scaling works.

    I'm afraid we will not be adding any significant new features to C2 from now on, and this kind of improvement is something we'd only consider for the new C3 runtime.

    Also for what it's worth, this is one of those surprisingly tricky optimisation areas: using a lower-quality for a layer will cause it to use its own texture, which in some cases can use more fill rate than if you didn't lower the quality at all. The overhead of the own-texture copy has to be exceeded by the amount of GPU time saved by the lower quality rendering. This is not a simple equation and in some cases will just make things worse.

  • Ashley Yes that sounds about right. That still doesn't change the fact that I find the framerate being overall way more stable and hardlocked at 60 FPS when the high-dpi is off. When on it's extremely inconsistent. Sometimes it's rock solid 60, other times it hits a snag that drags it permanently down to the 45 range, other times there's small noticable jags etc. This is very frustrating when I don't know exactly what's causing it. If I could track it down to an individual part of my game I could optimize/work around it.

    For instance my current theory is that my new approach to avoiding download size is the culprit. I've based the art style on relying on batching lots of single colors tiles over the screen. It looks clean, scales well, takes no download size, but a ton of draw calls. While the batching seems to handle this really well, I worry that the high-res algorithm wasn't optimized for this, and ends up slowing it down when enabled? Thing is I can't properly verify this theory, and deleting all the assets doesn't isolate the problem enough. There could be other factors affected when I delete all the assets.

    I find myself losing a lot of valuable dev time on just worrying over performance. You mentioned something about chrome having a more advanced profiling tool. Any info on how to use it?


  • If the game performance is affected by the rendering resolution, your game is definitely GPU-bound. That means draw calls, events, and anything else CPU-side won't help. You need fewer force-own-texture layers, less overdraw, fewer shader effects, etc. GPU performance is tricky since there aren't good inspection tools at the moment, Chrome's dev tools won't help you with that. Maybe you could use low-quality fullscreen mode? Reverse-engineering a slow game to a fast one is really difficult, this is why all our advice says test on mobile from the start.

  • Ashley Yes I already use low-quality on mobile. I also work on mobile as the primary target platform. I'm simply trying the waters with how far I can push the engine to get the most cost efficient visual fidelity out of it. I don't use force own layer textures. To clarify, I wasn't implying that the draw calls themselves causes the slowdown, but rather that the rendering struggles when it has to sharpen so many individual objects?

  • I'm not really clear on what you are doing. Do you mean you're using a sharpen shader effect on lots of individual instances? As the performance tips manual entry states, that can be slow and it can be more efficient to process it on the whole layer instead.

  • Ashley By sharpening I mean the added clarity and crispness by enabling High-DPI/High quality fullscreen mode. It has to force a lot more calculations in order to make the most out of each object right? Am I misunderstanding how it works? I know better than to use expensive effects for this by now.

    To explain a bit further. Let's say I have 30 objects being rendered, does the High-DPI/High Quality fullscreen individually look at all these 30 objects, calculate the best way to present the given asset, then draw each one individually? Or is it much simpler, where there's no extra calculations applied, but simply makes more of the pixels available in the canvas?

    I made some more tests today. The scene was at 900 objects, but I got it down to about 250 without much visual changes or fill rate. One of the changes I did was to remove about 150 instances of an object, and replaced it with a one-shot particle with infinite timeout. Only one object, but looks roughly the same. It runs a lot smoother on mobile now. Reducing the object count seems to have worked. I'm just trying to figure out why it works. Only thing that currently makes sense to me is that the amount of objects drawn is more important than how many pixels drawn?

  • If you're GPU bound, you can forget about the whole CPU side, like issuing draw calls. If high quality fullscreen mode is slow, it's most likely simply because it has to render a larger area, i.e. it's entirely limited by fill rate. This is exclusively to do with the memory bandwidth of the GPU hardware. The exact way the GPU renders those sprites isn't really important, it basically comes down to "how many pixels are drawn?" and if that's a bigger number, it is slower.

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