Ashley's Recent Forum Activity

  • Check the browser error console (Ctrl+Shift+J in Chrome). All your .ogg files are returning 404 not found. Most likely you need to set up the necessary MIME types.

  • Post a bug report to the forums following all the guidelines.

  • The main issue here is game engines run in discrete steps (frames), rather than continuously. They create the illusion of continuous motion with many small incremental steps at a relatively fast rate (normally 60 FPS). A smaller factor is system timers are not always perfectly accurate, so dt has small random variations. And an even smaller factor is adding up floating point numbers accumulates error with every addition.

    If you rotate an object by 90 * dt degrees every frame at 60 FPS, then it will be rotating about 1.5 degrees per frame. You only need 'Every X seconds' to be off by a single frame and you have greater than 1 degree error, without even taking in to account the small random variations in dt, or the floating point addition error. Even if all timers were perfect and the framerate was perfect, at 60 FPS then 'Every 1 second' is due to run exactly at the time the 60th frame runs. Then you only need the tiniest bit of random jitter in the timing systems to cause the next timer to fall on a random frame: either just before when it's due (so that frame), or just after when it's due (so the next frame). In practice there's probably enough jitter to throw this out by 2 frames.

    Solution: don't expect to get the right number of frames. A better way to achieve this type of thing is to use an algorithm like "rotate at 90 * dt degrees per tick until it is clockwise of its destination, then assign the end value again". The "assign end value" bit means that if you end up somewhere like 90.0001 degrees (due to any of the other sources of error), then you just set it back down to the exact value of 90.

    None of this is specific to C2 - it will be the case with any game engine using this approach.

  • You do not have permission to view this post

  • I am afraid that Lately I see Ashley being fast to reject ideas coming from forum members.

    If I see problems with suggestions, I will point them out. If people argue convincingly against me, I will consider what they say. Also as ever we get far more feature requests than we can possibly deal with, some of which are multi-month projects, so it is important to set a high bar and not get sidetracked with loads of experimental ideas that may or may not work out.

    In particular new UI features are very time consuming to develop, and what is outlined here is probably several months of work. There is a great opportunity cost there, since if it doesn't work out or few people end up using it (like with multiplayer), then we've lost several months work that could have gone on something more useful.

    So I can see how it might look like I'm trying to shoot everything down, but really it's how I test ideas to see if they're worthwhile.

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

Ashley's avatar

Ashley

Online Now
Early Adopter

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

Twitter
Ashley has 1,834,474 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