How do you guys work with graphics?

[Seecon]

I've been looking in to writing a game ... I know a bit of java .. hopefully enough for a basic game and I'm wondering how you all go about using images or sprites for your game? do you use the Graphics class.. or Graphics2D, or what..? Thanks.

[giacobua]

I use jogl

[Alan_W]

It depends on the type of game.

For a 2D game that uses sprites and tiles, you can use the Graphics class in most cases.  You will need to draw on one buffer, whilst displaying a second buffer and then swap them over every time you complete drawing a frame.  The BufferStrategy class provides this functionality.  You can't use BufferStrategy with all AWT or Swing classes.  In particular it doesn't work with Panels.  The usual option is to place a Canvas in a Frame and apply a BufferStrategy to the Canvas.  For the sprites and Tiles use the Image class or the BufferedImage class.

The above system works fast because Java caches your sprites in off-screen video memory and uses the graphics card to blit them to the right place when you use drawImage.  Things slow done if you draw on the image and then draw it to the screen.  For instance if you use a BufferedImage and then draw on it with (say) fillRect, this happens on the main processor.  When you draw the image to the screen, it has to be copied to the video memory, which is a slow operation, so you lose performance.  This also happens if you use some of the advanced compositing functions in Graphics2D.  You would think these would be done in the graphics hardware, but that is not the case (at least by default), so this results in slow operations.  You can force Java to accelerate more graphics operations using the 'opengl' systems property, but this only works on later versions of Java and the amount of acceleration may vary with the platform.

If you need compositing or are writing a 3D game, then using the standard Java2D functions won't be fast enough.  At this point people usually use JOGL or the LWGL which provide an interface to OpenGL.  Either of these libraries work fine.  However these are not built into the default java installation so your game will have to get java to download them as part of your game installation.  This is a big overhead for a small game, but is becoming less of an issue as broadband speeds increase.  A drawback of using external libraries is that they need to be digitally signed.  This results in annoying dialog boxes popping up when using Webstart (or Applets) which can upset users.

The last option is to create a BufferedImage the same size as the screen and then use a succession of function calls to get the underlying byte array containing the display data.  You can then write to this in the same way you would write to a chunk of display memory.  The drawback is you have to write your own drawing primitives.  The advantage is the java Just-In-Time compiler compilers this all to native code at run-time, so it runs fast.  After creating a copy of your window this way, you then use drawImage to write it to the display.  While you can use a BufferStrategy here, in practice this works well enough without one.  The main application of this method is when writing games for the annual Java4k competition.  Here you are artificially constrained on application size and therefore cannot use libraries such as JOGL.

Lastly there are Scene engine libraries such as Java3D.  These are really intended for building up a 3D scene in non real-time.  There are also other game engines that build on top of JOGL or LWGL, but I haven't tried those, so can't comment on them.

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

[Nate]

Shouldn't there be a FAQ thread with links to various libraries?

For 2D look at Slick, or Java 2D. For 3D look at jMonkeyEngine, Ardor3D, LWJGL, or JOGL.

[Orangy Tang]

If you're new to writing games and only know a bit of java then Graphics2D is an excelent starting point. It'll let you get graphics on screen quickly and let you worry about the actual game rather than the irrelevant technical details. Plus you can do some pretty amazing things with Graphics2D once you get your hand in.

[Seecon]

Thanks everyone for the advice. Yes hah I'm going to do a 2d. I'm pretty sure 3d is much too advance, and to add to that, I'm not a very good modeler  .

Orangy, is there some sort of tutorial that kind of shows usage of the class..? I am in fact new, but I have a lot of common sense and could work well with a little guidance.

Much appreciated!

- Seecon

[Orangy Tang]

You might find this useful: http://www.cokeandcode.com/node/6

[JL235]

These days you quite rarely use Graphics, as most objects that contain the getGraphics method also contain a createGraphics method for creating a Graphics2D object. Graphics2D can do more then Graphics.

Today, I use JOGL with my own graphics layer on top for creating 2D. For me this works very well. For you I would recommend using Java2D because it's a lot easier to setup, you will encounter less bugs as you develop and it is pretty fast and powerful. Plus over the next few years it will get faster and faster as more of it's underlying code takes advantage of more and more hardware acceleration (I've had JVM updates where changes to Java2D have literally doubled the speed of my game).

This guide on GameDev is a good place to start is it explains how to create a JFrame that is all setup and ready for rendering to.

[pjt33]

The last option is to create a BufferedImage the same size as the screen and then use a succession of function calls to get the underlying byte array containing the display data.  You can then write to this in the same way you would write to a chunk of display memory.  The drawback is you have to write your own drawing primitives.

I have two comments on this. Firstly, I prefer to use a BufferedImage backed by an int[] rather than a byte[]. Secondly, BufferedImage allows you to create a Graphics object, so you can use this approach to mix standard Graphics calls with custom processing. My Java4k 2009 game did this - I drew almost everything directly to the int[], but used the Graphics object for text, before finally blitting the BufferedImage to the applet's Graphics object.