Large sprites, tiled backgrounds, and performance

0 favourites
From the Asset Store
This is a pack with 7 space backgrounds wich have variations.
  • What I would be interested in knowing, is the performance cost of a sprite/tiledbackground that is doing absolutely nothing (aesthetic) versus an active sprite that is doing something?

    I much prefer the concept of using a modular approach however if overhead (notorious in editors like C2) is added with each sprite, it makes me worry.

  • What I would be interested in knowing, is the performance cost of a sprite/tiledbackground that is doing absolutely nothing (aesthetic) versus an active sprite that is doing something?

    It depends on what it is doing. But if you mean controlling with events, that means it's running on the CPU. Most games are bottlenecked by rendering, so chances are those events finish before rendering anyway, meaning there's no impact to the framerate.

  • I'll just jump in here with a quick question.

    Earlier i noticed that when inserting large sprites (directly from folder to the editor), no warning or anything appears.

    But if i double click a sprite (animation editor etc), and import a new sprite there, a warning appears if the image is too large, and slicing them is advised. Does it really help to slice it up? As mentioned in this thread, slicing up a huge image does not help performance wise.

  • the maximum size is 2048x2048 pixels, up to this, think in slicing it.

  • The problem with doing 'modular parts' or using heaps of sprites to make areas is that it can push up the objectcount to thousands, and I think the objectcount impacts the performance quite a bit from my experience. So I think I'm going to do my levels with unique sprites with a size of 1000x1000 (and invisible solid objects for collisions).

  • Wonder if this is something Scirra can incorporate or get some ideas from.

    Not sure if something like this could help.

  • Ashley (hope he can weigh in on this issue)

    Alspal, that is what I've been doing. Basically, I draw my entire level map in Photoshop which is very large, about 1000 by 10000 pixels, set my Construct window size to about 640x480 which results about 15 screenfuls in the game, then I split my single huge photoshop map into 10 png files of 1000 pixels by 1000 pixels so something like this:

    level_p1.png 1000x1000

    level_p2.png 1000x1000


    These png files are imported as tiled backgrounds. My reasoning for this is that even though I'm not taking advantage of the tiling functionality, I recall reading somewhere that tiled background objects have less "built-in maintenance/logic" as opposed to full sprite objects.

    Then using Scirra Construct 2 View Grid I lock the grid size, then drag each image p1 - p10 into the game view adjacent to each other. After this, I use generically alpha transparent shape sprite objects(squares, 45 degree triangles, etc) which have collision behavior on a separate layer in the appropriate places where the terrain should be solid. These collision objects are visual in-editor, but visibility is turned off in-game.

    Of course, anything in the game, such as enemies, player, etc are separate sprite objects. This approach seems to work, but I want to know if it is a good idea in terms of performance/optimization.

    I need a professional definitive expert opinion about this approach with respect to Construct 2. Is it a good idea? Why or why not? Will I run into scalability issues depending on the platform and or scope of the game? I think many people using Construct 2 would like an answer about this.

  • I really strongly recommend you do not take this approach to designing levels. Using very large images is the quickest way to fill a mobile device's limited memory and make it unplayable.

  • is right, it's not just on-screen objects that are in memory. The entire project is in memory, even off-screen images, and even images on different layouts.Why don't you load the images on diffrent layouts when the layout containing tose images is loaded?

    It seems like a waste of memory to me, but what do I know.

  • He's said he might do memory per layout later on.

    Ashley, but if we're not doing it for mobiles its fine then?

  • It's a bad habit to get in to, because if you do come to design a mobile game the way you're used to will probably not fit in to the device's memory. Also, some old desktop machines have about as much memory as a high-end mobile device, so this method is still possibly excluding some desktop machines.

    It also hugely increases the download size, because a series of very large image could run in to the megabytes, whereas levels made out of a series of smaller objects will probably just be a few hundred K.

    Construct 2 will eventually support loading layout by layout like Classic does, but it's a low priority because it's generally not necessary for projects designed properly (using levels composed of smaller images).

    Obviously C2 is just a tool and you can do what you like with it, but I strongly encourage you to compose levels out of smaller objects. It's faster, smaller to download, and uses vastly less memory, and won't make your game unplayable on low-end desktops or mobile devices.

  • Hey all

    I have been working on my optimisations today and implemented a lot of the methods mentioned.

    One thing I tried and now just found to be very BAD was over using tiled backgrounds. I thought that I could use a nice small tile and grow it over a large area. Big mistake! It killed the performance. I think I am getting a good idea of how html5 handles images and memory.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ashley,

    First of all, thank you for all that you do. You have enabled a small team of teachers to go from one developer and four designers to four developer/designers with Construct 2. We are very much looking forward to using it in the classroom.

    We are looking at rebuilding a 50 MB iPad app from the ground up in Construct 2 because of the portability of HTML5 versus Objective C. I am working through the first question layout (of approximately 40). I am not worried about download size, as I intend to PhoneGap the final product, but I am worried about overloading my phone's memory (a Samsung Galaxy S2 with a persistent memory leak). Objective C agressively handles memory so having 50 MB worth of resources isn't an issue. My first layout currently uses 1.5 MB of memory. If I extrapolate that out, the final product should require about 60 MB. Is it foolish to think that I will be able to load the app with all 40 question layouts built?

    Thanks for the help!


  • You resurrected an antique thread.

    By now we have layout-by-layout loading in C2.

  • That's great news, and thanks for the heads up!

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