Optimal Resolution for Node.js games

> But now imagine something different: that your sprite is 64x64 but shrank down in c2 layout editor to 16x16 and the game is still 430x270. In high quality scaling and in full screen and in full hd it again becomes 64x64. But now it is not upscaled 16x16 sprite - it is that original 64x64! Now check this: if the pc is not strong enough to output assets in full hd, you switch renderer to low quality scalling, and now this 16x16 is rendered as 16x16 but upscaled to fit the screen.

>

> So what you need to do, is to set your games resolution to half hd i wrote above, make all sprites in the editor half the size, but load original hd assets, and those will render now differently depending on the type of scaling.

>

>

okay got it! sounds good, I will definitely check this out. Awesome.. thanks! So when you mentioned before keep decreasing the asset resolution.. you mean find a point where it looks good without looking too blurry for that low-quality setting?

btw, I can't imagine anyone playing my game windowed, it will always be fullscreen, I'm not giving them the option if I can help it.

Is high quality scaling a run-time modifiable parameter? i.e. could I have a user change this setting while the game is running?

>

> And now going back to your question about optimising the graphics: you do this in photoshop. For example that nebula could be done differently: instead of having interlaced 16-bit or higher png, you can set its saturation and levels in ps, and also replace transparency with black colour, then export as 8-bit png, and in c2 editor set it's blending mode, making black background becoming transparent.

>

>

I've done this (blend mode to additive) on black backgrounded images before, but I had no idea it saved memory... it sounds familiar, but I guess I never really looked into it! How much of a difference does it make? I have a TON of images that have LOTS of transparency. Should I convert them all???

In system events you will find renderer option, which you can switch at runtime. The goal is to have both: good looking high and low quality scaling image, remembering thought that high quality scaling will look better; it's like finding compromise, based on priorities: you can keep high resolution for objects in foreground, and lower quality graphics used for background. You could also build backgrounds and bigger objects, from number of smaller objects. This way you can reuse them creating more variety.

Also remember that laptops hd screens are not that common yet, and usually their resolution is around 1280x720, and the screens are most often 15", so 860x540 in low quality scaling will look decent, but even on 17" it will look fine.

Some people play windowed, because they have other applications running that they need to keep an eye on.

In photoshop just press ctrl+alt+shift+s which will bring up export window, where you can work on optimization. In the bottom-left corner is size of the file, so you can make easy compartment. In that same export window you can work on colours of images, for 8-bit export.

Also remember that laptops hd screens are not that common yet, and usually their resolution is around 1280x720, and the screens are most often 15", so 860x540 in low quality scaling will look decent, but even on 17" it will look fine.

right right! didn't even think of this.. so rendering HD when a laptop's max resolution is 1366/768 is a complete waste!

my only problem now is on some of the advanced UI sections I use screen offsets..ugh..kicking myself! rookie mistake..

> Also remember that laptops hd screens are not that common yet, and usually their resolution is around 1280x720, and the screens are most often 15", so 860x540 in low quality scaling will look decent, but even on 17" it will look fine.

>

>

right right! didn't even think of this.. so rendering HD when a laptop's max resolution is 1366/768 is a complete waste!

my only problem now is on some of the advanced UI sections I use screen offsets..ugh..kicking myself! rookie mistake..

For ui just use Anchor. Also on start of the project testing for resolution and then loading UI graphics trough url from other location so you can have different resolutions of ui. And if you feel like more work, then could do that for whole project. But Ashley confirmation of this being useful from performance perspective ( as from visual side it lets you perfect assets for several types of resolution ).

For ui just use Anchor.

ah okay, that's another behavior I've never used. I'll look into it. thanks!

It will all depend on the how small I can make the resolution and have it still look acceptable. Then finding out if that smaller size makes a performance difference. There are other optimizations that I could probably do..I just want to know about the art now.

— - please file a bug report if there is too much memory use - the point of layout-by-layout loading is to keep the memory use down, so we want to make sure that is working.

I already dug more info on the issue, it's NW and Chromium related. Its a widely reported problem. I did not observe this behavior with IE or Safari.

This is why it sucks to have no explicit control over asset loading and unloading. Chromium does all the GC and its broken. Most people don't notice the issues because their projects are quite small, so the constant memory leak takes awhile to build up. Potentially many hours before its noticeable (stutter then crash).

But games tend to be much bigger than app, lots more assets, bigger games will reach the instability point much sooner, so play session is limited to an hour.

Quite difficult to tell people who buy your PC game, it has to be restarted every hour.

ps. Also, IE and especially Edge is an amazing fast browser nowadays. No vsync issues, butter smooth. NO memory leak issues, very stable. Can we please get a IE/Edge wrapper? :p I am so sick and tired of Chromium and all its constant plaguing issues leading to games that stutter even on powerful hardware, bloated memory use on mobiles and now memory leak on PC.

