Ashley's Recent Forum Activity

  • Well, since triggers are allowed to trigger at any time, that could include their current position in the event sheet so they dont break any triggering rules...

  • im using it mostly for right click menus

    That sounds like a pretty big hack...

  • Nice engine, but you're wasting a lot of events (wasting CPU power) by making it custom

    This is a classic case of armchair optimisation. You can't say statements like this without measured FPS differences between comparison .caps. I'd put money that there's no detectable difference, due to the parallel working between the CPU and GPU (the CPU will spend lots of time simply twiddling its thumbs waiting for the GPU, which does the serious work with rendering, to finish). So I say if it works for you and doesn't dent your FPS, go for it.

    Don't feel bad though - it's common for supposedly experienced low-level programmers to make incorrect statements about optimisation - given the mind boggling complexity of modern CPU caches, pipelining and branch prediction, its virtually impossible to look at two bits of code and say for certain one is faster than the other.

    If optimisation crosses your mind, the key is measure, measure, measure. Otherwise you don't know.

    (in this case it's unlikely the built in behavior would ever be slower, that's not the point, if it's not measurable it's irrelevant)

    The main advantage of the platform behavior is its perfect

    Brave words from a man who's behavior accounts for over 5% of the total bugs submitted to Construct, ever!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Have you enabled '3D layering' for the layer the boxes are on?

    Can you post a .cap file demonstrating the problem?

  • Custom particle systems are actually surprisingly simple - it's effectively a bunch of sprites with bullet behaviors that have random adjustments to any aspect of the object such as speed, acceleration, angle, opacity, colour, etc.

  • In fact you can put a loop below any condition at all that picks from 'player', and the actions will only run on the instance(s) that met the parent event. This is how subevents work - they inherit the picking from the parent.

    Edit: manontherun: that actually wouldn't be a good idea, it would be much more work! It's easily possible with deadeye's method.

  • This is a fairly complex and subtle part of the runtime - and as far as I know, it'd be very difficult to change, so it'll most likely stay the way it is.

    The way it is, though, is that when you create an object, it doesn't really exist until the end of the next top level event or trigger. If you create an object in an event, as everyone knows the actions following it apply to the newly created object - but other actions won't apply to it until the current top-level tree of events or the current trigger finishes. (A top level event is anything which is not a subevent of anything else - I can't remember if events in groups of events count)

    So a potential problem would be creating an object in a subevent, then trying to use it in another following subevent. However, it's still picked in subevents to the event it was created in! Confused yet?

    Then triggers make it a bit more complicated - triggers are allowed to trigger any time they want, at any stage in the runtime. So what I suppose is happening, is the trigger is firing between running events and drawing the screen, so it goes:

    Run events (no objects exist so the action to make it change colour)

    -> 'on button clicked' fires: creates an object with default colour

    Display rendered, showing the default colour

    Run events again - this time changes its colour

    Nothing triggers this time around

    Display rendered, showing the changed colour

    That's why you see it a different colour for one tick - you're assuming the trigger fires before the events. They're allowed to trigger any time, so you shouldn't rely on this kind of behavior. You should set up your object in its initial state in the event that creates it.

    If you've made it this far, the collisions and key press events (and a rare few others) aren't real triggers. Real triggers show with the green arrow icon; the fake triggers like 'on key pressed' actually just have a built-in 'trigger once' to a 'is key down' test. So they run where you expect them to in the event list - and you can guarantee events after them will run after it. You can't guarantee that with real triggers - their position in the event sheet has no meaning except in relation to other triggers.

  • Search the tracker for known issues.

  • Voting closes tomorrow! Make sure you get your votes in!!

  • I'll see if we can stick it on CVS at some point.

  • But ... this release of construct should be a patch.

    If you have a poor internet connection, re-download 50mb is long. . .

    It's only 13mb

    was hoping it would be 0.99.41

    I'm sorry to crush your hopes and dreams of there ever being a 0.99.41, but I thought the "2" made it clear it was the next version

  • I think each new release (with a large changelog) will add 0.00.1 (eg. 0.99.3 -> 0.99.4) then if there's anything wrong with that build then minor fixes to that changelog will increment 0.00.01, like this build. This build definitely isn't enough to warrant being called 0.99.5 - and hopefully from now on, the first build in 0.99.x0 will be unstable, and the last build under 0.99.x will be stable.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,537,685 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
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x69
    Educator One of your tutorials has over 10,000 readers
  • x3
    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
  • x38
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs