Hardcore Particles

programming
1

Hey, a recent post on the forums got me thinking about particles and bitmapData. Now ive never attempted anything like this before so what i am going to show you may blind you with my hideous ideas + code, but basicly ive used the same principles as Sirsian’s Bunny code.

Anyway tbh, it has come out pretty well… but i can do about 300 particles before it chugs and i have seen 10000 particles running smooth, so my code obviously has flaws. Can someone explain to me where im going wrong and what i should be doing!? :party:

Below is a rar with all the files!!

Ty in advance guys!

2

[quote=Krabex;2353483]Hey, a recent post on the forums got me thinking about particles and bitmapData. Now ive never attempted anything like this before so what i am going to show you may blind you with my hideous ideas + code, but basicly ive used the same principles as Sirsian’s Bunny code.

Anyway tbh, it has come out pretty well… but i can do about 300 particles before it chugs and i have seen 10000 particles running smooth, so my code obviously has flaws. Can someone explain to me where im going wrong and what i should be doing!? :party:

Below is a rar with all the files!!

Ty in advance guys![/quote]

Argh, I can’t open it with flash8, I guess it’s AS3.0? By looking at the classes I immidiately notice two things:

One, why do you have a pCount? If you push every particle in an array simply use pArray.Length. This is a bit more dynamic. This will not necessarily speed things up though.

Two, why do you create a new Rectangle when you’re rendering? This very slow since you do this for every particle every time it is rendered. If you have different sizes of particles atleast just save it in the constructor. Even better would be to reference it to 1 rectangle. I’m pretty sure doing this will speed things up significantly.

EDIT:

You’re also using memory with saving the xSpeed and ySpeed, even the gravity shouldn’t be a local variable. I still don’t think this is what’s causing the huge *** difference though. But I’ll keep looking :stuck_out_tongue:

Again, save rectangles if they’re not changing (in the render method of Emitter.as). I’m not sure what screen.fillRect and screen.applyFilter does but I’m pretty sure blur WILL take a lot of memory. Try it without the filters it’s atleast worth a shot.

Also, you’re particles are 4x4 = 16 pixels. The examples you talked about might have 1 pixel particles. Which means they wouldn’t even have to use copyPixels but rather .setPixel(x, y, color). Which could be a freaking lot faster. That might actually explain a lot xD

3

Some good ideas there, i will take into account what you have said… thanks :slight_smile:

4

One, why do you have a pCount? If you push every particle in an array simply use pArray.Length

important to notice that you should never loop something like this;

for (var i:int = 0; i < pArray.length; i++) {
};

didn’t check the file, sorry. Bit lazy.

I posted a particle experiment on my blog, feel free to download the source and check it out.

5

[quote=sekasi;2353712]important to notice that you should never loop something like this;

for (var i:int = 0; i < pArray.length; i++) {
};[/quote]

And why is that?

6

Because it recounts the number of elements in the array every time it is called which is slower than just counting once and storing the value in a variable.

7 

var len:Number = pArray.length;
for ( var i:int = 0; i < len; i++) {

}
8

Hmm I suppose that’s true, I thought of that actually, but I thought there was a better answer to be honest. I mostly have arrays that are not static. And I can’t believe McGuffin’s code is faster, quite the opposite actually.

9

[QUOTE=ArmoredSandwich;2353783]Hmm I suppose that’s true, I thought of that actually, but I thought there was a better answer to be honest. I mostly have arrays that are not static. And I can’t believe McGuffin’s code is faster, quite the opposite actually.[/QUOTE]

That seems a strange assumption. The idea behind declaring a variable is that it will remain constant, using pArray.length inside of the FOR loop declaration means that every time the FOR loop goes through, it needs to recheck the pArray.length property to see if it changed during a previous loop.

10

[QUOTE=ArmoredSandwich;2353783]Hmm I suppose that’s true, I thought of that actually, but I thought there was a better answer to be honest. I mostly have arrays that are not static. And I can’t believe McGuffin’s code is faster, quite the opposite actually.[/QUOTE]Well, it is.

11

[QUOTE=ArmoredSandwich;2353783]Hmm I suppose that’s true, I thought of that actually, but I thought there was a better answer to be honest. I mostly have arrays that are not static. And I can’t believe McGuffin’s code is faster, quite the opposite actually.[/QUOTE]

It’s not only faster, it’s exponentially faster.

12

I believe you guys, of course I do :stuck_out_tongue: I guess I’ll run some benchmark tests to see how big the difference is.

13

Yes back to topic at hand :m:, i redid my code but with set pixel and some other little tweaks, now i can spawn 2000 particles at a time without any lag, but any higher and fps drops dramaticly.

Any other techniques i can try to really get the most out of this ? :hat:

14

attach your new code, I’ll try and see if I’m able to improve anything (prolly not! :P)

15

Ty alot :slight_smile:

Here ya go!

16

in emitter.as;

Change update and render to this;


	public function update():Void
	{
		var p:Number = pArray.length;
		for (var i = 0; i < p; i++)
		{
			pArray*.update();
		}
	}
	public function render():Void
	{
		world.copyPixels(clean,sourceRect,destPoint);
		var p:Number = pArray.length;
		for (var i = 0; i < p; i++)
		{
			pArray*.render(world,pColour);
		}		
	}

I’m not quite sure what to do apart from that… the way you are doing this is to have a huge bigmap covering the screen and setting a pixel in a position in it etc… so flash has to redraw that huge bitmap each tic. I think a more moderate approach would be to use a 1x1 object and move that instead.

At least that’s my approach when I play with particles, but I code mostly in AS3 nowadays… :x

17

Above is exactly what I thought would be slower instead of faster. You still calculate the length of the array each time and even worse you have a variable for it. This is what I meant with McGuffin code being worse.

I just figured you manually assign a variable for length, in the constructor: once.

18

[QUOTE=ArmoredSandwich;2354068]Above is exactly what I thought would be slower instead of faster. You still calculate the length of the array each time and even worse you have a variable for it.[/QUOTE]Not in each iteration of the loop though.

19

Ooooooh!! That’s what you guys mean… OMG?? Never mind me guys :frowning:

:ponder::ponder::ponder::ponder::ponder::ponder::ponder::ponder::ponder::ponder:

Sorry, I’m pretty ashamed right now. But thanks for keeping patient :open_mouth: How could I not see that??

20

Noone knows everything.

Except Senocular. :confused: