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?

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 prototypeThen he added 2ms sleep between iterations and got 400 fps, which never came down, even on the finished game.

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

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.

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.

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