Ashley's Forum Posts

  • 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 ashleyhiy@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!

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

  • Thanks all for the feedback - it's interesting to hear all this, especially ideas about how to make a better animation product, and we're reading it all carefully and making lots of notes.

    I can't respond to all the feedback right here and right now - there's a huge scope to the questions asked and we haven't made final decisions on much at all yet. Part of the purpose of the public beta is to hear everyone's thoughts and use them to adapt our approach, which is what is happening and why we made this thread. There's a few things I'd still point out though.

    First of all Construct Animate is a new product primarily aimed at new customers more interested in animation than game development. Regular C3 users may be wondering why they'd use it, but the point is we're hoping to attract more people who have never used Construct before. Perhaps some of those new Construct Animate users will be interested in moving across to C3 for game creation too, so there could be a side-benefit of boosting C3's audience as well. We're also not aiming at pro users - we know we're not about to steal users from After Effects. We're aiming at the end of the market with simpler use cases. For example we've met several teachers using C3 for lessons who were keen on the idea of using it for animation too. A good analogy for this is the fact lots of pros use Unity for game development does not mean nobody is using C3 for game development - Construct is its own thing with a unique combination of features that appeals to a particular crowd.

    Secondly we recognise some C3 users will still be interested in animation too and want to make use of features like 'Export to video'. We have not finalised the pricing model and I don't want to commit to anything specific at this early stage, but we hear your concerns about having to pay for both, and we will definitely be thinking about how to handle that.

    Thirdly for those of you concerned about a potential slowdown in development, we started technical research work last summer, and work has continued in the background right up until the beta announcement. I am not aware of anyone who complained during that time that our usual rate of work had slowed down, and I expect us to keep going as we have been. The real work has been the implementation of the Timelines feature, which has been worked on for some years now, and has been included in C3 from the start. It has its uses for game development, but it's also got its uses for animation purposes. That opened up the possibility of designing a dedicated animation tool with a feasible amount of work and with a potentially large upside. As I noted in the blog post, there are many features in common and so in the long run I expect almost all the work we do to benefit both products, which is also why I doubt there will be any meaningful slowdown in development of C3 in future either.

    Let us know if you have more feedback on Construct Animate, especially specific improvements we can make - for example there's some good feedback on usability here and we're planning to make improvements on that area soon. Our regular weekly beta updates will also update Construct Animate, so you can keep an eye on changes and let us know how things are developing over time too.