# What is the biggest limiting factor in game size?

Get help using Construct 2

### » Sat Aug 29, 2015 12:46 am

The size of an image determines how much room it takes up in C2, if we use very small images and "zoom in" by adjusting the layer scale, is it possible to create an extremely large map/world with all of the objects already created at the start? Especially if you're using very few different and very small sprites? Or is there an amount of sprites that causes lag/dropped frame rates?

If I worded that terribly I'm basically saying. If we limit ourselves to 750MB, then there's only so many 1000 x 1000 images we can import before we hit that limit. Same with 100x100 images, but we can have more. If we're just using say 5 different sprites. What's limiting us from making 0.0001 x 0.0001 sprites and zooming in by adjusting the layer scale to see those sprites?

B
9
S
2
Posts: 37
Reputation: 729

### » Sat Aug 29, 2015 6:02 pm

Up to a fairly great amount, it does not matter. It is about what you do with them.

I noticed the greatest performance hits with large amounts of objects, is when you loop through them continuously and check/do things with each.
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,597

### » Sat Aug 29, 2015 7:49 pm

"What's limiting us from making 0.0001 x 0.0001 sprites and zooming in by adjusting the layer scale to see those sprites?"

Basically: the actual on screen rendering size and texture size will be the limit.

A texture cannot be smaller than 1x1 pixel (as... it is the minimum quantity of information you can have for an image., less than that would just be non-sense as the number of pixels a texture has is an integer), also, by having a 0.0001x0.0001 sprite object (not the actual texture) zoomed in 100 000 times or 0.1x0.1 zoomed in 100 times will give the same result as the rendered area will be the same and the texture size will also be the same in both case.

If you wanted however to say reducing the texture size, well, it can be worth it in many cases, but be sure that it still looks good, as a 1x1 texture zoomed in will look blurry or pixelated (depending on the sampling), a gradient texture can be scaled down with the linear sampling yet still looking good for exemple, as the blur won't damage it much.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

### » Sun Aug 30, 2015 7:17 am

lennaert wrote:Up to a fairly great amount, it does not matter. It is about what you do with them.

I noticed the greatest performance hits with large amounts of objects, is when you loop through them continuously and check/do things with each.

Thank you, I'll keep that in mind for the future!
B
9
S
2
Posts: 37
Reputation: 729

### » Sun Aug 30, 2015 7:18 am

Aphrodite wrote:"What's limiting us from making 0.0001 x 0.0001 sprites and zooming in by adjusting the layer scale to see those sprites?"

Basically: the actual on screen rendering size and texture size will be the limit.

A texture cannot be smaller than 1x1 pixel (as... it is the minimum quantity of information you can have for an image., less than that would just be non-sense as the number of pixels a texture has is an integer), also, by having a 0.0001x0.0001 sprite object (not the actual texture) zoomed in 100 000 times or 0.1x0.1 zoomed in 100 times will give the same result as the rendered area will be the same and the texture size will also be the same in both case.

If you wanted however to say reducing the texture size, well, it can be worth it in many cases, but be sure that it still looks good, as a 1x1 texture zoomed in will look blurry or pixelated (depending on the sampling), a gradient texture can be scaled down with the linear sampling yet still looking good for exemple, as the blur won't damage it much.

Ok I think I understand, thanks so much
B
9
S
2
Posts: 37
Reputation: 729