Drawing Thousands of pixels from array

[Borkpaladin]

I am trying to make a simple game where you can draw sand that falls, however when I draw the pixels I am suffering a lot of lag.
Any help would be much appreciated!
(Its fine up until about 500 pixels)

//Paint draw method
int i = 0;
	while(particles[i] != null){
	     if(particles[i].getType().equals("air") == false)
	     particles[i].draw(g2d);
	i++;
}

//Particle draw method
	public void draw(Graphics g2d){
		g2d.setColor(color);
		g2d.fillRect(x, y, 1, 1);
	}

[DarrylBurke]

One optimization that's immediately evident is that you could set the color before the loop, not at every pass through the draw(...) method.

But the real bottleneck here is likely to be the String equality test, and possibly in the getType() method, if it's non-trivial. Why don't you subclass and give the "air" type particles a draw(...) method that does nothing?

Also note that it's never needed to compare a boolean expression with a boolean literal.

// if(particles[i].getType().equals("air") == false)
if(!particles[i].getType().equals("air"))

db

[Borkpaladin]

Thanks, that did help with the lag a little but I found out the lag was mostly coming from my utterly shockingly bad method of moving the particles which involved going through several thousand, thousand iteration long while loops, I am now re-writing it.

[quad64bit]

So another thing:

g2d.fillRect(x, y, 1, 1);

...is extremely slow. It's many many times faster to simply set the color of a BufferedImage directly using setRGB(x, y, rgb);

Once all the drawing is done for a given frame, then just draw the whole buffered image. You're exploring pixel simulations which are very taxing on software based rendering systems (like most of java2d). I have written many, and have found lots of small optimizations like the one above can make a huge difference.

In the end, the single biggest thing that improved performance was to switch to OpenGL. I played with both JOGL and LWJGL and prefer the latter. I had frame rates go from about 10fps (after heavy optimization) to around 190fps when working with around a half million particles.

Another thing that tends to be quite slow depending on what you're doing is collision detection. I was doing some bouncing ball simulations which had a few hundred balls, and the collision detection alone was causing something like 1.5 million checks per second. No matter how well I optimized the detection code, the number of checks was so great that it caused massive lag. The solution there was to implement a QuadTree data structure to hold the balls, and use it to minimize the number of checks (1,500,000 per second to about 235 per second). In other words, I reduced the complexity of the check from O(n^2) to O(log(n)).

Your case probably isn't as bad since you aren't bouncing every grain of sand off of every other grain, but you can reduce the complexity of collision with solid objects by doing targeted detections instead of brute force. Hope this helps!

[lolmister]

Im actually doing something quite like this, and I got a major speedup by not drawing cells that are the same as the last time they were drawn.

[Borkpaladin]

Thanks, using a BufferedImage sped it up considerably and I'm going to have a look at LWJGL, any good tutorial websites that you know of?

[quad64bit]

The LWJGL website itself has some tutorials. I did the space invaders one back in the day. You really only need to know enough to get a 2D canvas and how to draw simple polygons on it. If you can get that far, you can mimic what java2d does, but, it will be hardware accelerated! D

OpenGL is tricky to get started with, so be patient and give it a week of playing around with. Let us know how it works out!