Rendering a HD game on less-than-HD display doesn't matter much: letterbox scale just downscales everything to fit. The source artwork is higher resolution than it needs to be, but scaling is something GPUs excel at, and the overall fillrate is still lower because there are fewer pixels on the screen to be written to. And having HD source artwork means it looks good on people who do have HD screens as well (some laptops even have 4K screens now!). If the resolution is less than half the design resolution, all your artwork will step down to the next mipmap level, and render from smaller automatically-generated high-quality renders of your source artwork too, helping save memory bandwidth.

— - all wrappers have their bugs. I'll take a look and see if there's anything we can do about it. Edge only runs on Windows 10+, and IE on Windows 8.1 and lower depends on the system version installed, and of course it does not cover Mac or Linux at all. So I think it's better to use a portable wrapper.

If the resolution is less than half the design resolution, all your artwork will step down to the next mipmap level, and render from smaller automatically-generated high-quality renders of your source artwork too, helping save memory bandwidth.

Thanks! good to know..

If in my game I have 4-5 background images that are 800x800 (with lots of transparency) and I make about 10-15 of each to spread around the layout (unbound). These draw calls (when the player is in front of them) are going to be way more taxing than say 50x50 of the same artwork correct? My question is how much? enough to warrant a resolution change?

I know at my current resolution I can probably make my background art smaller than 800x800 (nebulas etc) and upscale it without losing too much. I just want to know if I'm heading down a bad path given NW.js issues described in this thread.

Bottom line.. let's say I'm starting a new game today: hey guys! I'm making unbound layout, top-down space game. I plan to deploy with NW.js... Should I go with 1920x1080 or 240x135 game resolution? or are both doable?

> If the resolution is less than half the design resolution, all your artwork will step down to the next mipmap level, and render from smaller automatically-generated high-quality renders of your source artwork too, helping save memory bandwidth.

>

Thanks! good to know..

If in my game I have 4-5 background images that are 800x800 (with lots of transparency) and I make about 10-15 of each to spread around the layout (unbound). These draw calls (when the player is in front of them) are going to be way more taxing than say 50x50 of the same artwork correct? My question is how much? enough to warrant a resolution change?

I know at my current resolution I can probably make my background art smaller than 800x800 (nebulas etc) and upscale it without losing too much. I just want to know if I'm heading down a bad path given NW.js issues described in this thread.

Bottom line.. let's say I'm starting a new game today: hey guys! I'm making unbound layout, top-down space game. I plan to deploy with NW.js... Should I go with 1920x1080 or 240x135 game resolution? or are both doable?

Now I don't exactly understand either. Ashley : so basically, If I have 1080, with assets for that res, when played in 720, it performs as 720?

or, which is more along what mightbe true, a project in 860x540 with hd assets in hd upscaled with high quality scaling to hd will perform better then full hd with all of the same projects o not? Cause I'm confused now.

Anyway with optimized assets the performance increase is visible with naked eye.

megatronx not sure I understand.. but if I make a 800x800 nebula image, remove alpha channel and scale it down to 100x100 in PhotoShop, then in C2 resize it in the Layout View to 800x800 will that make any difference in memory usage/draw calls? or is that just making a giant fuzzy image at the same processing expense?

megatronx not sure I understand.. but if I make a 800x800 nebula image, remove alpha channel and scale it down to 100x100 in PhotoShop, then in C2 resize it in the Layout View to 800x800 will that make any difference in memory usage/draw calls? or is that just making a giant fuzzy image at the same processing expense?

The smaller the image size ( not dimensions ) the faster it loads in to memory, and is created faster. I'd really go with 860x540 because of older machines, to keep that fps high. But your question is a good question,, because it would mean that there is created some sort of phantom of original sprite just bigger, and so using more memory. Good question, and I'd like to know that.

megatronx not sure I understand.. but if I make a 800x800 nebula image, remove alpha channel and scale it down to 100x100 in PhotoShop, then in C2 resize it in the Layout View to 800x800 will that make any difference in memory usage/draw calls? or is that just making a giant fuzzy image at the same processing expense?

If you make an image smaller in Photoshop, you are basically removing information from the image. When you bring that small image back into C2 and scale it up, it will become blurry because those pixels are no longer there. It has to fill in data and average everything out, resulting in a blurry image.

If you want to rescale, it would be best to find some sort of happy medium. Those ship renders we made were slightly larger than needed to give a bit of head room for adjustment in C2. The render size can be adjusted before you render, and you can always shrink it down afterwards in Photoshop as well.

The main thing is that you don't end up with anything blurry on at least the majority of devices. Perhaps you can make a backup of the project and do some tests or experiments and see what is possible without ruining your main game.

Now, when it comes to draw calls or processing expense, I'm afraid this is not my area of expertise. Smaller images will use less memory, but I don't know what else. I didn't get to test my game on anything else and was just hoping it would run on other systems. I didn't get that far.

