Another Movie Clip

pie

Hi, this is Another Movie Clip for Gideros:
featuring texture switching, coroutines and TNT Animator compatible.

Here you can find the latest update.

I had to encapsulate the whole thing into a Sprite because I needed setScale to flip frames.

What do you think?
Do you see any chance of optmization?

If someone wants to benchmark it, I am not sure on how to do it scientifically..

Thank you

Apollo14

Awesome!
p.s. I see tiny optimization options, but they won't make difference, I'd not even call it 'optimization'.
I guess experienced folks can find something more fundamental

local function generateCoins(n) local mathRandom=math.random --localizing for i = 1, n do animpool = {"COIN_ROTATE","COIN_ROTATE_SLOW"} --add animation coins[i]= aMovieClip.new(c_tpack, animations, animpool[math.random(2)], "play") coins[i]:setPosition(mathRandom(10,470),mathRandom(10,790)) coins[i]:setColorTransform(mathRandom(),mathRandom(),mathRandom())

Line 177 in AMC.lua:

--self.amc_loopcounter = self.amc_loopcounter+1 self.amc_loopcounter+=1

SinisterSoft

@pie 2018.12 should have the modified version of Lua - we have been using it for ages.

pie

@SinisterSoft I'm sorry it was my fault: it was late and I wasn't paying attention to the position of the white space..

Attached the last release of anotherMovieClip, with usage examples and TNT Animator Studio by @GregBUG: mac version of TNT Animator Studio should be available in TNT Animator package: get it here http://www.tntparticlesengine.com/?cat=14

AMC 0.3 is capable of playing TNT Animator Studio .tan files through realtime conversion: obviously it would waste some resource to convert the XML files at creation time.

I've kept the option to precache texture regions or not, it all depends on how the animations table is written. This is to maintain the possibility to use AMC as a "simple MovieClip" writing the animation directly in lua.

Attached you will also find tntTOamc: a standalone win32 converter for TNT tan files, that translates the animations to a Json format readable by anotherMovieClip
(split in 2 parts because the forum allows me to upload only 2Mb per file)

If you are bothered by real time conversion and want to keep everything "lighter" (json files are smaller than xml files, and their conversion to lua table is really fast) go for this conversion option. You may also remove half of the code in AMC.lua (the conversion part).
However, you will also need the JSON plugin in your project to load json files.


If you spot bugs or optimization chances, please let me know.

I'm starting to use it today, so it has to be considered "beta", maybe "release candidate", I didn't test it thoroughly yet.

Quick reference is at the beginning of AMC.lua

Apollo14

wow, combined with TNT Animator, it's becoming totally cool and awesome! many thanks!!

pie

@Apollo14 it is awesome indeed! I couldn't have done it without your example, hgy29 and sinistersoft improvements to gideros, gregbug, and hints from many people around here
I am just returning a bit to the community
thanks to you all!

SinisterSoft

You should add it to the core as a LuaPlugin...

pie

@SinisterSoft how?

SinisterSoft

I'm not exactly sure - @hgy29 may know of an example.

antix

@pie pretty cool man. In this function the variable in the error message doesn't exist

function aMovieClip:setAnimationSpeed(speed) if speed > 0 then self:amc_callback("ANIM_SPEED_CHANGE") self.amc_animations[self.amc_state.currentAnim].speed = speed else print("!!AMC WARNING!! Animation Speed:", animation_name, "speed can't be 0" ) end end

I'd really like to know if this will be faster than a frame based solution using EnterFrame event. I wonder how much overhead all the thread yielding and stuff has.

I like the TextureRegion caching and think you should just make it cache them all the time, not make it optional if it's faster performance

pie

@antix whoops thanks, I will fix it asap. I've seen at least another bug that needs to be fixed on setAnimation and another one in stopOnFrame.. I hope I can get my hands on it in the weekend.
Many more bugs could come out as I switch a couple of existing projects from tnt animator to amc..

I think that the attached project is a good starting point to evaluate the performance: just place as many crocks as you like and see how it is performing: it seems pretty good to me.
Do you have an already working enterframe based animation system to compare values?


However I don't think there is much overhead: the basics should be pretty much the same thing (loading textures and switching them) but we save a lot on enterframe events / function calls.
Amcloop is just a local function that calls itself: doesn't need to listen to any event.

The reason to keep precaching as an option is that we could easily write frames by hand (like we did in standard MovieClip) in the end it's just a couple of conditions that shouldn't affect the overall performance.
It's good for prototyping.

If you can think of a better way to benchmark than reading player osd info with loads of actors, please let me know

Thank you

antix

I have some code I can use to compare which is an advanced version of something I posted here on the forums some time ago. Basically it has one instance called Animator and you call it's methods to attach animations to actors, animate them, etc.

I think however if I was going to test I'd just be using some cutdown version of each thing because you don't really need to do any graphics stuff as they would run at the same speed in each thing. The purpose would be to see which method worked faster, core yielding or enterframe.

Maybe I'll play with this later today

EDIT: Okay I just started messing with this and I see the yielding method uses Core.asyncCall() which the documentation says creates a new thread. How many threads can Gideros have?

pie

@antix I'm not sure, but I think that there is virtually no limit since we're using fake threads
http://forum.giderosmobile.com/discussion/comment/57637/#Comment_57637

antix

@pie, I see. I think there might be some performance hit at large numbers? I mean every different thing has a CPU overhead, I wonder what fake threads have, as there has to be something working in the background to manage them.

pie

More than their overhead I am worried by the "control" we have on them: since we can stop them only using a break or return, if they are waiting in a queue to be processed, we won't have a synchronous response - which - speaking of animations may be crucial.
Using AMC a bit extensively in a real time game, I noticed that there is a delay switching animations, due to the fact that any change in parameters has to wait for its turn in the queue. Things are better if yielding very fast, but I have to think of a trick to slow down frame switching.

@hgy29 would it be possible to add a control to stop asyncCall on call?

hgy29

@pie, you are guaranteed that each async task will be given a cpu slice at least once per frame, and since the task itself can decide when to yield, returning from the function when appropriate is easy and clean

pie

Release of AnotherMovieClip 0.5.
Fixed some bugs here and there and improved with "pause" control.
hgy29 you were right, shame on me

pie

Release of AnotherMovieClip 0.6
-Rewritten amcloop without "for" loop
-now it's possible to start animation from # frame
-better "pause" control

Like before, if you spot any bug or optimization chance, please let me know

talis

@pie thanks again, really appreciated.

pie

Release of AnotherMovieClip 0.7
remixed it a bit: it seems to work better in my old projects