What's Construct 3 Performance Limitations?

0 favourites
  • 9 posts
From the Asset Store
Casino? money? who knows? but the target is the same!
  • Hello as someone who has very big idea's I've found construct 3 to be quite limiting in the context of loading times, I have noticed that pixel density plays a big part in construct 3 performance issues but

    I could be incorrect and was wondering what are the actual performance limitations of construct 3 so

    I can design my idea around that?

    Is construct 3 basically limited similarly to like the snes and or ps1 and if so what is the best pixel density for images, frequency density for music,etc and how much can we throw at construct 3 before it hurls to a halt or annoyingly long loading times for each preview,etc

    I don't mind working within limitations if I have too and scraping what I have too to make my idea's work, I just need to know what my limitation boundary is so I don't waste my time....?

    Annoying loading times would be 1-5 minutes per preview just for one change that is ridiculous in this day an age.

  • Usually the performance limits are the hardware, not the Construct engine. For example if a game only slows down on a high pixel density display, that's probably because it uses more memory bandwidth on the GPU, which is a hardware limit. The limiting factor with that is your game design, not the Construct engine.

  • You are quite right potentially after some reading around on construct performance tips and advice for construct 2,3 and elsewhere.

    I've noticed that the best performance comes from trying to keep everything into one spritesheet as possible and keeping everything into one tilemap as much as possible to create interesting environments,etc

    The loading time is superb if that is done correctly.

    In the end the hardware targets are the bottleneck not the spritesheet size as such it's still best to keep in mind the lower res it is the more faster it will potentially be because of less pixel to load perhaps anyways.

    So basically you can create whatever you want within those hardware limitations 2048x2048 for mobile or desktop sprite sheet size though I'm not entirely sure how big one sprite sheet can be before it delays the load however just aslong as you can work with minimal amount of spritesheets and tilemaps at a fair spritesheet size it will be possible.

    I think that's the end game so far Id say construct 3 might be better then an snes or gba in terms of performance capabilities with this technique used properly and correctly we might be talking later (2000) pc power here.

  • Construct 3 actually creates the sprite sheets for you automatically. So there's no reason for you to attempt to organize your images into sprite sheets manually.

    In my experiences the performance of the actual Construct 3 runtime is generally very good for it being written in javascript and running in a browser. But keep in mind it won't out perform a runtime written nativly for the device. Since everything is web tech, if you want to export your game for desktops or mobile devices, we are forced to rely on wrappers like Cordova and NWjs. Those wrappers are great to get our games out to a wider audience but they have a lot of overhead and also run the entire game/app in a webview.

  • I would be keen to see actual benchmarks comparing Construct 3 with a native engine. I think Construct's engine will actually be highly competitive, and it's also possible it actually exceeds a less efficiently written native engine.

    Further, with WebGPU support it's entirely possible Construct can leapfrog native engines that are stuck with OpenGL.

  • You speak like that's going to happen soon!

    Excited for that Ashley

  • So it depends greatly on how the engine is written. Yes, a poorly written, unoptimized engine written in C can run slower than an optimized one written in javascript. So I guess the best way to say it, for example, an engine written in C for desktop has the potential to be magnitudes faster than a browser one in javascript.

    In C, memory is managed by the programmer, and can be used quite cleverly to minimize cache misses (if the programmer really knows what they're doing). There's no way to do that in javascript as far as I know.

    Also, because Javascript is interpreted, it cannot benefit from the optimizations that a C compiler can do. I realize there are "javascript compilers" like Google's Closure Compiler, but those don't produce highly optimized machine code, they just output optimized javascript. Which they appear to me be more concerned with download size rather than runtime speed.

  • Modern JavaScript is JIT compiled directly to machine code, not interpreted. That's been the case for years. These days JS engines are so highly optimised it's generally pretty competitive with native code.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Intriguing , I did not know that ashley and thank you for those explanations all of you, as someone who's spent years trying to program a game engine with no finished product on hand due to my own difficulties with technology currently, I can certainly agree with those facts as of the contemporary era.

    I'd be also blown away by a extremely potent benchmark.

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