Home » Community » Forums » » Java Games: Active Rendering
  Intel sponsors gamedev.net search:   
[Control Panel] [Register] [Bookmarks] [Who's Online] [Active Topics] [Stats] [FAQ] [Search]

Add Forum to Favorites |  Send Topic To a Friend | View Forum FAQ | Track this topic

Page:   1 2 »»

 Last Thread Next Thread 
 Java Games: Active Rendering
Post Reply 
Thanks for this article. One question though. On the 2nd page you first show an example when you use buffer.getDrawGraphics() todo the drawing, but in the full example you create a BufferedImage, then blit this image to the back-buffer?

What is the purpose of this extra BufferedImage?

Regards
elFarto

 User Rating: 1041   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

This is just an example of how you could use an extra image. That image could be a bitmap, or you could directly write pixel values to the buffered image.

Also, there are speed difference on slower machines when using the buffered image. I am not saying that it is the best case, but I have an old Pentium III that I tested the code with, and in that case, using the buffered image was faster.

I am glad you liked the article. The next Java Games: Input and Sound article is in the works. I have written all the code, I just need to write the article.

Thanks again.

Glass_Knife
I think, therefore I am.
I think? - "George Carlin"

 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

For a n00bie like me just stepping into 2d graphics programming in java, this article has tremendously helped clear my understanding of rendering. I knew of the so called 'traditional' method but the java tutorials/books always said to call paint whenever needed. I look forward to future java articles from you :D

Thanks!

 User Rating: 876   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by Glass_Knife
The next Java Games: Input and Sound article is in the works. I have written all the code, I just need to write the article.

Oooh, that's nice to know

________________

Drew Sikora
President, Programmer - Blade Edge Software
Executive Producer, Newsletter Editor - GameDev.net
Community Relations, Live Events Mngr - Game Institute
IGDA Chapter Advisor - New Jersey


 User Rating: 2077   |  Rate This User  Send Private MessageView ProfileView Journal Report this Post to a Moderator | Link

Quote:
Original post by Glass_Knife
Also, there are speed difference on slower machines when using the buffered image. I am not saying that it is the best case, but I have an old Pentium III that I tested the code with, and in that case, using the buffered image was faster.


Ok. I was doing a little bit of playing and found a much faster way, if you're willing to give up direct access to the pixels.

Firstly change the canvas.createBufferStrategy(2); from 2 to 1. It's not really necessary to have a double buffered canvas when your also buffering the contents (since you'd be blitting from your buffer to the back-buffer, then it would blit from the back-buffer to the front-buffer). I'm not sure if the following method would be quicker when page-flipping instead of blitting.

Then change
BufferedImage bi = gc.createCompatibleImage(640, 480);
to
VolatileImage bi = gc.createCompatibleVolatileImage(640, 480);


The add this
if (bi.validate(app.getGraphicsConfiguration()) == VolatileImage.IMAGE_INCOMPATIBLE)
{
   System.out.println("Recreating image");
   bi = gc.createCompatibleVolatileImage(640, 480);
}
before
g2d = bi.createGraphics();


This increased my FPS from about 190 to just over 1000 (changing the time to draw 1 frame from ~5ms to ~1ms). YMMV.

Also I replaced System.currentTimeMillis() with System.nanoTime()/1000000, as it is much more accurate (at least on windows anyway).

Regards
elFarto

 User Rating: 1041   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by Karan Bhangui
For a n00bie like me just stepping into 2d graphics programming in java, this article has tremendously helped clear my understanding of rendering. I knew of the so called 'traditional' method but the java tutorials/books always said to call paint whenever needed. I look forward to future java articles from you :D

Thanks!


You're welcome. I am glad you enjoyed it!



Glass_Knife
I think, therefore I am.
I think? - "George Carlin"

 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by elFarto
This increased my FPS from about 190 to just over 1000 (changing the time to draw 1 frame from ~5ms to ~1ms). YMMV.


That is one heck of a speed increase!



Glass_Knife
I think, therefore I am.
I think? - "George Carlin"

 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Excellent tutorial. We want more tuts on Java!

 User Rating: 852   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by Glass_Knife
Quote:
Original post by elFarto
This increased my FPS from about 190 to just over 1000 (changing the time to draw 1 frame from ~5ms to ~1ms). YMMV.


That is one heck of a speed increase!


Faster anyone?
Faster!

