I'm writing a basic game engine in Java, and am now trying to optimise the way I handle images (best to start early, rather than get too dug-in, I think).

Currently, before the game loop starts I load in an image containing all of the tiles I want to use and store it in a BufferedImage object. The image is composed of 32x32 tiles.

Then, at render time, I make a call to a function that draws the level tiles. At present, it's just all floor tiles - but I wanted to see what performance I'd be getting.

When drawing the tiles, I cycle through the tile map - a simple 2D array of objects - and work out whether they'll be in the viewport. If so, I render them using the getSubImage(...) method of the BufferedImage class.

This results in the relevant tiles being drawn on-screen, as per the following image:

In a 1024 x 768 window, roughly 221 tiles are drawn each frame

Incidentally, I know this isn't proper 'blitting', per se, but that leads me on to my question.

I've read reports about people using methods to copy pixels to/from a (static?) resource at render time - boosting draw performance. At the moment, my code seems to run around the 75/76 FPS mark (with a BufferStrategy in place), but I've heard of people managing to take similar projects up into the high hundreds, if not over a thousand FPS by adjusting the way small graphics like this are drawn.

I think it's got something to do with storing a 2D array of pixel data for each image tile, and then creating a new image from that data at runtime? Or am I way off the mark here?

Are there resources online where you can learn these methods? I've tried searching around, but this seems to be a very specific type of drawing method.

I'm not after a code answer, that would be cheating - and obviously wouldn't help me learn anything at all. If I could be pointed in the right direction, or be told what methodology I should consider, I would be most grateful.

Thanks. I think that's what I'm doing now, with the BufferedImage stored in the individual Tile objects?

The tile map is diced up before the game loop actually starts, and each individual tile 'slice' is stored ina BufferedImage for that tile, which is composited from the pixeldata extrapolated from the main tile map image.

Ok, but really, what's the point of copying pixel by pixel ?Use getSubImage() or drawImage() to copy between images.Take a look at GraphicsConfiguration to get images of appropriate formats.And if you dont want to modify your sub images separately, you don't even need them at all.I love optimizing

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.

DO NOT use setRGB or modify pixel data directly! That makes the BufferedImage unmanaged and it will not be accelerated by the graphics card. The fastest way is to cut everything up into a 2D array using getSubimage like the others posted.

Perhaps I should explain my reasons before I get shot down on this one

I'm using setRGB because I'm storing two versions of the same image. One which is an exact 1:1 pixel copy, and one which is slightly red-shifted to use as a 'pain' image.

I have read before about the arguments for staying away from unmanaged image objects, but if we're talking about, say 10 or 20 32-pixel images at the most - is it really going to have a massive impact on hardware acceleration?

Let's just assume for a moment I were to change the way I split the images up from the tile map (forget about the palette shifting for now). Would using a normal BufferedImage[][] array set remain hardware accelerated if I simply fill it with images returned from a getSubImage(...) call?

The impact it has on hardware acceleration is that you don't get any at all. The size of the image is not all that material, it's the unoptimized memory accesses and copies it has to do, and how many times you do them. getSubImage gives you managed images, so if you use only that you're fine.

Should I be looking at Volatile Images instead, then, as suggested earlier on in this thread?

If I'm honest, I'm not sure of the pros / cons of using them over the BufferedImage class. I know at least that BufferedImage provides all those handy manipulation methods, but unsure if Volatile is essentially the same thing?

I've been getting conflicting answers as to whether getSubImage returns a managed image or not, but it seems to be that getSubImage does indeed return an unmanaged image. Creating a new image and drawing into it appears to be the proper way to go. As performance tuning advice goes, "don't listen to sproingie" is probably a good place to start

I've been getting conflicting answers as to whether getSubImage returns a managed image or not, but it seems to be that getSubImage does indeed return an unmanaged image. Creating a new image and drawing into it appears to be the proper way to go. As performance tuning advice goes, "don't listen to sproingie" is probably a good place to start

Well its not documented D=

Seriously for simple 2D stuff, just use Slickyou never know when an image is accelerated, without really trying to find out, and slicks API is basically java2D

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org