Ashley's Recent Forum Activity

  • The bone behavior doesn't do anything CPU intensive at all, as far as I know. It just does a bunch of interpolation functions which are really really cheap for a CPU to do. Have you got some framerate figures that demonstrate slowdowns are caused by the bone behavior and not by other things like effects on the sprites the bone is controlling?

    As I said in another thread, the key to optimisation is to measure! What are the framerates? How much is bone slowing things down?

  • Yeah, I'm not sure it's a good idea. Why should an event run differently depending on where it is? Dragging and inserting events could break them. And what can it do that you can't do with normal events? What need is there for it and aren't other ways (like groups) a better way?

  • Limitations in the way the runtime is coded; the way it's written means that the SOL cannot be modified while actions are running, because actions run on the content of the SOL. I might be able to tweak this to make it less confusing for 2.0, but it's hard before then since I never anticipated the problem.

  • Multisampling won't impact perforance much will it?

    Actually it reduces the framerate by approximately the multisampling number (so 4 times slower for 4x multisampling). So not quite so

  • Maybe i was a bit jumpy on the optimization gun, just trying to point out to a new user that behaviors are faster than using events in large-number-of-instance scenarios.

    Even that's a tricky statement - if the collision checks are bottlenecking your game (by the way, the collision checker is very highly optimised, so you must be absolutely HAMMERING the collision checker) then the overhead of the event engine is small compared to the collision checks. The overhead of the platform behavior is smaller - but the actual collision check is the heavy lifting here and both would do that - so again, would switching between one or the other really change the efficiency of collision checks?

  • Hahahaha

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

  • Have you enabled '3D layering' for the layer the boxes are on?

    Can you post a .cap file demonstrating the problem?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,444,128 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
  • x63
    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
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs