Slick2D Most efficient way to draw a pixel array

[DDDBOMBER]

I have a int[] cols, and want to draw that in a grid across the screen, I currently have each color fill a 4x4 area, but I want to have it 1 pixel instead of 4. Doing that seems to cause tremendous lag. I am looking for a better way to do this.

1   2   3   4   5   6   7   8   9   10   11   12

public void renderTiles(Graphics g, int xScroll, int yScroll, int width, int height){       for(int x = -1; x < width; x++){          for(int y = -1; y < height; y++){             int xt = (x+xScroll/tileSize)%size;             int yt = (y+yScroll/tileSize)%size;             if(xt < 0)xt += size;             if(yt < 0)yt += size;             g.setColor(new Color(tiles[xt+yt*size]));             g.fillRect(x*tileSize-xScroll%tileSize, y*tileSize-yScroll%tileSize, tileSize, tileSize);          }       }    }

[jonjava]

Hmm, why don't you just stretch the image into 4 times its size?

1	g.drawImage( image, 0, 0, width * 4, height * 4, null );

[DDDBOMBER]

There isn't actually an image, I'm using it for the background and the cars are leaving tracks in it, so the array is constantly changing

Games published by our own members! Check 'em out!

[jonjava]

If you have a pixel array, you've got an image.

You're not using 'int[] cols' in your code. Is it actually called int[] tiles?

1   2

BufferedImage bimg = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB); int[] tiles = ((DataBufferInt)bimg.getRaster().getDataBuffer()).getData();

Now changes made to int[] tiles will be reflected in the BufferedImage.

Or you could copy them into another BufferedImage whenever int[] tiles changes.

1   2

BufferedImage bimg = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB); bimg.setRGB(0, 0, width, height, tiles, 0, width);

[davedes]

jonjava - he says he is using Slick2D, not Java2D.

In OpenGL you generally don't modify texture data per-pixel in real time; instead, you modify pixels as they are rasterized by GL. The former requires copying data between CPU and GPU (very slow), whereas the latter is done all on GPU (very fast).

Instead of modifying textures per-pixel, you might get faster speeds by drawing rectangles. The problem is that Slick doesn't batch calls to g.fillRect, so using it many times per frame can create a bottleneck. Instead, you might have better luck with using an Image to create an opaque coloured rectangle. So it might look like this:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25

//pack a small opaque white area into your sprite sheet, //e.g. 1x1 white pixel with nearest filtering //or a larger area with bilinear filtering //get the sub-image of the white pixel Image whitePixel = spriteSheet.getSubImage(...); ... //now in your render loop, draw many rectangles like so: spriteSheet.startUse(); //... draw your other sprites from this sheet using drawEmbedded ... // //now bind the color you want your filled rectangles to be, e.g. black or whatever rectColor.bind(); for ( each filled rectangle ) {     //draw the filled rectangle    whitePixel.drawEmbedded(x, y, width, height); } //end the sprite sheet spriteSheet.endUse();

I also described the technique here (for a different library):
https://github.com/mattdesl/lwjgl-basics/wiki/Batching-Rectangles-and-Lines

For more info on drawEmbedded:
http://slick.cokeandcode.com/wiki/doku.php?id=performance_memory_tips

If you want to try modifying a texture per-pixel (and deal with the performance problems of copying data from CPU to GPU), check out this page:
http://slick.cokeandcode.com/wiki/doku.php?id=per-pixel_manipulation:pixeldata_utility

If you are more interested in the GPU approach, you might have some luck from shaders:
http://slick.cokeandcode.com/wiki/doku.php?id=shaders
https://github.com/mattdesl/lwjgl-basics/wiki/Shaders

[DDDBOMBER]

Thanks very much, your method is a lot faster than what I was doing, I am going to look into shaders as they would probably be the most efficient. I still get a bit of lag when alot of the screen has been changed.