General slowdown with larger project?

This forum is currently in read-only mode.
0 favourites
From the Asset Store
Enlist the menacing fleet commander of the galactic star force in your next game audio production.
  • So if you add a new, empty layout with no events, running it unlimited is slower than a blank cap? That's odd. I think a while back Davo was investigating a bug where overall performance was dependent the number of different object types in the project. I guess he didn't solve it.

    I guess I should take a look back at Classic to solve this - it seems to have held up the biggest and best projects in Classic. If you send me your .cap (obviously I won't share it) I'll run it through a profiler and see what's going on. We're doing the big C2 launch on Monday so I can't guarantee I'll be able to fix this soon though.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I just checked it with my current project - yep, empty layout runs at almost same speed as playable layout (slower than empty cap)

  • Thanks so much for taking a look at it, Ashley!

    Also, at least for me it doesn't matter if it's fixed immediately since my game has a few more months of dev time. Obviously the C2 launch comes first in importance!

    I'm trying to contact Kayin, so you could have an extra .cap to look at.

    This does affect my .cap as well, so I'll send mine if you need it, but since my .cap isn't affected nearly as much (about 850 from about 1150), I'm not sure if it will be as much help. Not to mention it's stupidly huge, and I would prefer you don't have waste your time waiting for parts it to open and such.

    I also tried making a .cap with every default plugin type in it but it didn't seem to affect performance. Thought it might be useful to know.

  • I was having a quick look and almost immediately found something that may have been the problem - if anyone else wants to try, have a play with these runtimes:

    http://dl.dropbox.com/u/15217362/fasteruntimes.zip

  • Erm...I cant run any of them.

    "Error loading 'APPBLOCK' (1813)" is the error I get on all three apps.

    Huh? :(

  • You have to drop them in to your r1.2 <install directory>\Data and hit Preview inside Construct to use them.

  • Thanks Ash for looking at it.

  • Works for me, I'm not sure if its just an illusion but I get a little higher in unlimited with my game now.

  • by any chance are you running these tests with construct OPEN?, having a bigger project open in construct always seems to use more system resources for me, and then when i run the exe it generally works slower than if i would run it as a standalone without construct open. your project is increasing in size, #of layouts, textures, event sheets etc. so construct (the editor) itself may be the culprit of the slowdown, i remember having this problem with MEGA THUMB on my laptop, i'd have multiple tabs and stuff open and it was making the computer itself a lot slower. also, a drop from 1000, to 500, to 200, doesn't take THAT much in my experience.

  • My old project that I bitched and bitched and bitch and bitched about? Went from 900fps to 2000. The other, developed project I'm working on is all the way up from 120 to 250. SO BASICALLY MORE THAN DOUBLE.

    I love you guys.

    Out of curiosity, what caused this issue? Due to the suffering I've gone through, I'm invested in the answer.

  • Woot!! Jump from about 800-850 to 1000! Not all the way back up to 1150, but quite a significant improvement! Thanks, Ashley!

    Quazi - tried that, a good thought but it made no difference. Also, while a drop in fps might not take much, the point of this bug is that it's not supposed to hit the fps when there's nothing in the layout at all and no code is running.

    Edit: Hey, awesome, Kayin! Glad it works for you too!

  • Hmm, I might have been lucky before or have bad luck now, but I don't have any changes. 400 before, 400 now, 200 before, 200 now. But maybe they are much too small a project to get an advantage (no rpg, no adventure, you know).

  • Tanks again, Ashley!

    I just want to say I got a MASSIVE spike in FPS when I ran an empty layout and disabled my Xbox controller plugin being global, I'm now running my test level that used to be 250 fps at 700, so this coupled with your new runtimes has given me a whole lot of leeway.

    I just have to ask a difficult question: do you think you (or someone else kind-hearted) will be able to improve this further? It still doesn't reach the 11,000 fps of an empty layout in a new game, even if I hunt down everything global and remove it. An empty layout in my game now reaches 2600 (originally it was only 500, so a massive improvement).

    I just want to be able to decide if I should continue this game or not. <img src="smileys/smiley19.gif" border="0" align="middle" />

  • The problem was there was a function in the runtime - "GetObjectTypeByName" - that loops every single object type and finds the one with the given name, case insensitive. For behavior management, this was called once every tick. This meant if your project was huge (hundreds if not thousands of different object types), it was doing a fair amount of work per tick. I came up with a faster way that doesn't need to loop every single object type, so now it barely does anything every tick.

    Now for various reasons I think

    • it won't reach the 11,000fps of an empty layout in a new game, and
    • it doesn't matter.

    In the runtime there's a certain amount of work that must be done every tick, and some of these jobs invariably take slightly longer for large projects. However, the difference is (now) incredibly tiny. Remember: 11,000 fps means one tick lasts about 91 microseconds. That's obscenely fast. If that drops by half to 5,500 fps, each tick is now taking about 182 microseconds (less than a fifth of a millisecond).

    At the super-high framerates you get with Classic, tiny insignificant amounts of CPU work are vastly over-represented. For real games a change of 91 microseconds per tick has no effect. None. However when Classic is essentially doing nothing per tick, such a tiny change seems to be trashing your framerate. It doesn't matter though.

    So I think the big one has been fixed - but there shouldn't be any other significant performance issues. If in doubt calculate your delta-times instead of framerates, and you should see you're doing just fine.

  • So what I'm hoping, and you might be suggesting, is I won't see much of a drop in framerates as I go along now? It will get lower as the game gets bigger, but it exponentially decreases how much FPS it loses? Don't think "exponential" is the right word for shrinking...

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