All I did was add -Dsun.java2d.opengl=True to the start parameters, which causes the Java API to use the OpenGL pipeline rather than the DirectDraw one, resulting in much much faster operations.

And they say Java is slow .

Regards
elFarto

 User Rating: 1041   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by ndatxcod
Excellent tutorial. We want more tuts on Java!


Thank you. I am glad you enjoyed the tutorial.


Glass_Knife
I think, therefore I am.
I think? - "George Carlin"

 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by elFarto

Faster anyone?
[image]

All I did was add -Dsun.java2d.opengl=True to the start parameters, which causes the Java API to use the OpenGL pipeline rather than the DirectDraw one, resulting in much much faster operations.

And they say Java is slow .

Regards
elFarto


I think that at this point, learning game programming with Java is very possible. I know it was too slow a few years ago, but since JDK 5.0 and JDK 6.0, things are good.



Glass_Knife
I think, therefore I am.
I think? - "George Carlin"

 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Hi!

First, thanks for the great tutorial! I am looking forward to the next one!

I am a complete java noob, so excuse me in advance if my questions are idiotic:
- Is it possible to use this technique in an Applet?

- I tried copy-pasting the final code and compiling failed because it couldn't find KeyAdaptor, BufferStrategy and BufferedImage. I am using javac version 1.5.10, and I put in the path the bin,lib,include,jre folders. What did I do wrong?
edit: hmmm I didn't know there is JDK6, I'll try downloading it and see if that is the problem.
edit: same problem with the JDK6

thanks,
Iftah.

[Edited by - Iftah on October 18, 2007 4:22:57 AM]

 User Rating: 1196   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by Iftah
First, thanks for the great tutorial! I am looking forward to the next one!


You are welcome! I am glad you enjoyed it. The second article, "Java Games: Keyboard and Mouse," should be finished soon. I can not comment on if or when it will be published. For that, I have to wait and see if they like it.

Quote:
Original post by Iftah
I am a complete java noob, so excuse me in advance if my questions are idiotic:
- Is it possible to use this technique in an Applet?


For this one I will say yes and maybe and no. How is that for an answer. I have not tried doing this, but I don't see why you could not use a Canvas object, add it the applet, and do all the graphics stuff with that. So that is the yes part. The maybe part is that I am not sure if you will actually be able to do double buffering that way. But then what? The great part about this way of writing the code is that all the code is in the game loop in main(). Applets don't have a main method. I guess you could put the game loop in a Thread, but now it is getting rather complicated, and I am sure that there is no way to switch to full screen mode from an applet (Again, I am not sure about that). That is the No part. Might I suggest that if you want people to play your game from the internet, just make the application and use Java WebStart to launch the program. Since most of the Java examples that used to be Applets are now WebStart applications, I think this is the direction that Java is going.

Quote:
Original post by Iftah
- I tried copy-pasting the final code and compiling failed because it couldn't find KeyAdaptor, BufferStrategy and BufferedImage. I am using javac version 1.5.10, and I put in the path the bin,lib,include,jre folders. What did I do wrong?
edit: hmmm I didn't know there is JDK6, I'll try downloading it and see if that is the problem.
edit: same problem with the JDK6


I don't know if it matters anymore, but I had a couple of my friends try out the code with both Java 5.0 and Java 6.0, so I am reasonably sure that this code will work with both Java 5.0 and Java 6.0.

Tim Wright (a.k.a Glass_Knife)



 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

how about active rendering on a jpanel (which does not consume the entire screen)?

 User Rating: 974   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by domstyledesign
how about active rendering on a jpanel (which does not consume the entire screen)?


I tried this out and it worked well. I just added the Canvas to the JPanel. You do need to change where you call ignoreRepaint however.

// Create game window...
JFrame app = new JFrame();
//Don't do this now : app.setIgnoreRepaint( true );
app.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
// Create canvas for painting...
Canvas canvas = new Canvas();
canvas.setIgnoreRepaint( true );
canvas.setSize( 400, 300 );
		
// Create a JPanel with the canvas
JPanel p1 = new JPanel();
// Ignore repaint here
p1.setIgnoreRepaint( true );
p1.add( canvas );
		
// Create another JPanel with a JButton
JPanel p2 = new JPanel();
JButton b1 = new JButton("ASDF");
b1.addActionListener(new ActionListener() {
  @Override
  public void actionPerformed(ActionEvent e) {
    System.out.println("ASDF");
  }
});
p2.add(b1);
		
