Killer Game Programming's Animation Framework Being Wrong

Newbie & Debugging Questions
#1

Hello. I’m a new member here.
While I’m not a newbie in Java, I’ve just started to game programming. And I need your advices on this.

In the resources page of the site (http://www.java-gaming.org/index.php?action=resources), I’ve seen that “Killer Game Programming in Java - Andrew Davison” is one of the recommended books.

I have been trying to read this book for a while but I have discovered that the animation framework presented in the second chapter of this book is wrong. Because in Java tutorial it’s said that GUI components should be accessed (created, modified, queried, etc.) only in EDT (Event Dispatch Thread). But in Killer Game Programming, animation is controlled by another thread. And it uses a technique named ‘Active Rendering’ which doesn’t event use method repaint. Instead, it tries to get graphics context of JFrame in order to render everything by itself. It uses JPanel from another thread therefore violates Swing’s single thread rule.

Seems like this book had already been outdated when it was printed. Because as far as I know the change in Swing rule was made in 2004.

Since you recommend this book to newbies, can you enlighten me? What should I do? Should I continue reading a wrong book? Am I the wrong one?

#2

I have read that Book myself (partly). The threading is actually correct. And using the repaint() method is actually a really bad idea…

Yes. You are right about components needed to be accessed inside the EDT, but in that case, you can just use Frames instead of JFrames, Panels instead of JPanels, etc. Just use the awt equivalents to swing’s classes (awt is thread-safe), you won’t need any functionalities from swing anyways. The only thing you might want to implement yourself (via a WindowListener) is swing’s JFrame.setDefaultCloseOperation(…).

Or just go on with using JPanels and JFrames. That shouldn’t cause a problem.

#3

Huh? You do know that Swing uses the AWT event dispatch thread (EDT), right? :wink:

AWT is equally single-threaded and not thread-safe - http://en.wikipedia.org/wiki/Event_dispatching_thread

No, Swing has always been single threaded. The “rule” that changed was around creating components off the EDT before they were realised (ie. before making them visible). It’s now recommended to always create components in the EDT.

However, active rendering to an AWT or Swing component is OK. I’d recommend a Canvas, and searching for information on using BufferStrategy.

While painting to the component is OK, I’d recommend building and displaying the window and canvas on the EDT first. You also should probably use setIgnoreRepaint(true) to stop the component trying to respond to paint requests from the EDT.

#4

Hello. Thanks for the reply.

Can you give more specific information on why it’s OK to paint ? Doesn’t painting mean modifying? Is every painting function thread-safe or what?

I use this method to create the Frame and the JPanel. GameMain contains the code to instantiate and show JFrame.

public static void main(String[] args) {
// Use the event dispatch thread to build the UI for thread-safety.
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
new GameMain();
}
});
}

#5

repaint() is unreliable. It’s just a suggestion to AWT/swing to repaint… maybe… if it’s not too busy… and it feels like it

#6

I should have been more adamant about my last sentence! :wink: Use setIgnoreRepaint(true) on the component. This makes it ignore repaint requests, so you don’t get thread races between the EDT and your active rendering thread.

You should do some research on active rendering and buffer strategy. There’s lots of stuff on this site and out on t’internet.

#7

OR!!! yall should use libgdx…

Just super saiyan. :wink: