Faster tile creation

[weston]

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:

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

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);       }     }   }

[oNyx]

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

drawImage

[weston]

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

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

[dranonymous]

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.

[Abuse]

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.

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.

[pepe]

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.

[weston]

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 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...