[peterigzParticipant]

If I ever get around to installing linux, then I’m sure I’d do that but can’t say when I’ll get around to it

I’ve got to the stage now where all effects in the example library work exactly as they should. Now to start optimising and see what I can do there, I’m sure there’s quite a few things I can do to get more performance out of it. I’ve uploaded a windows demo if anyone wants to take a look, and you can get the code to have a play with from the particles branch on github here: https://github.com/peterigz/timelinefx.monkey2/tree/particles

Loading an effects library is a bit of a pain at the moment as you have to import each asset manually – @mark, any idea when the zip module might be ready to use?

Download windows demo here

[peterigzParticipant]

I think the stack is a key thing here, if you didn’t have structs, then if you wanted to store vectors or matrices in a usable way you’d have to use a class which are objects managed by the garbage collector. So if you have a game entity that has vectors to store coordinates, velocity, direction and so on, that ends up being a lot more work for the GC. But with structs they’re all on the stack so when the game entity is removed the GC has less clean up work to do.

Yes you could store coordinates as individual x,y float fields in your class and do all your vector math “by hand” as it were, and not see any real benefit to using structs but you make your life a lot easier when you can just do Position += Direction * Speed

Put it this way, I converted my collision code from Monkey1 which stored vectors using a class. When I changed them to structs instead I saw a significant performance boost.

[peterigzParticipant]

Only other thing I can think of is try rebuilding mx2cc, in ted go Build>Scripts>Rebuild mx2cc. If you pulled the latest version from git I think you need to do that as well as the rebuild mods. Otherwise it’s a bit of an odd one that, maybe an OS issue of somekind?

[peterigzParticipant]

I can recreate this if I use “#include”, instead of “#import”, only works with “#import” (Not sure include exists in monkey2).

Maybe paste or attach the code here?

[peterigzParticipant]

It’s possible something was fixed since v1.0.0 if that code doesn’t work. As Weibow says, either have no namespace at all in each file, or make sure you do have one in each file.

Monkey

Namespace myapp Global myvar:="Hello World"

1 2 3

Namespace myapp   Global myvar:="Hello World"

Monkey

Namespace myapp #import "globals.monkey2" Function Main:Void() Print myvar End

1 2 3 4 5 6 7 8

Namespace myapp   #import "globals.monkey2" Function Main:Void() Print myvar End

[peterigzParticipant]

I’d say you’d get a speed boost although I didn’t use monkey1 much, it does seem to be a fair bit faster than Blitzmax though in my tests. When I was converting my collision code I had a test to see how many polygon collisions could be done in 1 second. Max gave me 1.3mil whereas initially I got 3.7mill in mx2. Then after I optimised it more to use structs and stacks I pushed that up to 5.5mill. That’s one of the things I like about mx2 – the fact that you seem to have more options when it comes to optimising.

As far as rendering goes I doubt there’s much improvement there as I don’t think there’s that much difference between the mojos, but again you’re probably more flexible in what you can do to improve things.

I don’t think there’s a great deal missing other than targets (android, iphone etc), don’t think there’s reflection yet. There’s possibly even a gain to be had in that you get lambdas, function pointers, structs, stacks, plus easier to import external c/c++ libs which correct me if I’m wrong is not in monkey1.

I’d say just go for it, the more people trying it out and reporting issues the better it can get

[peterigzParticipant]

You’re missing the ‘padding’ param. Should implicit enum->bool be disallowed?

Doh! That was the reason, can’t believe I missed that! I should know by now to look for the obvious thing first, thanks

[peterigzParticipant]

I have nice crispy particles again, I found the reason but I’m still a bit confused. I have a function to load a sprite with frames of animation:

Monkey

Function LoadFrames:Image[] (path:String, numFrames:Int, cellWidth:Int, cellHeight:Int, padded:Bool = False, flags:TextureFlags = TextureFlags.Filter|TextureFlags.Mipmap, shader:Shader = Null)

1	Function LoadFrames:Image[] (path:String, numFrames:Int, cellWidth:Int, cellHeight:Int, padded:Bool = False, flags:TextureFlags = TextureFlags.Filter|TextureFlags.Mipmap, shader:Shader = Null)

So if I call that function with:

Monkey

shape.image = tlShape.LoadFrames(url, frames, width, height, flags)

1	shape.image = tlShape.LoadFrames(url, frames, width, height, flags)

Where flags is set to “TextureFlags.Filter” only, it seemed to just go ahead and assign both flags anyway, which is odd, I’m not sure why as it gets overridden properly inside the mojo lib.

So I’ve fixed it to just set one filter by default:

Monkey

Function LoadFrames:Image[] (path:String, numFrames:Int, cellWidth:Int, cellHeight:Int, padded:Bool = False, flags:TextureFlags = TextureFlags.Filter, shader:Shader = Null)

1	Function LoadFrames:Image[] (path:String, numFrames:Int, cellWidth:Int, cellHeight:Int, padded:Bool = False, flags:TextureFlags = TextureFlags.Filter, shader:Shader = Null)

[peterigzParticipant]

I’d like to look at using a texture packer as I’ve always thought standard sprite sheets are a bit inefficient.

I’ve been working more on it today, slowly every effect starts to look as it should looking forward to optimising it with some of the new features in monkey2.

[peterigzParticipant]

Very useful! thanks

[peterigzParticipant]

Thanks Matthew! I’ll give that a go.

[peterigzParticipant]

Looking good. The main thing I don’t like about Ted is the font doesn’t seem very crisp to me, I find it quite hard to read. Is there an easy way to change it? Be nice at some point to have a preferences dialog of some sort.

[peterigzParticipant]

A module manager would be great, especially if they can be accessed within the IDE. I can upload mine if you want, be interesting to see if the docs are working too.

[peterigzParticipant]

I’ll have to try that if it’s quicker. The other method is safe if you need to add and remove things from the list while you’re looping through but only as opposed to using a foreach, so maybe using it directly like that is slightly faster. But then given how exotic the c++ compiler seems to be these days it’s anyone’s guess!

[peterigzParticipant]

This might be a better way of doing it now:

Monkey

Function Main() For Local i:Int = 0 Until 20 Local car := carStore.GetItem() list.AddLast(car) Next Local items:=list.All() While Not items.AtEnd Local link:=items.Current Local storeObject :=Cast<StoreObject>(link) items.Bump() Wend End function

1 2 3 4 5 6 7 8 9 10 11 12 13

Function Main() For Local i:Int = 0 Until 20 Local car := carStore.GetItem() list.AddLast(car) Next Local items:=list.All() While Not items.AtEnd Local link:=items.Current Local storeObject :=Cast<StoreObject>(link) items.Bump() Wend End function

[Author]

Posts