Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat
How to stop a coroutine? - Gideros Forum

How to stop a coroutine?

Hi I am trying to handle animations through coroutines:
I successfully did something, but I was wondering if it's possible to stop a coroutine from the outside.

Assuming a code similar to this one from @Apollo14
local rooster=Bitmap.new(rooster_tpack:getTextureRegion("rooster_1.png"))
stage:addChild(rooster)
 
function rooster:run()
	for i=1,17 do
		rooster:setTextureRegion(rooster_tpack:getTextureRegion("rooster_"..i..".png"))
		Core.yield(true) --we can set delay Core.yield(.02) for example
	end
	rooster:run() --repeat again after one cycle of animation finished
end
 
Core.asyncCall(rooster.run)
can we stop "on call" (ie. on mouse down) Core.asyncCall(rooster.run)?
I thought of inserting a condition to make the function return/break, but I haven't got the time to test it yet:
function rooster:run()
	for i=1,17 do
		rooster:setTextureRegion(rooster_tpack:getTextureRegion("rooster_"..i..".png"))
		Core.yield(true) --we can set delay Core.yield(.02) for example
	end
        if stoprooster then
            return
        else
	    rooster:run() --repeat again after one cycle of animation finished
        end
end
Is there a better way to do it?

Thank you

Comments

  • antixantix Member
    Is this method actually more efficient than a purely frame based one?
  • hgy29hgy29 Maintainer
    Yes, use a variable to break the loop.
  • piepie Member
    edited January 19
    Thank you, that should stop its resource consumption completely or do I have to annihilate its reference/collect garbage?

    @antix I don't have real proof to show yet, but I think it looks pretty awesome: in windows player I placed 500 instances of a 7 frame animation (two different animations sharing the same 30x30 textures) without lags at 60fps.
    I don't know how would it perform in a real world though :)
    I'll keep you posted, if this works I think I will share it
  • Apollo14Apollo14 Member
    edited January 19
    btw 'getTextureRegion' calls are unnecessary
    (but I guess you already skipped them in your real project)
    --rooster:setTextureRegion(rooster_tpack:getTextureRegion("rooster_"..i..".png"))
    rooster:setTextureRegion(preloadedTextureRegionsArray[i])
    > Newcomers roadmap: from where to start learning Gideros
    "What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
    “They did not know it was impossible so they did it” - Mark Twain
  • antixantix Member
    @Apollo14, interesting. I should do some testing but I'm too lazy heheh. I've found that getTextureRegion() is pretty quick, but I suppose if there was some code to prefetch texture regions it would be a faster solution, albeit marginally.

    I'd still like to know if the async method is better than an EnterFrame event method.
  • piepie Member
    I'm wondering if preloading all textures won't be counterproductive in terms of resource consumption: we use most only a portion of the texturepack (ie player moving vs player dying).
    Preloading all the textures that we may need later would not keep some memory busy?
  • antixantix Member
    Well if you load a TexturePack it has a table of all of the TextureRegions as well. When you call 'getTextureRegion() I'm assuming it is just finding the specific region for the named png file and returns that.

    This will be quite quick and pre caching them yourself will be quicker as well, but I don;t think the performance gain would be significant unless you managed to get thousands of objects on screen at once.
  • piepie Member
    I tried, and I'd say you're right it's pretty much the same:
    maybe precaching looks worse, because there is a small delay while it is creating all the instances.

    I have a prototype which can precache textures or not: can you suggest how to benchmark it "for real"? :)

    paying attention to the fps shown in my windows player I'd say
    1500 instances of the same animation
    no precache: 58-60 fps
    precache: 59-61 fps, showing a delay at the beginning, down to 45 fps

    Reading the profiler outputs confuse me a bit, I attach them here if someone can read those better than me

    thank you
    rar
    rar
    AnotherMovieClip_profiler.rar
    6K
  • Apollo14Apollo14 Member
    edited January 23
    Hey guys!
    I've tested 'getTextureRegion' vs 'pre-loaded value', attached gproj and profiler results.
    If I understood Profiler correctly, pre-loaded values are 8-10x faster than getTextureRegion (383ms vs 4663ms).
    (@pie I guess it's not 'texture pre-caching', it's only values pre-caching)

    but I'm not sure if I understood profiler correctly, you'd better check it
    and there will be no difference in the real projects anyway, cause we never need to load huge amounts of such values so frequently :#
    local rooster_texturepack = TexturePack.new("rooster_spritesheet.txt", "rooster_spritesheet.png", true)
     
    local roosterTexturesArr={
    	rooster_texturepack:getTextureRegion("rooster_00.png"),
    	rooster_texturepack:getTextureRegion("rooster_01.png"),
    	rooster_texturepack:getTextureRegion("rooster_02.png"),
    	rooster_texturepack:getTextureRegion("rooster_03.png"),
    	rooster_texturepack:getTextureRegion("rooster_04.png"),
    	rooster_texturepack:getTextureRegion("rooster_05.png"),
    	rooster_texturepack:getTextureRegion("rooster_06.png"),
    	rooster_texturepack:getTextureRegion("rooster_07.png"),
    	rooster_texturepack:getTextureRegion("rooster_08.png"),
    	rooster_texturepack:getTextureRegion("rooster_09.png"),
    	rooster_texturepack:getTextureRegion("rooster_10.png"),
    	rooster_texturepack:getTextureRegion("rooster_11.png"),
    	rooster_texturepack:getTextureRegion("rooster_12.png"),
    	rooster_texturepack:getTextureRegion("rooster_13.png"),
    	rooster_texturepack:getTextureRegion("rooster_14.png"),
    	rooster_texturepack:getTextureRegion("rooster_15.png"),
    	rooster_texturepack:getTextureRegion("rooster_16.png")
    }
     
    iterations@100000
     
    local function bench1()
    	local rooster=Bitmap.new(rooster_texturepack:getTextureRegion("rooster_00.png"),true)
     
    	for i=1,iterations do
    		for j=10,16 do
    			rooster:setTextureRegion(roosterTexturesArr[j])
    		end
    	end
     
    	print "bench1 finished"
    end
     
    local function bench2()
    	local rooster=Bitmap.new(rooster_texturepack:getTextureRegion("rooster_00.png"),true)
     
    	for i=1,iterations do
    		for j=10,16 do
    			rooster:setTextureRegion(rooster_texturepack:getTextureRegion("rooster_"..j..".png"))
    		end
    	end
     
    	print "bench2 finished"
    end
     
    bench1()
    bench2()

    Likes: pie, SinisterSoft

    zip
    zip
    bench_getTextureRegion.zip
    159K
    > Newcomers roadmap: from where to start learning Gideros
    "What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
    “They did not know it was impossible so they did it” - Mark Twain
    +1 -1 (+2 / -0 ) Share on Facebook
  • antixantix Member
    edited January 23
    @Apollo14 interesting, I wouldn't have thought that getTextureRegion would be so slow, maybe I should retro-fit my animator class to cache these when it starts.

    However for a small number of actors (say 200-500) the gain would maybe not be worth the time to code the changes :D

    Likes: Apollo14

    +1 -1 (+1 / -0 ) Share on Facebook
  • Anything that has to call the 'C side' will have the bottleneck of 'calling c' but the speed of the C side once you get there.

    Likes: Apollo14, antix

    +1 -1 (+2 / -0 ) Share on Facebook
Sign In or Register to comment.