Ashley's Forum Posts

  • 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.

  • 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 ashleyscd@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.

  • Try a relative URL like "second/index.html".

  • It might be better to use an iframe for this, but you should not need to use a full URL - a relative URL should work fine. Also don't use the file:// scheme at all, modern Cordova exports use custom URL schemes (e.g. app:// on iOS) which make things like this work much more easily.

  • What about r296? It's very helpful to identify the specific release where a change happened, as it significantly narrows down the list of potential code changes that affected it.

  • Construct already culls anything not in the viewport. But culling itself can have a significant performance overhead if you have tens of thousands of objects.

  • - Can you please add Alpha Channel to the PNG sequence export?

    It's already supported. Make sure all layers are transparent.

  • My point is nobody appears to have noticed a change in the rate of development in the work already done. You can't now turn around and say that's a problem when nobody ever said anything at the time. In fact we've had really positive feedback on the last few C3 releases.

    Throughout the life of Construct, people often describe features as mandatory and try to frame the product as unusable without it. We know many people are passionate about what they want to see in Construct. But not everyone needs everything. Even simple and limited products have success on the market. It's even the case that C3 has long lists of major features that other products lack - and yet those other products still have large userbases. Remember that if you personally really need something, it does not necessarily mean the majority of other people using the product will also need the same. There's space on the market for a variety of different tools with different capabilities.

    I think it's also worth bearing in mind that if you list 10 years worth of feature requests (which pretty much happened with the old feature request platform), it's not reasonable to expect quick action on that. Making quality software takes time. It's best to focus on a small number of things that are the highest priority, and then move on to the next highest priority things after those are done. Some feature requests are also literally never-ending. Things like "Make commercial-quality games in Construct" is both arguably already possible for certain types of games, and if expanded further probably amounts to "Make Construct as capable as Unity". That will be an ever-present request that can keep being repeated right up until Construct exceeds the capabilities of Unity, which as much as it's a nice dream will probably never happen. We all have to be realistic, and feature requests need to be framed in an achievable way otherwise there's no point even considering them.

    As ever feature requests are a balancing act of trying to use limited resources to best effect. In the case of Construct Animate I think there is a chance we could see a much more significant return on investment than with any other work we could have done in that time. It is a bit of an experiment too, but I think there is very little chance it will either ruin the company or significantly impact C3 in any way. I'm still keen to hear actionable feedback on Construct Animate, so if you have any more, let us know!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Again, I would encourage you to watch everyday users try using your custom input controls. I expect it will be enlightening.