Ashley's Forum Posts

  • Test test test 2

  • Test test test

  • (please ignore)

  • I still don't see much use in any of these examples.

    Take an event like this:

    + On Player collides with Powerup

    -> Destroy Powerup

    -> Add 1 to Player score

    Suppose you somehow bind that to the Player object. How does it run then? As far as I can tell - exactly the same. So there doesn't seem to be any purpose to it. In other words, the way Construct picks instances already does everything necessary.

    If you want to create different sets of events per instance, then I can see major downsides to that. Firstly it would have a high performance cost: Construct would have to re-run entire sets of events for individual instances, rather than picking sets of matching instances like normal events. It would be in the ballpark of having a 100x performance overhead if you have 100 instances, similar to moving an entire event sheet under a "for each instance" loop which needlessly re-ran everything repeatedly per-instance. Secondly it would seem to have a significant maintainability cost - you can no longer just look at an event sheet and know what will happen, now you have to sift through individual instances and review their logic independently; if you see an instance misbehaving, now you have to figure out which instance that is exactly, identify its corresponding set of events, and debug those individually. I have to say, that sounds like a nightmare! And thirdly, it's limited: which events run for dynamically created instances? There doesn't seem to be a good way to set that (and then imagine debugging that).

    The current design of centralised event sheets shared across the whole project is deliberate: it's good for performance and maintainability. I'm not convinced anything much in this area would actually make anyone's life better. At best, maybe you could attach an event sheet to an object so it goes with it when you copy/paste it, but in all other regards it would work identically to event sheets now - but that seems to be something different to what people are talking about here. Still, I'm open to reconsidering if someone can clearly and concisely describe a really great example that explains why this is valuable and avoids all the potential downsides, but I remain sceptical.

  • People occasionally suggest something along the lines of "associate events with a single instance", but it's not clear what that would actually do. Would the events run differently? If so, how exactly? If not, what's the point?

  • If the Physics collision mask is "circle" or "bounding box", it ignores the collision polygon, as described in the documentation, e.g.:

    Circle ignores the object's collision polygon if any, and for the purposes of Physics collisions considers the object to be a circle.

  • Well, that imposes a performance cost on all games, for one very specific case.

    Frankly the effect compositor is so brutally complicated I'd rather not touch it. Working with it is an absolute nightmare and it's been really hard to get even small changes right in the past.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The effect compositor is super complicated. It has lots of separate special paths, and it knows about the source texture for Sprites and intermediate surfaces, but not Text objects (which is only significant on the first draw).

  • The problem is this, the engine detects collisions when the objects are just close, not touching.. close.. It seems to be around a 6-10 pixel difference.

    I would guess the object image doesn't line up exactly with the collision mask.

  • Currently the source rectangle and pixel size parameters are only set when rendering an image-based object like a Sprite. This is because those values come from the sprite sheet (the pixel size being derived from the source sprite sheet texture size, and the source rectangle being set from the area of the spritesheet being rendered for the current sprite). It might be tricky to figure out how to apply those to non-spritesheet objects like Text.

  • Construct games should run fine on Android, and many do. It's hard to help without seeing performance information such as the relative CPU and GPU usage of the game. For example if you max out the GPU usage, then it's limited by the hardware, not Construct or any of the software. So the conclusion then is that switching software won't help and you have to optimise the game to be less intensive. If you max out on CPU usage, then you need to look at the game logic. In that case Construct's own profiler can tell you where the time is being spent and what you need to optimise. Usually it's straightforward to make improvements. JavaScript performance is extremely competitive these days and it's rare to see anything that is genuinely slow only because of the overhead of JavaScript; usually it's something else. So these days I don't think there's any performance drawback to Construct and HTML5 games.

  • See also the example Integrating events with script

  • It should work fine. It's hard to help without more information.

  • Sprite fonts are probably faster than text objects, since text objects use antialiased vector font rendering to a canvas which is then uploaded to a WebGL texture, whereas sprite fonts are basically the equivalent of rendering a sprite per character (which is super fast). Normally it's not important unless you have an intensive case (e.g. lots of large, constantly-changing texts). As ever you can measure it yourself.

  • The sad face icon means Chrome's canvas rendering crashed, which typically is indeed a GPU driver issue.