Edit key is down condition, as key pressed will only move it once...Oops!

If that does not suit, maybe experiment with "move at angle"

What it offers is 100% control of your movement without the set behavior interfering

give a default sprite an instance variable say speed,set it at 100 for now, create event on left arrow pressed

set sprite x to sprite x-sprite variable <speed>*dt this will move it left

create event on right arrow pressed

set sprite x to sprite x+sprite variable <speed>*dt this will move it right...

same applies to Y for up down...or both for diagonal...alter the variable to change speed

At runtime it makes no difference, it has to go into VRam as a texture to be displayed...The sprite sheet cropping is to reduce the download time...

You would probably find it easier setting up custom movement rather than fight the inbuilt 8 direction behavior.. just adding x*dt to your axis then set your animations from variables.

danialgoodwin I was under the impression the collision cells were a performance enhancing feature, so minimal is too much...

Objects are a mix of random, player placed and static, but mostly static after being randomly placed at start of layout not sure that's relevant as most object in any project would be similar...

objects again a mix but pretty small 16x16 the most prevalent objects, that is probably why I can get away with so many collision checks per sec...

By "brute force optimised" I mean, I have not edited My event sheet, to ensure I do not break any of the caveats, required for the collision cell performance gain.

Cheers for feedback.

So nobody has gained or lost performance since collision cells were introduced?... Kinda odd...

Maybe this as come across as a complaint, but actually I am really impressed with C2 performance overall...

At the moment I am stress testing, running R153 At fullscreen 1024x768 it's pushing 169 meg of video ram with average 900 objects in the layout, hitting anything from 200-1000 poly checks per tick! CPU average 35%-40%

In chrome I'm getting a consistent 50-60 FPS, node webkit rarely drops below 60, firefox struggles at 15-20 FPS.

Not bad, In a browser environment on a seven year old system running windows XP, fitted with an ATI radeon 3400 graphics card...

What I don't get is why exactly the same game, after updating to a C2 build that uses collision cells loses me 20 FPS on chrome 10 FPS on Node and Firefox sits at 10 FPS but still functions...just.

If the cells are not suited to My game, "Brute force" is fine by me, but I could just do without the performance drop.

I did notice that in recent C2 versions the poly checks per tick can rise by a good few hundred and only 1 cell ever seems to move, but that's in my brute force optimised build, I gave up on the cells weeks ago...

Yup, auto "breaking change" is not an option I would click...

I doubt you use all new features each upgrade?

Also can't beat update day, scurry for the lightning draw..can Ya?...

DARTH crusher Good taste there old chap!

Nobody has mentioned Defender, Berzerk or Phoenix! shame on Ya!

The introduction of collision cells to increase performance was more than welcome, as optimised as C2 is "brute force" collision checking in a frame rate undulating browser environment, is a bottle neck on many projects...

Unfortunately I did not get the performance gains I had hoped for, in fact I got a drop in performance, despite my game being pretty much a perfect fit as far as I can tell, breaking none of the Caveats "many static instances, same type, same none parallax layer"

Even reworking events removing "focusing" collision checks moving collisions to top level ect, did not help...

I find it difficult to believe that C2 sizing the cells automatically can be optimal for each and every project, and surely if the cells are unused due to caveats, the fact it has checked for them, will give a performance drop overall?

The caveats, can be difficult to track in a complex event sheet with many objects involved, maybe I have missed something? and that's half the problem.

I am curious if Cell sizing options or a collision cells off option, would allow fine tuning of collision check heavy games, I would certainly like the option...

So my question is, has anybody else gained or lost performance, in games that were in development prior to the introduction of collision cells?

played the game, like the pixel retro look...

The knives are very fast and small, you could make the collision box larger without increasing the size of the actual graphic, just increase the canvas size,with bounding box collision, same goes for the walls...

I have not tried the game but, If you are using bullet behavior for the knives it uses delta time to calculate pixels moved per tick, so a lower frame rate will result it it moving more pixels each tick, if that is more than the width of the wall then it could glide right through without a collision being detected.

You can counter this by either making the sprite hitbox larger, slowing the knives down or making the wall thicker... a combination of all three would probably be best...