[peterigzParticipant]

Are you wanting T to be a generic type? I think you’re just missing the <T> after the class declaration..

Monkey

Class Store<T>

1	Class Store<T>

[peterigzParticipant]

For something that’s still pre-release I’d say it’s very stable, and also very fast

[peterigzParticipant]

I use a javascript linter which basically underlines syntax and other common errors like undefined variables (picks out typos), and it also alerts to bad coding practices, like only putting an “end” instead of “end if” as I’ve been doing

There’s some more info about the SublimeLinter here http://www.sublimelinter.com/en/latest/about.html

[peterigzParticipant]

That actually raises an interesting point, I always used a prefix for classes to avoid potential clashes with other mods, but now we have namespaces I guess that’s not so necessary.

Thanks for the new version I wonder how easy a monkey2 Linter would be to make…

[peterigzParticipant]

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

[peterigzParticipant]

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”:

Monkey

[crayon-5cba91cf99207484642078 inline="true" ]C:\monkey2\bin>mx2cc_windows makemods timelinefx MX2CC V0.011 ***** Making module 'timelinefx' ***** Parsing...

1 2 3 4 5 6

[crayon-5cba91cf99207484642078 inline="true" ]C:\monkey2\bin>mx2cc_windows makemods timelinefx MX2CC V0.011   ***** Making module 'timelinefx' *****   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

[peterigzParticipant]

Ahh the end if fixed most issues, thanks. It still doesn’t seem to highlight Interface or Class though eg:

Monkey

Interface tlQuadTreeEvent Method doAction:Void(ReturnedObject:Object, Data:Object) Method doAction:Void(ReturnedObject:Object, Data:Object, Result:tlCollisionResult) End Class tlQuadTree End

1 2 3 4 5 6 7 8

Interface tlQuadTreeEvent Method doAction:Void(ReturnedObject:Object, Data:Object) Method doAction:Void(ReturnedObject:Object, Data:Object, Result:tlCollisionResult) End   Class tlQuadTree   End

[peterigzParticipant]

Thanks for this For some reason sometimes things don’t get highlighted (see attched), any idea why that might be? Sometimes other things like Method or Class don’t get highlighted either.

Attachments:

1. 

   sublimehighlighting.jpg
   

2. 

   sublimehighlighting2.jpg
   

[peterigzParticipant]

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

[peterigzParticipant]

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?

Monkey

[crayon-5cba91cfa44aa314469513 inline="true" ] Method Clone:tlVector2() Return New tlVector2(x, y) End

1 2 3

[crayon-5cba91cfa44aa314469513 inline="true" ] Method Clone:tlVector2() Return New tlVector2(x, y) End

[/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!

[peterigzParticipant]

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:

Monkey

[crayon-5cba91cfa77f7588486945 inline="true" ] Method TFormBoundingBox() 'After the bounding box is updated, it needs to be moved into world space. boxoffset.x = tl_corner.x boxoffset.y = tl_corner.y tl_corner.x+=world.x tl_corner.y+=world.y br_corner.x+=world.x br_corner.y+=world.y End

1 2 3 4 5 6 7 8 9

[crayon-5cba91cfa77f7588486945 inline="true" ] Method TFormBoundingBox() 'After the bounding box is updated, it needs to be moved into world space. boxoffset.x = tl_corner.x boxoffset.y = tl_corner.y tl_corner.x+=world.x tl_corner.y+=world.y br_corner.x+=world.x br_corner.y+=world.y End

[/crayon]

worked out quicker than:

Monkey

[crayon-5cba91cfa77fe346607620 inline="true" ] Method TFormBoundingBox() 'After the bounding box is updated, it needs to be moved into world space. boxoffset = tl_corner.Clone() tl_corner+=world br_corner+=world End

1 2 3 4 5 6

[crayon-5cba91cfa77fe346607620 inline="true" ] Method TFormBoundingBox() 'After the bounding box is updated, it needs to be moved into world space. boxoffset = tl_corner.Clone() tl_corner+=world br_corner+=world End

[/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.

[peterigzParticipant]

I think I’ll aim towards the immutable approach as that seems to make more sense to me, and it helps to make structs stand out more in my head. I’m happy that just using them as they are is enough for a big speed boost

I looked at circular queues for particles; they look interesting but unfortunately my particles are quite complex with variable lifetimes, so will just have to use a normal stack I guess.

[peterigzParticipant]

Try adding

New AppInstance

At the start of main, I think that initialises a load of stuff in mojo so it’s ready for use.

[peterigzParticipant]

That’s interesting, so if I have a method in a struct it shouldn’t modify the field values I should create a new struct with updated values and return that? It’s making more sense now, I still have it in my head that creating things puts load on the GC but of course that doesn’t happen with structs because they’re on the stack. It seems kind of the other way round with structs in that it’s cheaper to create and let them go rather then change their values.

Thanks for the info on particles I’ll look into that

[peterigzParticipant]

Vec2 in std needs a type to specify whether is an integer or a float vec, so you can use either 1 of 2 aliases:

Monkey

Local vec1:Vec2i 'integer Local vec2:Vec2f 'Float 'or just Local vec3:Vec2<float>

1 2 3 4 5

Local vec1:Vec2i   'integer Local vec2:Vec2f   'Float   'or just Local vec3:Vec2<float>

[Author]

Posts