Ashley's Recent Forum Activity

  • I am worried the consequence of this thread is people telling each other "don't use families", which would be poor advice. As ever the most critical thing in performance is to make measurements. The only reason you should ever remove a family is if doing show measurably increases performance enough to warrant the increased complexity of events. It's also possible that you have thousands of instances in a family, but you run so many events on them that the overhead of the family is negligible; in this case removing the family doesn't bring any meaningful performance improvement but still causes people's events to get much more complicated and difficult to maintain.

    This is by far the most important point and the tutorial doesn't mention it. It instead says things like "families is something that you should be using quite sparsely". There is no reason to use them sparsely, if they don't measurably impact performance. Not everyone has 10,000 instances in a layout. This kind of advice could end up making beginners needlessly avoid useful features and end up making their events far messier.

    The same goes for behaviors and animations. There's a time and a place to say "have you tried everything else and do you have a project with thousands of instances? Well, you can try these advanced options..." But right now I think making simplistic statements like "behaviors have a 40% performance impact" does more harm than good, especially when it's not entirely accurate (e.g. behaviors which do actually need to tick, are doing useful work, so that 40% is useful work and not wasted).

  • It looks like the SDK doesn't support color properties yet - I'll add that to the todo list.

    Link properties work significantly different in C3, it's probably not easily possible to automatically convert them. In C2 they would call OnPropertyChanged() when clicked, but in C3 the property has a linkCallback option that is a JS function. In C2 the callback type defaults to (effectively) "for-each-instance", but you can specify a C2 option "firstonly" to only call on the first instance; in C3 this has been replaced by the "once-for-type" callback option, which instead passes an IObjectType to the callback rather than the first instance. I think the best you can do is create a stub function for the linkCallback, and put an instance parameter by default, or iObjectType parameter if the C2 plugin specifies "firstonly". Filling the function will just have to be a TODO comment, since it's probably too difficult to lift out the code from the property changed handler automatically, it's easier for the developer to do.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I just realised the Scirra forums have been running for 10 years now! Our first posts to this incarnation of the forum were in late 2007, where we were concerned with the latest release Construct 0.8, an early version of Construct Classic. We've come on a long way!

    In that time we've had over 100,000 topics, 630,000 posts, and 350,000 users signed up. This works out to an average of about 170 posts a day, for 10 years. Also, it looks like about 3.9% of all posts on the forum are mine ??

    Thanks to everyone who's been part of the forum over the years! ??

  • CKMartin - OK, I added Czech. You can request access here: https://poeditor.com/join/project/gM9NeJ7wtR

  • Adding another frame to the "sprite" object seems to have a performance impact as well (about 25%) But it only happens if you set the speed to anything else than 0.

    Yeah, this is another deliberate optimisation which only applies some of the time. Animated sprites need to be ticked to advance the animation frame, but to avoid the ticking overhead for static sprites, if it has only 1 frame or an animation speed of 0 it doesn't tick it at all. This is so all your static scenery and background objects don't get the overhead of ticking if they're not animating. It will start ticking if you set the animation speed greater than 0 (and it has more than 1 frame), but one quirk is it never stops ticking that instance until it is destroyed, i.e. it assumes it will always be animating thereafter.

    I think this is pretty reasonable, the main goal is to remove overhead from static objects, and it does the job. However it's true that we could refine this a bit so as sprites stop playing animations they also stop ticking, and only start again when they start animating again. I've made a note to look in to doing that for the C3 runtime.

    Adding something to the quadissue test and measuring the impact seems to be a good way to measure the engine overhead of various features! I'd warn though that the overhead isn't necessarily always important - for example in the animated sprites case, I would guess for most projects sprites either animate or don't, so the ticking overhead issue probably isn't particularly significant.

  • We've added a number of new languages to the translation project! We expect many of these to be long-term projects and some may remain idle until enough contributors sign up. However there is no harm in making them available so anybody who wants to get started can do so. This thread has more information about how to get started.

    Here is a complete list of all languages we've now got translation projects for, and their status:

    • Belarusian [started]
    • Bengali [new]
    • Bosnian [in progress]
    • Chinese (simplified) [started]
    • Chinese (traditional) [new]
    • Czech [complete]
    • Dutch [complete]
    • English [complete]
    • Filipino [new]
    • French [complete]
    • German [in progress]
    • Greek [new]
    • Hindi [new]
    • Hungarian [in progress]
    • Indonesian [in progress]
    • Italian [complete, in review]
    • Japanese [started]
    • Korean [in progress]
    • Malay [started]
    • Punjabi [new]
    • Polish [in progress]
    • Portuguese (Brazilian) [complete]
    • Romanian [in progress]
    • Russian [complete]
    • Serbian [started]
    • Spanish [complete]
    • Swedish [in progress]
    • Thai [in progress]
    • Turkish [in progress]
    • Ukrainian [in progress]
    • Vietnamese [started]

    Languages are marked 'new' up to 2%, 'started' up to 10%, 'in progress' beyond that, at which point we start bundling it in Construct 3 available in developer mode, if it passes verification.

  • Hopefully I'll be able to post more news about the state of the C3 runtime by early next year. I just don't want to commit to too much yet. It'll be our main priority after the full launch of the C3 editor, though.

  • Changing Z order in a loop is inefficient because it changes the Z order repeatedly. The 'sort Z order' action is efficient because it does the sorting, then changes the Z order once at the end. So you should basically only use the 'sort Z order' actions for large numbers of instances. However if you just update the instance variable it uses in a loop, that's fine, because updating an instance variable doesn't itself change Z order.

  • Nice to see an initial version appear so quickly!

  • I don't think these other cases are the same polymorphism issue.

    I noticed a hit of around 40%, even when the solid behaviour was set to disabled.

    Currently the C2 runtime unconditionally ticks all behaviors. The solid behavior does not need ticking, so this is wasteful when you have a lot of instances. The C3 runtime is smarter and only opts in to ticking the behaviors that need it. So I tested this as well and in the C3 runtime, adding a solid behavior does not impact the performance in the quadissue test. (This isn't polymorphism, it's just better design.) Some behaviors do need ticking though (generally the movements), there probably won't be much change for them, but for those it has to do per-tick work anyway so it's necessary.

    [quote:15a6nvsr]EDIT2: Adding the effect grayscale on the sprite game me 32000 max sprites, where as original was 180.000

    But adding the same effect to the Layer instead of the sprite showed now significant drop.

    Rendering effects has quite a high overhead per effect, and using a layer effect instead when you have a lot of instances is already in our performance advice. Rendering effects is complicated so there will probably be quite a high per-effect overhead in the C3 runtime too, but this also isn't polymorphism, it's just that rendering effects involves extra work.

  • We don't want to put out the full source of the built-in plugins in C3, because in C2 this basically caused ongoing compatibility nightmares, to the extent I'd rather simply block the option of copy-pasting an addon to tweak it, and force us to come up with another way to alter other addons in an extensible way. You can however see the runtime scripts in preview mode, as pointed out. If you have any questions about the SDK I'll try to answer them on the forum.

    The point about loading project files is a good question, because it's different in C3. Preview mode doesn't actually host on a server, it keeps everything locally, so there's no direct URL to project files. You can solve this by asking the runtime for the URL to the resource with:

    var urlToRequest = this.runtime.getLocalFileUrl(projectFileUrl);[/code:132x49b4]

In preview mode, urlToRequest will be a blob URL that you can fetch normally and will load the project file locally. After export this just passes the URL through and fetches it from the network as usual.

  • It's not been planned in much detail yet. It's an important goal, but is probably some way off at the moment, since we want to have the C3 runtime in place first, and then probably significantly revise the way functions work after that.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,774,038 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
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs