Speed problems with construct

This forum is currently in read-only mode.
From the Asset Store
Casino? money? who knows? but the target is the same!
  • Initially they aren't apparent, but as you continue working on a larger game with construct, there are some major speed issues. I realize a lot of these probably can't be resolved in construct one, maybe for construct two they can be fixed.

    Opening large event sheets - one of my event sheets has about 3500 events, and it takes about 2 minutes to open the first time it's opened. It's faster subsequent times when I switch back to the layout editor then go back to the events, but regardless still takes a while.

    Solution idea: even if the initial loading can't be sped up, after the event sheet is loaded, switching back and forth via the tabs from one event sheet to another is instant. Perhaps if the event sheet was kept "open" in its own window the same way other layouts are kept open in other windows, then it would remain plenty fast to switch between a layout and its events.

    Previewing games with large event sheets - my game takes over a minute to preview. Before I realized how much extra time event sheets can add to compile time, it was taking almost two. That was after the graphics had already been cashed. After deleting all of the code from my game and previewing again, the progress bar appeared and disappeared in less than a second. Events, when there are enough of them, take a long time to compile.

    I wonder if there is some way to speed up this process, such as cashing event sheets similarly to the way graphics get cashed, except individually, as most of the time that I preview I've only edited one event sheet. I'm not sure how much that would help on large event sheets since AFAIK the event sheet includes simply results in construct pasting the events from one event sheet to another, though.

    Maybe if there was some way to be able to cache event sheets so after being compiled once, they can be pasted as a single chunk rather then pasting each and every event, condition and action? Then larger event sheets could be broken up into multiple smaller event sheets, making the whole process faster, since only one of the included event sheets would need to be recompiled. I don't know if there's any other way to optimize the process of compiling events to speed it up, but it sure would help!

    Initial preview - since AFAIK in construct 2, games are going to be saved in a way that includes multiple files in one archive, would it be possible to include an option to save the cashed event sheets and graphics as well? It would take up more space, but hard drives are getting so huge these days the amount of time saved would be worth it.

    Working with large images - whether it's in the picture editor or how long they take to cache for preview, large images slow down construct a lot.

    Undoing on large event sheets - I tried pressing undo on that event sheet with 3500 events. 5 minutes later it was still sitting there undoing. Because of this, I don't use undo any more.

    Deleting objects - the biggest speed problem facing construct. I'm not kidding when tell you that when I tried selecting some objects then deleting them, my computer sat working on that for almost 1/2 hour. Because of this, I don't delete objects anymore in the IDE.

    Edit: forgot to mention one.

    Working in the event sheet - when there are lots of events, edits can take about 2-3 seconds for the screen to update itself with the edit. I recall hearing that the event sheet editor was going to be rewritten in C2 to use hardware acceleration, though, so hopefully that will be fixed.

    Can these be fixed for construct 2?

  • Care to post system specs? My game has over 1000 events but previewing and stuff is almost instant. I think the number of objects in a layout and resolution of sprites matters most in terms of IDE performance.

  • Care to post system specs? My game has over 1000 events but previewing and stuff is almost instant. I think the number of objects in a layout and resolution of sprites matters most in terms of IDE performance.

    I guess there might be a big difference. Arima said 3500 events in one event sheet. You may have over 1000 splitted to several event sheets?

  • AMD athlon 64x2 4400+, 2GB ram, 9800GT. What are your system specs?

    Total events in the game is over 7000, not exactly sure how many, and construct recompiles all of them each time. The 3500 are in one event sheet, not including includes, which put it over 4500. As I mentioned, if I delete all of the code then preview it previews in less than a second. It's definitely the events affecting the preview time.

    The resolution of sprites might affect the layout editor, but it doesn't affect the event sheet editor. I don't work in the layout editor much, so I'm not sure what causes speed decreases there.

  • I guess there might be a big difference. Arima said 3500 events in one event sheet. You may have over 1000 splitted to several event sheets?

    no, it's all one event sheet, and preview time is around 2 seconds.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thanks for the report, I didn't know about several of those slowdowns... you must have the biggest .cap anyone's ever created!

    Unfortunately as you point out, it's likely many of the deficiencies will have to wait until Construct 2...

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