Ashley's Forum Posts

  • I don't think any operating systems support streaming an EXE directly over the internet, but an existing EXE can stream data from the internet, but there aren't any plugins in Construct suited to that yet.

  • I'm not sure its possible. I already spent a while making the algorithm as accurate as possible. Have you got a .cap showing it being inaccurate?

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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