Construct's processor/memory efficiency

This forum is currently in read-only mode.
From the Asset Store
Memory game, with 10 levels for you to have fun. Made in Construct3, template available for purchase.
  • I'm curious about Construct's efficiency. How much time is devoted to checking events? Are there certain kinds of events that are faster than others? Are "Else"s better than just checking for the alternative condition? For larger projects, would it be very bad practice to have multiple events that have the same trigger (for organization or group purposes)?

    Do additional instances of objects cause more processor load, or just more memory load?

    In other words, where should I be directing efficiency methods towards, with an eye towards keeping things fast even when the game gets larger?

  • You should read that the CPU and GPU work at the same time so if the screen takes longer to render than the events take to process, the events have no impact on performance.

    As for making events run faster, generally just favour readability and whatever's easiest to maintain - you only need to optimise it once your game is running too slow. Before then, you cannot know if anything you are doing is making the slightest bit of difference.

    As for your other questions:

    • Some events are faster than others, but generally the difference is negligable - notable places people waste CPU time is nested 'For Each' loops, which with two nested levels with 1000 objects each, runs a million iterations every tick, etc. A single for each is usually fine though.
    • Instead of having a lot of separate triggers it's faster - and more readable IMO - to have a series of subevents under one trigger. Subevents can be used similarly in other places to make events only checked when another event is true as opposed to all the time.
    • Additional instances of objects cause more CPU load, because most conditions test all instances of an object. "Mouse is over X" has to iterate all instances of X for example, so the more X exist, the more processing there is to do. This generally only becomes noticable over an entire event sheet of events. You probably don't need to worry about memory load because rendering or CPU time will become a bottleneck sooner.

    In summary concentrate on making your game render quickly. 90% of the time the game is waiting for the screen to finish drawing rather than waiting for the events to finish processing before a tick is complete. Avoid intensive shader usage, and stick to PS 0.0 effects and plain old alpha-channeled sprites wherever possible. They're fast.

  • This kinda goes along with his question but would save on file size if I has a script that loaded masks for levels instead of laying them out in the layout editor?

  • This kinda goes along with his question but would save on file size if I has a script that loaded masks for levels instead of laying them out in the layout editor?

    Loading your masks from disk at runtime will make your .cap file smaller, but those mask files will have to be distributed with the .exe instead, so it wouldn't really make a difference size-wise.

  • > This kinda goes along with his question but would save on file size if I has a script that loaded masks for levels instead of laying them out in the layout editor?

    >

    Loading your masks from disk at runtime will make your .cap file smaller, but those mask files will have to be distributed with the .exe instead, so it wouldn't really make a difference size-wise.

    Unless the .txt file used to load in the masks (an INI file, right aeal?) is smaller than placing 1 of the same object around a layout...?

  • The difference between using the layout editor and a level editor is going to total a few kilobytes in a game which is probably several megabytes. The question is not about the filesize of each - it's about development time, allowing the user to design their own levels, etc. - those are much much more important than whether your file size is 1% smaller.

  • I'm not entirely sure what you mean, but if you're talking about storing a "map" in an ini file instead of placing the objects in the layout editor, then it still wouldn't make much difference to the file size since multiple objects of the same type share the same memory.

  • I'm saying there's no point talking about whether loading levels from files or using the layout editor creates smaller files. As you say, the difference is negligable, so the more important things to worry about is if you want to spend the extra time writing a level editor, and so on.

  • Oh no, that was in response to ansmesnobody's post, I probably should have quoted it

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • So how about creating the map with a level editor and saving as one large png to bring into Construct. (As compared to having half a dozen small png tiles and building the level in Construct.) Is there any difference in Render time?

  • So how about creating the map with a level editor and saving as one large png to bring into Construct. (As compared to having half a dozen small png tiles and building the level in Construct.) Is there any difference in Render time?

    Large images take up more VRAM, so I imagine that using separate tiles would render faster.

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