What is the biggest limiting factor in game size?

0 favourites
  • 5 posts
From the Asset Store
220 Food Sprites in 16x16 pixel size. Perfect for items for a retro style game.
  • 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?

    Thanks in advance.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • "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.

  • 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!

  • "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

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