> megatronx not sure I understand.. but if I make a 800x800 nebula image, remove alpha channel and scale it down to 100x100 in PhotoShop, then in C2 resize it in the Layout View to 800x800 will that make any difference in memory usage/draw calls? or is that just making a giant fuzzy image at the same processing expense?

>

If you make an image smaller in Photoshop, you are basically removing information from the image. When you bring that small image back into C2 and scale it up, it will become blurry because those pixels are no longer there. It has to fill in data and average everything out, resulting in a blurry image.

If you want to rescale, it would be best to find some sort of happy medium. Those ship renders we made were slightly larger than needed to give a bit of head room for adjustment in C2. The render size can be adjusted before you render, and you can always shrink it down afterwards in Photoshop as well.

The main thing is that you don't end up with anything blurry on at least the majority of devices. Perhaps you can make a backup of the project and do some tests or experiments and see what is possible without ruining your main game.

Now, when it comes to draw calls or processing expense, I'm afraid this is not my area of expertise. Smaller images will use less memory, but I don't know what else. I didn't get to test my game on anything else and was just hoping it would run on other systems. I didn't get that far.

Well,that's what I've been talking about mate. Just look up the tread. The doubts came after Ashleys post, as I just couldn't understand his rhetoric.

The main thing is that you don't end up with anything blurry on at least the majority of devices. Perhaps you can make a backup of the project and do some tests or experiments and see what is possible without ruining your main game.

right, I'm just wondering if that gives you any benefit at all to upscale an image opposed to already having a large image in C2.. maybe not. And yes you'd have to make sure that no sprites were actually blurry at the highest resolution - that goes without saying.

yeah I'm going to have to run some tests.. but I have no time for that right now.. way too many other things on my plate! but I will post it here when I find the answers...

When Ashley said:

If the resolution is less than half the design resolution, all your artwork will step down to the next mipmap level, and render from smaller automatically-generated high-quality renders of your source artwork too, helping save memory bandwidth.

I assume this is part of the answer I am looking for... except I don't really understand it. Does memory bandwidth relate to draw calls? will this improve the lag-like effect I get when my player goes in front of one of these large background images on a laptop with an integrated HD4000 gpu? because what I am seeing on those laptops is not jank, I'm well versed at identifying jank. It's a graphics thing, I can see it drawing the screen and lagging behind.

> The main thing is that you don't end up with anything blurry on at least the majority of devices. Perhaps you can make a backup of the project and do some tests or experiments and see what is possible without ruining your main game.

>

right, I'm just wondering if that gives you any benefit at all to upscale an image opposed to already having a large image in C2.. maybe not. And yes you'd have to make sure that no sprites were actually blurry at the highest resolution - that goes without saying.

yeah I'm going to have to run some tests.. but I have no time for that right now.. way too many other things on my plate! but I will post it here when I find the answers...

When Ashley said:

> If the resolution is less than half the design resolution, all your artwork will step down to the next mipmap level, and render from smaller automatically-generated high-quality renders of your source artwork too, helping save memory bandwidth.

>

I assume this is part of the answer I am looking for... except I don't really understand it. Does memory bandwidth relate to draw calls? will this improve the lag-like effect I get when my player goes in front of one of these large background images on a laptop with an integrated HD4000 gpu? because what I am seeing on those laptops is not jank, I'm well versed at identifying jank. It's a graphics thing, I can see it drawing the screen and lagging behind.

It's as simple as this: smaller image ( by that i mean I mean Smaller in dimensions and file size in kb ) loads faster and is being removed faster from memory, then big image. And I think it is easier to draw several smaller images then one big one, as construct draws objects that are on screen, even if only single pixel of the big image is on screen, the whole image is being drawn anyway.

On the side note, I've noticed long time ago that scrolling does impact performance at times more than it should. But again it might be due to image sizes.

There are two sides to the GPU performance:

1) reading from the source textures. Larger images involve more data to read so can be slower.

2) writing pixels to the screen. A higher resolution involves writing more pixels. The rate the GPU can write pixels at is called the fillrate.

Usually from what I've seen the bottleneck is 2). As in, the size of your source artwork doesn't matter that much, it's mostly about how much content is drawn. If you have a large source image and render it to a small, low-resolution display, you don't use much fillrate, because there weren't so many pixels written to, even if the source image is large. On the other hand, even a small source image drawn at a large size on a high-resolution display will use a lot of fillrate, since it has to fill a lot of pixels. So generally I focus on the fillrate side of performance.

Look up mipmaps on wikipedia to learn more about them, but they also help make 1) less of a performance issue. The GPU stores images at 1/2 size, 1/4 size, 1/8 size etc. down to a single pixel with high-quality resizing. If you render a large source image at half the size, it will render from the 1/2 size source image that it automatically generated, which means there's even less concern about the size of the source image. The main reason to reduce the size of your source images is basically to reduce the overall memory usage.

If you have any performance questions involving specific cases, it's best to measure them yourself.