Collision module and performance

About Monkey 2 Forums Monkey 2 Development Collision module and performance

This topic contains 43 replies, has 8 voices, and was last updated by  peterigz 2 years, 8 months ago.

Viewing 14 posts - 31 through 44 (of 44 total)
  • Author
    Posts
  • #1179

    peterigz
    Participant

    My latest round of optimisations is now up to 5.6mill/sec which I’ll settle for for now, really pleased with that. I’ve learnt quite a few things along the way, and also some oddities. It’s definitely ok to modify the fields of a struct in some cases so I won’t worry to much about that, for example this:

    [/crayon]

    worked out quicker than:

    [/crayon]

    So I guess if your struct already exists and you need to clone it or change values then it can be ok. But in this case:

    vec.Normalise()

    Where the normalise method modifies the fields of the vector was quite a bit slower than:

    vec = vec.Normalise()

    Where it returns a new normalised vec. It’s really nice that mx2 gives you that extra control to make a difference with the speed of a program.

    #1180

    Mark Sibly
    Keymaster

    Have a look at Operator+=

    Mx2 will synthesize one for you, but you can provide your own too.

    #1181

    Mark Sibly
    Keymaster

    Also, just cleaning up another issue and there appear to be several places in timelinefx where you use ‘Stack’ or List’ without any type, eg:

    Method GetObjectsInBox:Stack(area:tlBox, Layer:Int[], GetData:Int = False)

    This was compiling before but wont with the next release. Full list of errors with my release…

    D:/dev/monkey2/modules/timelinefx/quadtree.monkey2 [246] : Error : Type ‘Stack<T?> is generic
    D:/dev/monkey2/modules/timelinefx/quadtree.monkey2 [291] : Error : Type ‘Stack<T?> is generic
    D:/dev/monkey2/modules/timelinefx/quadtree.monkey2 [841] : Error : Type ‘Stack<T?> is generic
    D:/dev/monkey2/modules/timelinefx/quadtree.monkey2 [936] : Error : Type ‘Stack<T?> is generic
    D:/dev/monkey2/modules/timelinefx/collision.monkey2 [1068] : Error : Type ‘List<T?> is generic

    #1182

    peterigz
    Participant

    Thanks, fixed. Although I still have work to do on some of those quadtree methods. Is there an equivalent to .Last for stacks by the way? I’m guessing Top is the same as First?

    I see what you mean about += operator, yes that does seem to sort it. The Clone method really kills it though (about 500k less), a bit odd?

    [/crayon]

    But then again I get different results elsewhere and clone seems fine. I think I’ll just put it down to the compiler and how it evaluates things in its own exotic way!

    #1183

    Mark Sibly
    Keymaster

    I mean ‘Operator+=’, not ‘Operator+’, eg:

    If you’ve defined an Operator+() but not an Operator+=(), mx2 will rewrite…

    p+=v

    …as…

    p=p+v

    …but if you’ve defined Operator+=(), mx2 will use that instead.

    I’m guessing Top is the same as First?

    Top is really ‘last’, ie: the last thing pushed/added. blah[0] is ‘first’. You can use a stack pretty much how you’d use a c++ std::vector or java ‘ArrayList’, ie: index with [i], so blah[blah.Length-1] is also ‘last’ or ‘Top’.

    #1191

    peterigz
    Participant

    Thanks Mark, yes I actually realised what you meant about the += and edited my post before you saw I think. I did add that operator to my vec class and it did help so that’s good.

    That’s good about Top too, I was hoping it’d be the same as Last 🙂

    #1228

    peterigz
    Participant

    Got this pretty much all working now 🙂 I do have one issue though, I just started updating the docs but now for some reason it hangs when compiling, doesn’t get passed “Parsing”:

    [/crayon]

    I’m not sure sure what I’ve done other then add in some docs. Latest version is on github: https://github.com/peterigz/timelinefx.monkey2

    #1229

    Mark Sibly
    Keymaster

    There are a few issues…but what’s hanging the compiler is a stray ‘=’ before a ‘#End’ in quadtree, ie: search for ‘=#’.

    Will fix!

    #1230

    Mark Sibly
    Keymaster

    There is also a bit of an issue with markdown ‘#’ clashing with ‘#’ for the preprocessor…need to come up with some kind of work around for this.

    #1231

    peterigz
    Participant

    Thanks! All fixed now. Thought there might be other issues as I had to merge some changes but obviously couldn’t test 🙂

    #2672

    Ethernaut
    Participant

    So I’ve found a little bit of time to play with the collision module, and I have to say it’s working great!

    My next step is to try to use this with my own entity system. In my old one, each entity used to have a “Transform” object that provided much of the functionality you already have in tlBox, like coordinates, dimensions, moving with collision, etc., so I’m going to just use tlBox instead this time.

    There’s one little thing I wanted to ask what’s the best way to implement: hierarchies, so that moving the parent moves all its children as well. Notice that in this case, objects need to store their local coordinates, and then calculate the world coordinate before they can do anything useful.

    Should I add a step somewhere that adds the coordinates together on every frame before displaying and checking collisions? Os is there a better, built in way to do that?

    Thanks!

    P.S. Here’s a quick test I did to get my feet wet:

    #2684

    peterigz
    Participant

    I think my approach was to separate the collision box from the entity rather then try to use it as the thing that manages all the coordinates of the entity. I guess you could do it like that but as tlBox doesn’t come with a local vector (only world) you would have to extend it and then override tForm() to transform stuff from local to world.

    So I would have the entity have it’s own vectors to manage its position and update it’s collision box each update, which is a little bit more overhead but ultimately more flexible. That also goes back the other way if you use prevent overlap, whereby the collision box would need to update the entity coordinates after a collision.

    Under the particles branch on github there is gameobject which might help (https://github.com/peterigz/timelinefx.monkey2/blob/particles/gameobject.monkey2). I think use a couple of collision boxes, one for actually calculating the collisions, and a container box, which updates to envelope the whole entity for off screen culling and such. I wrote it a while ago though so I’m not sure what everything does!

    #2695

    Ethernaut
    Participant

    That’s great, thanks! I’ll dig into that gameobject code and see how I could adapt it as soon as I find a bit of time again.

    Just out of curiosity, I see that you added a lot more classes and stuff, but has the collision code changed much since last month’s commit (which is what I’m using currently)?

    I think I’ll go with a “transform” object just to keep that stuff separated from entity events and components, and I’ll handle the transform inheritance and collisions through the transform class. Thanks for sharing!

    #2710

    peterigz
    Participant

    I haven’t touched the collision code, only added all the extra timelinefx stuff so it should be all the same when I eventually merge it all.

Viewing 14 posts - 31 through 44 (of 44 total)

You must be logged in to reply to this topic.