Ashley's Forum Posts

  • It's powerful enough to make games like this: http://store.steampowered.com/app/332250/

  • The full license is here: https://www.scirra.com/store/licensing#license3

    It says each purchase gives you the right to use the asset in unlimited non-commercial projects, or one commercial project. So if you want to use it in two commercial projects, you need to purchase it twice.

  • Android uses exactly the same code as all the other platforms, so I don't know any technical reason this would be the case, other than your game works differently and requires more data on Android because of your own changes, or the measurements you are looking at are inaccurate.

  • There is nothing Construct 2 can do to work around popup blockers - they are designed to block popup ads that would irritate the user, and anything C2 could do to circumvent it would be done by ads as well.

    Generally the workaround is to only open a window in a user input trigger, such as "on object touched". Browser popup blockers allow popups in user input events, since they are treated as intentional actions by the user.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Can you test the latest version r230, as well as Firefox, as per the bug report requirements?

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