Ashley's Forum Posts

  • Heh, newt is right, the feature actually already exists: just use a large sprite and make your first condition "is overlapping sprite". That will efficiently reduce the list of instances to run the rest of the event on.

    Sure, you can make a test with 10,000 objects and measure all sorts of performance differences, but have you ever actually measured it making a difference to a real-world game? Most games use far fewer instances. Of all the projects I've ever debugged or profiled, people usually run in to GPU performance limits (a hardware limit) before CPU limits. I guess there are some special cases where a game really does involve 10,000 objects, but that's generally the exception, and then there are ways of reordering conditions to efficiently reduce how many instances you're testing against - e.g. using the overlapping sprite trick.

  • Time is our most limited resource. We are constantly working at full capacity on all sorts of things, including exciting and essential projects like the new C3 runtime, which nobody can develop apart from us.

    The SDK exists because we don't have time to implement all the features everyone wants. In acknowledgement of this, we allow third-party developers to come up with addons independently of us, so some ideas that we simply do not have the resources to implement, can be implemented by others.

    For this reason it's out of the question to expect us to do any sort of maintenance on third-party addons. To start with we don't have the time anyway, but on top of that, it's unfamiliar code often written in a radically different style to what we'd use, and being dragged in to maintaining third-party code defeats the whole reason the SDK exists, which is to allow development without our involvement.

    Third party developers can, and do, disappear at any time, for any reason. This has happened before, and will happen again. When you choose to use a third-party addon, you are entrusting any further maintenance and support for that addon to someone who may or may not be around in future. It should be common sense: you're making a trade-off between using a new feature that may be valuable to you, versus the uncertain level of support for that.

    If a third-party developer disappears at any time - and it could happen to any other developer, for any reason at all - then I'm afraid they're the ones who have left you out in the cold. But you should have been aware that was a possibility, and if your project is important, perhaps made some preparations for it. After all often these are volunteers working on addons in their spare time - do you expect the same level of support as a for-profit company with full-time professional developers? No, that's unreasonable. They do what they can when they feel like it. That's the deal.

    As I say it's happened before and will happen again. The problem is unreasonably expecting a professional level of support from third-party developers. If you are not aware of the deal you're making when you use a third-party addon, this is your wake-up call. Maybe you want to think a little bit more carefully about it next time you use a third-party addon.

    If you're missing any really crucial features that you've previously depended on third-party addons for, you can post them or vote on them here: https://construct3.ideas.aha.io

    Any really important ones we can build in as official features.

  • TheRealDannyyy - I don't think you understand, that in engineering terms, undocumented features exist for a reason. As I mentioned in that other thread often it allows us to move quickly and make radical changes without the burden of backwards-compatibility dragging things down. So some features will remain undocumented for that reason. Again, all products have undocumented features, and experienced engineers know not to rely on them or at least not to expect any support for them - this is not controversial or new. We're actually in general more closely aligning ourselves with the industry standard approach. Outside of that though, we will make sure we document as much as possible.

  • Your projects do not disappear if your C3 subscription expires. You can still open them, preview them, export artwork and other assets etc. It's only the ability to edit them that expires.

    Also, many existing C2 tutorials should be straightforward to apply to C3 as well - the UIs are generally similar.

  • It also looks perfectly smooth here. The engine is not doing any significant amount of work. So I would guess this is just a system v-sync issue. It's been discussed a lot on the forum already if you search.

  • The ^ operator calls Math.pow() which might be as slow as Math.sqrt(), I'm not sure. For best performance I just use value*value.

    If you profile a snippet of JavaScript vs. doing that in events, then yeah, events have a performance overhead. As with any higher level abstraction it tends to come with a performance cost, just like how Python tends to be slower than C. That's pretty much unavoidable, it's just how these things work. Most of the time though, it doesn't matter. It's only if you're doing something thousands of times every tick that you'll be able to measure a difference, and even then, will it actually affect a real-world game? Probably not - so I'd guess that writing a behavior to make a bunch of specific tests is not necessary. Also most of the usual suspects for performance are already highly optimised as internal code, such as collision detection and pathfinding.

    Exposing collision cells to events is an interesting idea - I think we could do something like "pick instances in rectangle area" without having to iterate all instances.

  • Benchmarking is hard. You're not actually measuring picking performance in an isolated way.

    Firstly the test is set up a little weirdly - I'm not sure why you have that whole thing with the 'picked' flag going on, you don't need it and it means it's possible for some instances to be processed twice in one tick, which I think means it's not a fair test. The most obvious setup is every tick, reset the state for all instances, then in an event below that, have one single test that changes the state of picked instances.

    Secondly I profiled the first case; the main bottleneck is the distanceTo calculation (which involves a square root), so that one's basically a math benchmark.

    Thirdly, for distance comparisons like "distanceTo(a, b, c, d) < 10", it's actually quite a special case performance-wise: it comes down to a comparison like sqrt(dx*dx + dy*dy) < 10. Then if you square both sides you can test dx*dx + dy*dy < 100, which eliminates a costly square root calculation. In some cases the engine does this internally, but if you write distanceTo() in an expression it won't. So then you're comparing doing a square root to not doing a square root.

    Fourthly, LOS works completely differently: it's mainly designed to use a collision-detection algorithm. It also takes advantage of collision cells to reduce the test candidates, which none of the other options do.

    Basically this is mainly a math benchmark. It's not much faster in the C3 runtime, because math doesn't suddenly get faster there. Actually, I think it's a good sign that the engine is well optimised enough that something like whether or not you include a square root makes a measurable difference.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
    • Post link icon

    It sounds like you missed the sdkencryptedappticket DLL.

  • Somehow literally all other products on the market get by without open sourcing all the core components. I am sure we will be fine. I don't think there needs to be so much worry over it.

    Scoremonger - thanks for the suggestions.

  • Construct 3 currently uses the same runtime as Construct 2, so the performance should be the same. (For most devices, C2 performs just fine on mobile.) Soon we will be releasing a new runtime for Construct 3 though, which should be much faster.

  • Please see the bug report guidelines. They explain what to do.

  • The runtime doesn't normally touch any CSS, since it only renders to a canvas. You've only provided a screenshot, which means we cannot investigate this, so closing. Please see the bug report guidelines.

  • Why did these devs who came to you with their dramas of failed plugins not just roll back their version of c2 so everything would work again - why make scirra responsible for un-f'ing a 3rd party's lack of support?

    Why even allow the possibility for things to go wrong? It's obviously better if it's not possible for the problem to happen in the first place. Also, people could probably blame us for these problems anyway - they'd ask "why haven't you better managed the ecosystem to make sure this kind of thing doesn't happen to your product?", and that would be a fair question.

    As I said - we'll be better documenting the new runtime so you'll be able to see everything that's available more easily. And if you have some good ideas, I can always add new samples showing how to do some interesting/unique things, which will help get new developers get going.

  • I'd also add that if you copy-paste our code, you can't release it under an open-source license, because the runtime is not open source licensed and you don't have permission to do that. I'm not going to start chasing anyone over this, but it should be obvious that it's not exactly brilliant from a copyright point of view either.

    If we force everyone to use a solution that doesn't involving copying engine code, then that's actually better for open-sourcing addons as well - you actually have permission to use the license you want

    • Post link icon

    All their past releases are here: https://partner.steamgames.com/downloads/list