Best rendering method using pure java?

Game Mechanics
#1

Hello, i’m new here. I am very confused and curios.
If you’ll take a look over the internet for Java game programming tutorials you’ll find that people are teaching two common ways for rendering(in pure Java):

1.Using just an Image at the size of the window:


Image image = createImage(1024,768);
image.getGraphics().drawString("My string!",100,100);

2.Turning a BufferedImage into an Integer array for pixel manipulation:


BufferedImage image = new BufferedImage(WIDTH, HEIGHT, BufferedImage.TYPE_INT_RGB);
int[] pixels = ((DataBufferInt) image.getRaster().getDataBuffer()).getData();
pixels[myPixel] = 0xFFFFFF;

I want to ask you which of them is better, and why? and if no, can you recommend me another method? I’m very curios about this and i want to develop my own game, but i’m still planning.

#2

BufferedImage. It loads data from a texture file and allows you to draw pixels straight to the screen. Its more low level, but the first way you have up there is much slower, but easier.

#3

I’m programmng in java for like a year now, and still can’t really get the idea of the bufferedimage with loading sprites and manipulating everything, but thanks for the fast answer.

#4

It depends upon:

  • what precisely you’re drawing, and,
  • how well the hardware acceleration is implemented on your target platform.
#5

Please search forums first.

Loading an image is very easy. Just ImageIO.read(ClassLoader.getSystemResource(path)); where path is the location of your resource. Then use the Graphics object to draw the image.

g2d.drawImage(x,y,w,h) is the FASTEST method of drawing images in java2D. The speed is based on your drawing surface when doing this though. Drawing to a Volatile Image or canvas will be fast. Drawing to an other BufferedImage will be slow.

Reality check. If you want to do anything more then simple sprite based games, use some opengl engine.

#6

It depends on what you want.

First method uses Java2D to render, which tries to use DirectX, then OpenGL and if both fail it will use a software renderer.

Second method uses your own software renderer, but it can be a lot more flexible than Java2D.

#7

I usually end up basing my core class off of the applet class, Then I just work from there.

I create an image (not a BufferedImage) called ‘display’, ‘canvas’, ‘screen’, etc. Then I define it in the run method as a volatileImage. These are handy little things and work quite well.

This is what my usual render method ends up looking like, if I don’t scale the game down:


private void render() {
        Graphics g = display.getGraphics();
        
        g.setColor(new Color(0, 0, 0));
        g.fillRect(0, 0, WIDTH, HEIGHT);

        // Render Stuff. I.E: screen.render(g);

        g = getGraphics();
        g.drawImage(canvas, 0, 0, WIDTH, HEIGHT);
}

I had the boilerplate code for some sort of demo that used this method, I’ll upload the code whenever I have the time.

  • Jev.
#8

Lots of tutorials on the youtubes to get you started such as thechernoproject which runs through producing a game in the buffered image manor. HOWEVER , only use the code as a basic template so only really go as far as learning how it draws the pixels and how to load images if you start messing around into other peoples rendering conventions you most likely will find yourself confused and stuck on meager issues that will effect further project development.

#9

+1 * Infinity for theChernoProject. He is possibly the most helpful and most thorough youtuber there is that deals with Java. He doesn’t even just create game tutorials, he’s also doing networking which involves GUI and other fantastic things! I have to say he’s probably one of the major reasons why I switched to Java from C++!

#10

Just a side note if you are looking for anything that is syntax based take a look at the newbostons intermediate and beginner java tutorials they explain almost everything.

#11

I started one, and uploaded it to Gist:

It’s a software graphics library with blending, textures, and simple primitives.

Checkout https://gist.github.com/ClickerMonkey/7534326/raw/7a472d6541a9be059eba3735a7e6e19e7264e5e1/Test.java to see what the drawing code is like.

#12

[quote]I had the boilerplate code for some sort of demo that used this method, I’ll upload the code whenever I have the time.
[/quote]
@kpars - am looking forward to this upload!

#13

@orel27bit Good question, I have been working the same thing myself. ???

Thank you for posting this topic. It has helped me too! :slight_smile:

#14

i would suggest to just use the draw calls given by java. i too recently asked the same question and came to figure out that pixel manipulation of an image is much slower than just drawing said image. and you dont get all the built in controls (e.g transforms) . Also you cant have good resolutions with per pixel rendering since the better the res the slower it will run.

So like suggested before g.drawImage seems to do the trick quite nicely.

#15

@kpars - am looking forward to this upload!
[/quote]
I wrote something very similar a few days before I made that post, actually :smiley:
http://kemoy.net/JevDocs/Java2DPhysx/

  • Jev
#16

Same here. My youtuber was thenewboston… Bacon, Apple Pie, and Chicken got me through polymorphism :)…

#17

:smiley: I like the new boston , and his er “Extravagant” Backgrounds.

#18

What do you all think about this method of drawing a loaded image to the screen?

I first load the image using this code:

package utilities;

import java.awt.Graphics2D;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsEnvironment;
import java.awt.image.BufferedImage;

/**
 * 
 * @author Valkryst
 * --- Last Edit 24-Oct-2013
 */
public class ImageUtilities {
	private static GraphicsConfiguration graphicsConfiguration = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
	
	/**
	 * Checks if the specified image is already compatible with the current display.
	 * If the image is compatible with the current display then return the image as-is.
	 * If the image isn't compatible with the current display then run the code to make it compatible then return the compatible image.
	 * 
	 * @param image The image to make compatible.
	 * @return Returns either the same image that came in or the compatible version of that image. 
	 */
	public static BufferedImage toCompatibleImage(BufferedImage image) {
		// Check if the image is compatible with the current display. If it is then return the image, else make the image compatible and return it.
		if(image.getColorModel().equals(graphicsConfiguration)) {
			return image;
		} else {
			// Create a Buffered Image compatible with the current display.
			BufferedImage newImage = graphicsConfiguration.createCompatibleImage(image.getWidth(), image.getHeight(), image.getTransparency());
			
			// Create a graphics context and render the incompatible image onto the compatible image.
			Graphics2D g = newImage.createGraphics();
			g.drawImage(image, 0, 0, null);
			
			// Dispose the old image and return the new compatible image.
			g.dispose();
			image.flush();
			
			return newImage;
		}
	}
}

Then just do a g.drawImage(); statement whenever I’m drawing the image. The images aren’t being constantly loaded by the way. If I’m in a certain level then only images used in that level are kept loaded and reused until I don’t need them.

#19

Maybe it’s just my old C++ habits talking, but shouldn’t the responsibility of cleaning up created objects be left to the creator? In this case your class is freeing resources that weren’t allocated by it. Maybe not a biggie in your use case, but something that popped out at me.