Submissions from 2015-07-26 to 2015-07-27 (3 total)

So I did some quick optimization work on the exploding sprites algorithm. One of the very noticeable problems was the delay during the initial and last frame of the explosion or combination. The delay came when the PC had to write a large amount of objects to and from arrays. By introducing a random delay to the algorithm I made it so that all the pixels don't arrive at their destination at the same time so the array writes are spread out over multiple CPU cycles instead of all at once. It removed the delay at the end. I'm leaving the slight delay at the explosion because I think it is worth it to have them all go at once.

I have a couple problems to solve:

  1. What do I do if I try to assemble a sprite and there aren't enough pixels floating?
  2. How can I keep the total number of pixels down? Even with large sprites?
I'm thinking that allowing the pixles to change size might be a solution to both problems. Large sprites might break into large pixel objects and small pixles might get larger to fill in more area on larger sprites. Not sure how it will work though.