Active rendering, Swing, custom threading, peripherals

Newbie & Debugging Questions
#1

I have seen a lot of people troubled by the stuff mentioned in the topic, and while I understand the problems entirely I won’t claim to have any particularly viable solution. A forum search reveals a number of threads which basically say ‘you can do this that way’, but I have not been able to find any explicit solutions to the stuff presented below. Sorry if it has nonetheless been rehashed indefinitely already.

As you all know, most games work with only one main thread and executes everything from there. In most games there are some performance-critical parts, such as a main display, which may be actively rendered. However there are frequently information panels that would benefit from a more swing-like model, and in this context it becomes difficult to avoid threading problems. Another point is that mouse and keyboard input managed through eventlisteners generally run from the event dispatch thread.

I believe JInput offers a solution to the peripheral input problem. But if you wish to use Swing components, it is still difficult to avoid trouble unless the Event Dispatch Thread is used as the main thread for both logic and any mix of passive or active rendering. As far as I can see, doing everything from the Event Dispatch Thread is the only easy solution, but I have the feeling that this is not a common thing to do.

Another option is to get all peripheral input asynchronously, like I assume JInput would - or possibly by manually queueing all of it for execution in the other Thread. Now, the ability to perform passive rendering is - as far as I can see - lost.

Which structure do you guys use? Do you have any rants or opinions regarding this topic? What is the square root of 517? And what is the meaning of life?

#2

Well using event dispatch thread i modify states of global variables: e.g. keys[600]-this can store all key strokes. Also i store mouse actions inside booleans.

Then in that main thread you’ve mentioned i poll for states of these keys-.e.g isPressed(KeyEvent.VK_LEFT) -then all logic…

I guess that it solves the problem to some point-there are still 2 threads- but hey-u also have garbage collector thread(3)- u cant escape them in Java…
You should check out Andrew Davidson’s book “Killer game programming in Java”-there are good examples.

#3

[quote]As far as I can see, doing everything from the Event Dispatch Thread is the only easy solution, but I have the feeling that this is not a common thing to do.
[/quote]
Swing is not thread save. doing stuff on the Event Dispatch Thread is not only common, sun even advises it.

http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html
http://java.sun.com/developer/JDCTechTips/2005/tt0419.html#1
etc

#4

You can go to active rendering to get control of the render in a game-like manner.

Mike Martak’s notes on it remain the definitive reference/tutorial:

http://java.sun.com/docs/books/tutorial/extra/fullscreen/

You can even use Swing compnents ina ctive render as long as you disable automatci rendering (tehre is call for that on Component,I forget what it is but I believe it is mentioned in the tutorial above.

After that, you paint by calling the paint() method directly.

Note that thsi isnt used a lot. msot games woudl ratehr do their own UIs anyway, so there are probably lots of little details youll need to work thorugh if you want to do it.

#5

[quote]Well using event dispatch thread i modify states of global variables: e.g. keys[600]-this can store all key strokes. Also i store mouse actions inside booleans.
[/quote]
That is how I store keystrokes too. The primary beef I have with doing the same thing for mouse input is that mouse input is usually handled by multiple listeners in different panels, and if I have a complex Swing component (for example a JTree or JTable) it is extremely inconvenient to force input to be handled in another Thread (or more accurately I have no idea how).

[quote]Swing is not thread save. doing stuff on the Event Dispatch Thread is not only common, sun even advises it.
[/quote]
Yeah, Sun advices it. I just had the impression that everyone here was doing something else, but couldn’t see why. If that isn’t the case then - well - that clears things up. It is quite nice to have automatic collapsing of subsequent repaint events, for example, if the game starts flickering.

Right now I use a java.awt.Canvas + BufferStrategy for painting, except from the information panels, which use passive rendering. The Canvas is convenient because the BufferStrategy does not apply to the other panels, whereas the alternative would be to equip the entire JFrame with a BufferStrategy applying to all components (since I cannot modify directly the BufferStrategy of a JComponent). This would be bad as far as I can see, because it’s only a certain portion of the screen which actually has to be rendered every frame, and would result in lots of unneeded buffer activity. However it is quite hack-like to use an AWT component just in order to avoid attaching a BufferStrategy to all the other components.

One alternative is to simply rely on Swing default double buffering, but since everyone use BufferStrategy (or something even more manual) I assume this approach would be ill-fated somehow - people say it is more efficient to write your own (not that I have made any tests).

#6

Most folks here either use active rendering or go aroudn ti competely by usign an OGL binding.

The reasons are performance and control.