Ashley's Recent Forum Activity

  • You should report these issues to Intel - Construct 2 does not control the build process, that's done by the Intel XDK.

  • Closing as won't fix: the expected result is incorrect, text boxes are single-line by design unless you choose textarea mode. This is how browsers implement them, not Construct 2. The positioning isn't centered but I don't think this aspect is standardised. The editor representation is never going to be exact either since form controls are rendered differently in browsers so it's just basically a placeholder; for example the checkbox control doesn't really look like what you really get either.

  • Closing, please see the bug report guidelines, we never investigate reports like this.

  • I wanted to make an app to process insanely long chunck of HTML, (I'm speaking of several millions of caracters), but just found that construct would truncate any string I give it to the 524.288th caracter

    That shouldn't happen. Does every browser do it? Can you make a minimal test case and file a bug report for it?

  • Ashley , How does the current method increase performance?

    Because not doing work is always faster than doing work.

  • And then when checking instance list, cycle through the would-be indices- if they are greater than the instance list length, then check the new object list instead?

    This is also extra work that would add a great deal of complexity and degrade the performance of all projects, just for this corner case.

  • Would it be possible to request a new type of top level event related to creation of objects that allows for picking? Would there be any drawbacks to changing the "On created" condition to be a pure top level event?

    No, this does not solve the underlying problem. The engine cannot support potentially modifying the instance lists while it is using them, and so there can neither be a new kind of event, nor a special kind of trigger, that works around this.

  • The image you see in the image editor is the source image. Objects in the layout are always rendered from the source image and stretched to their display size. So resizing objects in the layout has no effect on the source image. The source image will be fully loaded in memory regardless of the display size, but resizing an image from 64x64 to 32x32 will only save about 12kb of memory, so it's kind of pointless to do it in the name of memory. In this case I think just stretching them in the layout view is fine.

  • Construct 2 only issues draw calls for objects that are visible and on-screen. Invisible layers are skipped completely and issue no draw calls at all regardless of their content.

    In extreme cases (which I guess you might be seeing) a huge number of off-screen objects can still cause overhead in draw calls due to all of them having to reject the bounding box test which checks if they are on-screen. This is a tiny super-fast check though so you will need thousands of objects to see any effect here. This is precisely the problem render cells are designed to solve: it means it only checks instances near the viewport, rather than everything on the entire layout. (But note the restrictions on render cells.)

    Invisible layers on the other hand skip their contents entirely (since it makes no difference if they are on or off screen), so it is faster to hide large numbers of instances by putting them on an invisible layer than moving them offscreen. This is a micro-optimisation though, so again is only important with thousands of objects, and render cells should in theory avoid the need to use this workaround.

  • The User Media object already supports this. There's a "speech synthesis" demo built-in to C2 that demonstrates it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Closing as by design. This has come up a few times in the past and it's not feasible to change it.

    The problem is the event system is nested, and internally the engine will be half-way through iterating the instances list while running various aspects of an event. Creating a new instance adds a new instance to the instances list, and destroying an instance removes it from the instances list. Modifying these lists while they are being iterated for running events causes bugs and crashes, because it's unpredictable to modify a list while you're simultaneously using it. A long while ago user's projects were crashing because of this problem, so we made this change intentionally to fix it. The end of top-level events are the only safe place to actually update the instances lists, because they are guaranteed to not be in use at that point. After top-level triggers also counts, but not functions (or other triggers fired from inside conditions/actions/expressions), because then you're still nested inside another event.

    Note that creating works the same as destroying, i.e. a destroyed instance does not really stop existing until the next top-level event, although this tends to be less of a problem.

    Working around this from within the engine would degrade performance for all projects, because it would mean every loop inside the engine that deals with instance lists has to have a per-iteration check to see if the instance list was changed while it was looping, and then do extra work to mitigate that. Not only does this slow down everything (particularly tight loops which do little work), it is also a very complex engineering project that would probably take months and involve a whole load of follow-on bugs and further corner cases that need fixing. I really don't see that as a reasonable thing to do when it will also degrade performance everywhere, just to fix a slightly weird corner case which is possible to work around, so this is not something I think we will ever change.

  • Closing as not a bug. You must still specify the return type flag with the deprecated flag, which is what the error message is telling you. Otherwise you are saying the expression is hidden and has no return type (which affects projects that still use it).

Ashley's avatar

Ashley

Online Now
Early Adopter

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

Twitter
Ashley has 1,832,423 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
  • x6
    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