Creating a non-vanishing trail effect

Hey all, I am working on a game that involves an object that leaves a trail behind it as it moves around the screen. Think of it like a paint brush moving across the screen and leaving paint, or a pen moving around and drawing a line. Whatever system I use such as Particle Candy or writing something myself, all objects/particles must remain on the screen.

I’ve done a few preliminary tests where I monitor if the object is moving, and if it is, depositing simple circle shapes (small like 5px) in its wake… Unfortunately the processor severely slows at about 200-300 particles deposited.

Any thoughts or recommendations? Thanks in advance!

Nate [import]uid: 131038 topic_id: 24651 reply_id: 324651[/import]

It’s not great to be creating a lot of objects and leaving them around, but I don’t think you need anything advanced for that. Just measure the distance between the last one and the current touch or object position and place a new one if it is over a certain length. I should think you’re putting too many on the screen at the moment, perhaps three or four directly on top of each other? [import]uid: 8271 topic_id: 24651 reply_id: 99875[/import]

Since i don’t know how exactly your game works I’ll give you a demo of a way that wont screw with your memory usage.

local trail = {}  
i = 0  
  
function spawnTrail( event )  
 if(character.x \< character.x + 10) then  
 i = i + 1  
 trail[i] = display.newCircle( character.x-10, character.y, 5 )  
 trail[i]:setFillColor( 0, 0, 0 )  
 end  
 if( i \> 50 ) then  
 trail[i-49]:removeSelf()  
 trail[i-49] = nil  
 end  
end  
  
Runtime:addEventListener( "enterFrame", spawnTrail )  

It will use memory to spawn 50 circles if you need your trail to be that long, but after that it wont use any additional memory since it will be deleting the old trail. Hope this helps, let me know if you need a better explanation or help [import]uid: 77199 topic_id: 24651 reply_id: 99992[/import]

Thank you both for your help - I have tried a solution where I’m measuring the distance and placing less trails, but there does still seem to be a performance hit when trail count reaches a certain level. Seems like I’m gonna need to have a hybrid approach between measuring distance and phasing out old trail particles… [import]uid: 131038 topic_id: 24651 reply_id: 100083[/import]

I’d like to know more details about what you’re trying to do with these particles.

However, in lieu of that, there is another option. Assuming you don’t need to affect individual particles a lot later, you could make sure you’re painting them to the same display group. At some given time, perhaps when no user touch event is occurring, you save the group to a single image and replace it with that group.

That way, you suddenly drop from 200 images to 1. I don’t know how smooth the save/replace would be - but Ansca recently updated the display functions to avoid saving the image to disc first.

The only thing which would possibly stop this is if you’re expecting 200+ images to be painted before the touch ‘ended’ event, at which point, yes, start killing them sooner. [import]uid: 8271 topic_id: 24651 reply_id: 100086[/import]

I really like that idea… actually thought of the possibility of that but wasn’t sure how quick it would be… Have you tried this before?

Ultimately I am trying to keep a visual “trail” of every place that an object goes around the screen. Ultimately, I’d love it if they didn’t have to fade out, or if I didn’t have to limit them. I do have an event where I “reset” the object that is depositing the trail - this could be an excellent opportunity to do the image capture/replace…

I assume you are referring to this? http://blog.anscamobile.com/2012/03/taking-snapshots-of-objects-and-groups/

If this works, that would be most excellent! Thanks much for the tip! [import]uid: 131038 topic_id: 24651 reply_id: 100139[/import]

And… it worked! Thanks again for the suggestion.

There is about a 500 msec freeze when it’s taking the snapshot which pretty much halts the physics engine altogether. However, the benefits of going this route far outweigh the limitations of not…

I am going to create a realistic “pause” when I can create the duplicate and wait for it, then continue on.
[import]uid: 131038 topic_id: 24651 reply_id: 100151[/import]