Faster tile creation

Java 2D
#1

I’m writing a game framework that I will use for making java2D games (I will do an jogl or lwjgl version later, havn’t decided which yet), and for tiled games I use all the tiles for a given location from a single image (rm2k chipsets actualy). Right now I am breaking this image into pieces when the level is loaded and storing all the tile images in a BufferedImage[][], this allows me to draw my maps plenty fast, but it takes a bit too much time to do the breaking it into tiles part. Is there a way where I can get similar rendering speeds without such a big load time? here is my code for breaking the image into tiles:


private void createTileImages()
  {
    Graphics2D g2;
    GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
    for (int row = 0; row < tileImages.length; row++) 
    {
      for (int col = 0; col < tileImages[row].length; col++) 
      {
        tileImages[row][col] = gc.createCompatibleImage(Game.TILE_WIDTH, Game.GAME_HEIGHT, Transparency.BITMASK);
        g2 = tileImages[row][col].createGraphics();
        g2.drawImage(image, 0-col*Game.TILE_WIDTH, 0-row*Game.TILE_HEIGHT, null);
      }
    }
  }
#2

You draw the whole image each time. The version of drawImage which takes a target and a source rect should be somewhat faster.

drawImage

#3

Ok, I’ll give that a try and see how it does. Tommorow I’m Leaving to New York for 10 days ;D so I won’t be responding about the results any time soon :(.

#4

oNyx - Why is the other drawImage slightly faster? I looked at the javadoc between the different methods and it doesn’t seem to mention anything about it being faster.

#5

[quote]oNyx - Why is the other drawImage slightly faster? I looked at the javadoc between the different methods and it doesn’t seem to mention anything about it being faster.
[/quote]
I would presume because that method is manually specifying the clip rectangle, where as your method requires the API to work it out for itself.

I wouldn’t expect the difference between the two to be large however. (a few extra if’s per image draw, thats all)

btw, why are you breaking the source image into tiles anyway?
I would imagine rendering 100s of different tiles should be slower than rendering many different portions of the same image.

#6

afair, Trembovetski said one time that using getSubimage(int x, int y, int w, int h) on a BufferedImage would return an object pointing on the same source data.
I expect that to be way faster to draw under GL pipeline (no texture switching) but i think it might also help actually.
Moreover, it would reduce memory consumption, fragmentation in ram and vram, and would give almost non perceptible tile creation time.
Worth a try, imho.

#7

whether I draw hundreds of diferent tiles or different areas of a single source image, I’m still drawing 16x16 pixels so I thought the speed would be the same… that doesn’t mean I think thats the best way of doing it though, thats why I was looking for a new way ;D Sounds like the alternate draw method or getSubImage() could work well, sad I won’t be able to try for 10 days though, I’m leaving in about 15 minutes…