Fuzzy. Ram optimization and object count.

0 favourites
  • 9 posts
From the Asset Store
This is a single chapter from the "Construct Starter Kit Collection". It is the Student Workbook for its Workshop.
  • I read the article on general performance optimization, as well as the blog on RAM usage. I'm a little confused.

    The best way to save RAM is to use small objects that get reused, or tiled. It has also been said that using lots of objects is bad for performance. If you're using small objects, you're going to need a lot more of them to fill out a level.

    So which is worse? Huge tiles, or tons of small ones?

    I'm not confidently clear on how to really, truly optimize a game. Is it really just a balance between RAM and processing? Are there any general guidelines or methods that take both RAM and processor usage into account, equally?

    Also, why does a tiled object count as 1 object, but particle effects count as hundreds of objects?

    Edit: I assume all instances count as individual objects?

    I could really use some more clarity, overall.

  • There is a difference between an image of a Sprite and the Instance of Sprite. Your lumping the sprite as individual images even if they are the same image. That`s not the case.

    * A sprite is world object that renders an image based on world position. The sprite usually only consists of a few values such as XY, frame.....

    * An image is a memory allocation that holds the colours that creates the visual looks.

    A sprite is location where the image is to be drawn to on the canvas. That way you can have many sprite information XYs, but not use up more memory. The sprite is not the image.

    ImageMountain, size 200kb

    Sprite1, x0,y0, image=ImageMountain.(size is 100bytes)

    Sprite2, x0,y100, image=ImageMountain.(size is 100bytes)

    Sprite3, x0,y200, image=ImageMountain.(size is 100bytes)

    Sprite4, x0,y300, image=ImageMountain.(size is 100bytes)

    Sprite5, x0,y400, image=ImageMountain.(size is 100bytes)

    this is just rudimentary principle. There is only one singular image for each sprite. That image is the largest chunk of ram. Each sprite even though there are 5 of them all use a tiny fraction.

    When the computer is then told to draw the sprites. The computer will draw the same image for the same sprite.

    Sprite is not the image... sprite is the location and condition to draw the image :)

    (note: the term sprite seems to shift depending on the tools being used)

  • Huge tiles are bad, and lots of objects on-screen are bad as well. So if you have lots of objects spread out over a long level, without too many being on-screen at once, you should be fine.

  • Thank you both! I'm feeling MUCH more confident now.

    Jayderyu:

    That's a great distinction. Thanks for the extra details, too. It's quite helpful.

    Ashley:

    That really cleared up my biggest concern. Also, I just reread the performance tips page, and noticed the "on screen" distinction is in there. I just missed it the first time. So, thanks for being generous, and posting it here as well.

    Now I'm off to figure out how to use the "objectcount" expression in a text field. /salute

  • Actually, I've experienced really bad performance with lots of off-screen objects in the game.

    I've had to rework my spawning system to generate objects around the player to keep perf at an acceptable level.

    We're talking about a 28fps difference to get the same visual density of objects on screen.

  • I ask here, to not create another topic.

    Does Large number of events affects on performance on mobile devices?I mean like 500-700? They are "work" not at the same time, they are on different event sheets. And I mean case when I export as native app, not html5 ?

    I have to know it to optimize my code as it even possible and at in time

  • Kurz: Performance tips (with the only things that really matters in term of optimisation/performances)

    Optimisation don't waste your time more advices/informations about what/when/how to optimize with C2.

    Also as recommended in the best practices test on several target devices as often as possible to make sure everything works as intended.

    Finally, the number of events won't really matter, don't just do stuff like creating billions of objects every tick or huge to infinite loops, those kind of events will pulverize your CPU (possibly on desktop as on mobile).

  • Kyatric

    Thanks, I already read all this posts. I don't agree with some things from "Don't waste your time" and I try to make my games without behaviours (to example - if I need move platform from side to side I don't plug in Sine, because it automatically include lots lines of code which I don't need)

    But I hope you right in your lasts two strings.

  • Try Construct 3

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

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

    (to example - if I need move platform from side to side I don't plug in Sine, because it automatically include lots lines of code which I don't need)

    This has been on my mind a lot lately regarding behaviours actually, especially platform behaviour.

    The platform behaviour has a lot of neat features including changing the angle of gravity; I can imagine that requires use of trigonometry math, which could be bad for phone exports if you have a few platform behaviours present, each figuring out their own angles (for enemies and such).

    Even if the user has the angle of gravity set to downwards, does it still USE the trigonometry code?

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