Container contentPane = app.getContentPane();
contentPane.setLayout( new FlowLayout() );
contentPane.add( p1 );
contentPane.add( p2 );
app.pack();
app.setVisible( true );



I hope that helps!

Ciao,

Tim Wright (a.k.a. Glass_Knife)


 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

is that safe though? i mean, what about the z-order bug when mixing lightweight and heavyweight components?

i want an actively rendered jpanel that i can safely drop into a completely-SWING app w/ no worries

 User Rating: 974   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by domstyledesign
is that safe though? i mean, what about the z-order bug when mixing lightweight and heavyweight components?

i want an actively rendered jpanel that i can safely drop into a completely-SWING app w/ no worries


According to the java tutorial on active rendering, "Finally, be very careful to avoid deadlocks if you decide to use both active and passive rendering simultaneously--this approach is not recommended."

I have read about problems with menu items not being drawn, as well as other problems. A quick test showed no issues, but you are right, mixing light-weight and heavy-weight components can cause trouble.

If you know of any websites that explain the problems with this, please post them, so future readers can understand what problems they might have.



 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

This page should explain what you need to know about mixing heavyweight and lightweight components.

---
GameDevMike | The One With Aldacron | The One With D

 User Rating: 1462   |  Rate This User  Send Private MessageView ProfileView Journal Report this Post to a Moderator | Link

Quote:
Original post by Aldacron
This page should explain what you need to know about mixing heavyweight and lightweight components.


Thanks to Aldacron. After testing this out, I see no way that mixing these two can work. The active rendered area draw over the top of everything. If you have a menu that extends into the Canvas area, then it is hidden.

So at this point, I would say "Don't mix AWT and Swing." Yes, you can do it, but you will have the problems pointed out by the link above.

Tim Wright (a.k.a. Glass_Knife)



 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by Glass_Knife
So at this point, I would say "Don't mix AWT and Swing."


and i would agree - which is why i was asking about an actively rendered jpanel, and not a jpanel with an actively rendered canvas inside it.



 User Rating: 974   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by domstyledesign
Quote:
Original post by Glass_Knife
So at this point, I would say "Don't mix AWT and Swing."


and i would agree - which is why i was asking about an actively rendered jpanel, and not a jpanel with an actively rendered canvas inside it.


Right. Now I understand. If there is a way to do this with a JPanel, then I do not know what it is. I did a search of the J2SE API docs, and the only classes that have the createBufferStrategy() method are the Canvas and the Window.

Tim Wright (a.k.a. Glass_knife)



 User Rating: 1569   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

yes, but the buffer strategy is only one solution. for example, one might have

class ActivelyRenderedJPanel extends JPanel{
	private boolean running = false;
		
	public JPanel(){
		super(null);
		setOpaque(true);
		setIgnoreRepaint(true);
	}
	
	public void run(){
		if(running) return; // throw exception?
		running = true;
		while(running){
			repaint();
		}
	}
	
	public void stop(){
		running = false;
	}
	
	public void paint(Graphics g){
		// draw stuff here
	}
}


swing components are double buffered by default, so flickering shouldn't be a problem (right?). but i believe the repaint() method also triggers the EventDispatcher's thread, which would kill performance.

i'd like to just call the paint method directly, but i remember reading that it's unsafe. haven't, however, looked at the source code to see why.


thoughts?

 User Rating: 974   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by Glass_Knife
According to the java tutorial on active rendering, "Finally, be very careful to avoid deadlocks if you decide to use both active and passive rendering simultaneously--this approach is not recommended."


i think they are referring to actively rendered components which have not called setIgnoreRepaint(false);


i can see no (immediately obvious) reason why one couldn't have an actively rendered component and a passively rendered component side-by-side



 User Rating: 974   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

and i just noticed that the java tutorial on active rendering includes this tip:

Do not use heavyweight components, since these will still incur the overhead of involving the AWT and the platform's windowing system.


the example they provide uses a Frame object... but isn't Frame (and Canvas, for that matter) a heavyweight component?

 User Rating: 974   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link
Page:   1 2 »»
All times are ET (US)

Post Reply
 Last Thread Next Thread 
Forum Rules:
You may not post new threads
You may post replies
You may not edit your posts
You may not use HTML in your posts
Jump To:
Administrative Options: