Optimal Resolution for Node.js games

Discussion and feedback on Construct 2

Post » Tue Nov 10, 2015 8:50 pm

jobel wrote:@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.
B
72
S
29
G
35
Posts: 340
Reputation: 22,721

Post » Tue Nov 10, 2015 9:32 pm

DrewMelton wrote:
jobel wrote:@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.
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
85
S
27
G
20
Posts: 1,961
Reputation: 18,649

Post » Wed Nov 11, 2015 12:09 am

DrewMelton wrote: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:
Ashley wrote: 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.
B
88
S
29
G
14
Posts: 1,154
Reputation: 15,003

Post » Wed Nov 11, 2015 2:47 am

jobel wrote:
DrewMelton wrote: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:
Ashley wrote: 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.
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
85
S
27
G
20
Posts: 1,961
Reputation: 18,649

Post » Wed Nov 11, 2015 12:39 pm

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.
Scirra Founder
B
387
S
230
G
87
Posts: 24,245
Reputation: 192,210

Post » Thu Nov 12, 2015 6:24 pm

Ashley wrote: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.


thanks ashley, that helps me understand better... so basically: stay away from large images as much as you can. And my challenge is to fill up my game's background smartly as possible. I read some of your other blog posts where you reference Rayman Legends' art etc... I guess I thought I was already being conservative...good to know.
B
88
S
29
G
14
Posts: 1,154
Reputation: 15,003

Post » Thu Nov 12, 2015 6:40 pm

@Ashley so if fillrate is the ultimate decider.. then do you get any benefit from using the same object over and over? (besides memory)

i.e. a single 800x800 blue square vs. 10 duplicates of a single 80x80 square (snapped together to make it look like one big sqaure)

I ran a test although I can't tell if it's the same performance or if I'm not looking at the correct info..
B
88
S
29
G
14
Posts: 1,154
Reputation: 15,003

Post » Fri Nov 13, 2015 12:02 pm

Fillrate isn't affected by what you're drawing: 10 of the same or 10 different objects drawn at the same size use the same fillrate. Using the same object over and over helps save the overall memory use, which is a separate concern to fillrate.
Scirra Founder
B
387
S
230
G
87
Posts: 24,245
Reputation: 192,210

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 2 guests