Ashley's Forum Posts

  • Either I misunderstand your events or they are wrong. You appear to have two modes:

    1) a canvas the size of the window with low quality fullscreen mode. Since the canvas is the size of the window, it won't stretch the display, so low quality fullscreen mode has no effect, it's the same as rendering at full resolution.

    2) a canvas smaller than the window, with high quality fullscreen mode. This is the same as rendering at full resolution.

    So both ways render at the same size with identical GPU loads.

  • You do not have permission to view this post

  • You can, but diffuse shadows are only supported with infinite shadow length (i.e. zero height).

  • As said this would be useful for setting things up - and as said it is totally a question of approach - for example, I would, for example, like to make a jungle scene with vines and all sorts of little bugs and animals and so on - everything nicely animated and alive and yet background when it comes to gameplay - with a system like this I set everything up it never enters the event system which stays clean and ready for the gameplay logic.

    I'm not sure I get your point. A lot of behaviors already work just fine without any events at all. For example you can apply the Sine behavior to a bunch of objects and they all become animated and alive, with no event involvement at all. So you can already get that with the existing behavior system. Then if you want to add some kind of logic to that, then I think events are still a better way of doing that.

  • 27 physic objects on html5/js based engine is already too much

    I don't think that advice is true any more with the asm.js physics engine. It should run close to native speed.

    Make a minimal .capx that demonstrates the problem and share it here. If even 6 objects is slow, that suggests physics is not actually the problem, it must be something else.

  • You do not have permission to view this post

  • The point here is that you would be able to do all the same things, but not fill your event sheets with, basically, non-events like: Set setting A to this, Setting B to that, Setting C to that, etc. ... As is I would say there's plenty of "event spagetti" just to set up some mildly random or reliant things.

    You talk it down, but the thing about events is you can reference arbitrary variables, functions, other events, other actions and so on - in other words, custom logic. The system you've shown as I see it only supports a very, very small subset of the "anything goes" capability of events. Want a variable time for the timer? Want a trigger to enable/disable? It looks like you'd be straight back to events. So this is a lot of work for something which is only useful some of the time.

    Anyway as far as feature requests go, this appears to be just another way of doing what's already possible via events. Generally I prefer to work on feature requests where it's not yet reasonably possible to achieve the request by any other means. That actually increases the scope of what you can do with Construct 2.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Closing as this is not a bug (as in a defect). The platform behavior only has one jump strength setting so that is the one used for both jumps. It should be straightforward to customise this with events if you want to change that, by turning off double jumps and making your own with events.

  • I can't reproduce here - it looks correct in Chrome, Firefox and IE11. Are your graphics drivers up to date?

  • This is actually by design: using 0 means "connect to the center of gravity", which is in the middle. To connect to the object origin, use -1 (or create another image point there). That wasn't documented anywhere though, so I've updated the manual entry and the parameter descriptions for the next build.

  • Closing as not a bug.

  • This should be fixed in the 0.12 alpha, or by the final version of 0.12, so closing for now.

  • The Steam version is effectively identical to the standalone version, the only difference is in how it determines if it's licensed. So it would be odd if there is any difference. I just tested it with the Steam version as well and I can't reproduce any problem there either. If you download the free edition from our site is that affected as well? (That would establish if the problem is Steam-specific or not)

  • Can't reproduce - it remembers the theme correctly here.

  • Closing as won't fix: this is just because the behaviors update their positions at different stages within the tick. In particular the Pin behavior updates object positions at the end of the tick, so your overlap event is always testing the latest player position with the previous tick's position for objects with the Pin behavior, so it's always testing it at speed x dt pixels behind where it appears. The overlap condition is actually working correctly.

    The easiest workaround is not to rely on behaviors and position everything with events, so you can control the exact sequence of position updates and collision tests. We can't change the behaviors since that will break other games.