Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Killer Game Programming's Animation Framework Being Wrong  (Read 699 times)
0 Members and 1 Guest are viewing this topic.
Offline ggt

Junior Newbie





« Posted 2013-03-14 18:10:12 »

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?
Offline matheus23

JGO Kernel


Medals: 107
Projects: 3


You think about my Avatar right now!


« Reply #1 - Posted 2013-03-14 18:54:36 »

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.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline nsigma
« Reply #2 - Posted 2013-03-14 19:15:41 »

awt is thread-safe

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

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.

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.


Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ggt

Junior Newbie





« Reply #3 - Posted 2013-03-14 19:35:26 »

awt is thread-safe

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

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.

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.



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();
         }
      });
   }
Offline deepthought
« Reply #4 - Posted 2013-03-14 19:45:20 »

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

jocks rule the highschools. GEEKS RULE THE WORLD MWAHAHAHA!!
captain failure test game
Offline nsigma
« Reply #5 - Posted 2013-03-14 19:51:00 »

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 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.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline StumpyStrust
« Reply #6 - Posted 2013-03-14 20:05:56 »

OR!!! yall should use libgdx...

Just super saiyan.  Wink

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (24 views)
2014-09-19 03:14:18

Dwinin (39 views)
2014-09-12 09:08:26

Norakomi (68 views)
2014-09-10 13:57:51

TehJavaDev (93 views)
2014-09-10 06:39:09

Tekkerue (47 views)
2014-09-09 02:24:56

mitcheeb (68 views)
2014-09-08 06:06:29

BurntPizza (51 views)
2014-09-07 01:13:42

Longarmx (38 views)
2014-09-07 01:12:14

Longarmx (44 views)
2014-09-07 01:11:22

Longarmx (40 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!