Ashley's Recent Forum Activity

  • The video export is an offline encode option, which is a key difference to Video Recorder, which does a real-time encode. If the system can't keep up with Video Recorder, the game performance suffers and that can affect the content recorded. However with video export, the engine renders a frame, encodes it to video, and then advances the time by one frame, and continues. So the performance has no effect on the video content: it will always export perfectly smooth motion regardless of how fast or slow encoding is. And if you have a powerful system, depending on the export parameters, offline encoding can run much faster than real-time.

  • You should already be able to fully customise the Platform behavior to do whatever you want by using the set vector X/Y actions.

    You can try making your own platform movement with events as a learning project. However the Platform behavior's main movement logic is over 1000 lines of some of the toughest JavaScript code I've written in my career. The whole point of Construct is to take these really complicated things and make them easy to use. As with many things in software, some things that seem simple are actually very complicated.

  • Construct is estimating that your project will use over 3GB of memory. That is exceptionally high. Many devices will not have enough memory for that. You should try to keep the memory usage well under 1GB.

  • The Animated SVG example demonstrates it's possible with the HTML Element object. Unfortunately for technical reasons it's very difficult to integrate further in to the engine.

  • Even if we supported that, you still have the question of what happens for the 5-10% of people who don't get WebGL 2. What should be rendered instead? Or should it fail?

    I think some of that can be done in WebGL 1 anyway. Perhaps we could enable the OES_standard_derivatives extension, which should let you do it in WebGL 1 code with better compatibility - I reckon most WebGL 1 devices probably support that extension too, although actual support numbers are hard to come by, especially since webglstats shut down.

  • I had a look at the project. I can't reproduce any significant performance difference between r295 and r297. In both cases the CPU is around 50-60% and it runs about equally smoothly. The GPU utilisation increased slightly in r297, probably due to a rendering change to improve how transparency is handled, but it didn't appear to affect the smoothness much.

    The events are pretty inefficient. In particular a great deal of CPU time goes on two actions that adjust the Z order of a couple of hundred "Billboard_Grass" objects with the "Move in front" action, which is done apparently redundantly every frame. The engine doesn't handle this efficiently at the moment, but it's a poor solution for Z ordering anyway - use layers, Z elevation, or if necessary, only run those actions when something actually changes, rather than all the time. If I delete those two events I don't actually see any obvious visual change and the CPU usage drops a lot.

    It also creates around 1000 objects which seems a lot for a relatively simple style of game like this - perhaps you're creating hundreds of unnecessary objects and running intensive events on them all?

    It's also difficult to test this reliably, as it seems to be based on randomised and procedurally generated content, which makes doing a fair comparison between two releases difficult. What if one time it generates a lot more content? It could be slower because of the content, not because you switched release. You have to be scientific about performance and make sure you're running exactly the same thing in each case and only vary one thing. It seems possible that there is no significant performance change in Construct and the content differences gave you a misleading impression of a performance change. From an engine point of view it is also much, much easier to investigate performance differences with a minimal project (as per our bug report guidelines).

    I'm afraid I don't have time to dig any deeper, but in short I can't see any evidence of a major performance difference between r295 and 297 here, and the most serious problems look like inefficient events or game design, which are up to you to change! As ever it's important to keep an eye on the performance numbers and watch out for any changes that cause a big change to the numbers, which is an indication you made a change that hit performance, so you would probably want to find a better way to do that. And if you want to track down something that might be slow, split events up in to smaller groups to get better numbers from the performance profiler, and try deleting chunks of events to see if performance improves when to remove specific events.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's hard to say because as far as we are aware, the WebM Opus files Construct generates are supported on every platform and are working for everyone else. It's also possible it's just a mistake, like the event logic to play sound is not correct, or the user has their sound turned off, etc.

    If something doesn't work in general you should file an issue following all the guidelines, as we need all that information to be able to help - without it it's usually impossible to figure out what might be going on.

  • In terms of the core features, WebGL 1 works virtually identically to WebGL 2, basically doesn't need any maintenance, and dropping it would mean the 5-10% of people who still only get WebGL 1 will get either a blank screen, or drop to software rendering which will ruin performance. So dropping WebGL 1 would be a tiny amount of upside to a huge amount of downside. I think it's the kind of thing you can only consider when usage drops to <1%. That will probably still take years.

  • The forum is still missing lots of features like limiting voting, sorting the suggestion lists various ways, managing the status and official responses, and so on. I spent quite a while looking for a suitable service and that was the only one that did most of what we needed when I last looked, but that was a few years ago, so perhaps some other service has turned up?

  • That's weird, I can't see anything about the r296 release that would have seriously affected performance. Send your project to ashleyphe@scirra.com and I'll do some profiling and see if anything comes up.

  • Yeah, discussing ideas collaboratively in the forum to refine them and make sure they are robustly justified is definitely a good idea before submitting a suggestion, and I'd encourage that.

  • We do regularly look at the suggestions platform. The main problem is the community submits far, far more ideas than we could possibly implement. It's just totally impossible to imagine that we could do even a significant fraction of the submitted ideas. Unfortunately this is sometimes interpreted as "Scirra ignores suggestions", and adding yet more ideas to the list makes the problem worse. I don't really know what we can do about that - I've tried hard to explain clearly how it's used and what to expect in the suggestion guidelines, including emphasising that it's best to focus on a small number of realistic suggestions, rather than a large number of all-encompassing ideas. I'm reluctant to shut it down though, as it is a source of genuinely good ideas.

    As noted in the guidelines the original plan was to completely reset it every 6 months to keep it manageable, fresh and relevant. However I think 6 months is too short. I'm leaning towards annually resetting it, which is around about now. Unfortunately two more problems are that I wanted to keep old suggestions archived, but they just get completely clogged up with really awful spam, which forced me to remove public access from the old platform, which limits people's ability to refer back to old suggestions. Secondly I'm also wondering if it would be better to do the reset in say January and align it to calendar years.

    Anyway, managing the impossibly huge mountain of ideas everyone comes up with is quite a difficult problem. I should emphasise many of the ideas are great and I'd do many of them if it were possible. Unfortunately we are bounded by the laws of physics. I'm still not certain how to manage it. Posting forum threads like this don't mean we have any extra time, so won't really change anything, other than perhaps collecting a few more votes for the ideas you advocate for, but remember everyone has limited votes - as a measure to try to avoid everyone voting for an impossible volume of work.

Ashley's avatar

Ashley

Online Now
Early Adopter

Member since 21 May, 2007
Last online 15 Oct, 2026

Twitter
Ashley has 1,826,616 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs