2DGraphics PixelArray vs G2d.drawImage(...)..

Java 2D
#1

Ok, so i’m just starting to finish my GFx API in my game and I’ve watched some tutorials where people add every entity into the games Pixel array instead of just doing g2d.draw(image,x,y) to a Canvas, they instead do pixel raster to images. Is this really needed or is G2D.draw(bufferedimages) suffice for mediocre game. My game art style is a 2D sidescroller like type gamerpg such as Dungeon Fighter online etc.

My question is, what benefits are there to using pixel arrays? Is this needed for my type of game? Also is this easy to integrate?

Thanks in advance,
Tipshat
Jay

#2

Maybe they dynamically apply graphic effects.
Besides that, its only useful for slowing down things drastically.
So, if you just want to render static images, use draw().

#3

Isn’t every image basically just wrapped up RGB pixel data anyway? I don’t see why one method should be faster than the other.

#4

There are managed images and unmanaged images in Java2D.
Fast vs. slow.
Pixel juggling is probably the second category.
Do a research on that. As far as I know, it even depends on your platform.

But luckily, pure image rendering is pretty fast in Java2D.

#5

As far as i can remember, when notch made minicraft as a 320x240 game using a pixel array, it got around 2200 fps on the prototype
Then he added 2ms sleep between iterations and got 400 fps, which never came down, even on the finished game.

#6

Thanks for the responses, I mean is there one that is more professional than another? Do you all just use Draw when making a game, is it acceptable for an app? Does one get higher fps than another? I just really want to make sure before I put the cap on my game’s graphical capabilities =D

#7

I would say that with PixelArrays you could do some some effects to certain areas of the rendering. You know…things like bloom filter and stuff but it is very slow compared to just static 2D rendering.

g2d.drawImage is very fast and I have not done tests but I think it is faster then a PixelArray. I mean with a few tests with a bloom/glow filtering system (not at all optimized) you would be looking at a max resolution of about 200-300 pixels. Java was not designed to have dynamic access to pixels that way.

So unless you need to access the pixel information before or after somethings is drawn, g2d.drawImage should be fine.

#8

I certainly hope not. Its a 2D game that doesn’t even do that much on screen.

#9

The answer is, it’s complicated. It depends a lot on what you want to do with the pixels and such, and what you’re doing with your graphics. I’d take a stab and guess that you can probably just use g2d.drawImage(), but the simplest thing is to start with that and see if things run to slow for your tastes. If they do, then profile and see where the problem is, it might be somewhere other than drawing.

But for a bit of background, basically images can be in tons of different formats, and the image classes hide a lot of that complication from you. If the format of your image doesn’t match the format of your graphics device, then every time you draw the image the code under the covers does a lot of work converting each pixel in your image to the graphic device format. On the other hand this code is usually written pretty well and they can take advantage of lots of other stuff like caching images inside the graphics card, etc. Conceivably (a little bit of a guess here, as I don’t muck around that deep in this kind of code) a call to drawImage() might be converted into a call across to the memory card, and use hardware to blit an image from one part of the graphic card memory into another part of the graphic card memory, very very quickly.

On the OTHER hand, if you know exactly what format your image or images are in and you know exactly what format you want to write it to, you can get at the underlying data structures (i.e. DataBuffers) and just munge the numbers yourself. Unfortunately once you ask Java to get at that data, all that magical code the sun guys wrote way back when can’t rely on you not pulling the rug out from under them, i.e. they mark that image as “do not cache on the graphics card, ever”, because they have no way of knowing if you wrote to that underlying big honking array of pixels. So now while you can do a lot of manipulations on the pixels a lot quicker, you can’t take advantage of whatever hardware acceleration might be going on, or whatever other goodness the sun guys wrote under the covers.

Make sense? The real answer is that it greatly depends on what you’re doing. Mind you there are a lot of things you can do to make things faster without mucking around with the pixels and messing up acceleration.

Among other things make sure that you create the BufferedImage that you’re drawing too by calling createCompatibleImage on GraphicsConfiguration. This will hopefully avoid a having to convert all the pixels of the image you’re drawing to the screen from one format to another, each and every time you draw.

Overall I suggest you start with that, and if things are too slow ABOVE ALL PROFILE your code because the slow part may very well not be in drawing to the screen. If you find it is the drawing that slows things down then do more research on the web.

Finally I leave you with the three Rules Of Optimization

  1. Don’t do it
  2. Don’t do it yet
  3. Profile
#10

It’s just a tradeoff between more control over the rendering process and ease of use.

I’m with seanrowens, get the program running first, and only then optimize.