Game development with Swing: Using threads.

[AvivC]

I admit to have corss-posted this to another site, but I’m getting no help there, so I’ll try my luck here

(Note: Even if you don’t recommend Swing for game development, please try to answer my question as it is).

For those of you who use Swing to develop their Java games.

As I see it, there are three main possible approaches to designing games in Swing, in relation to threads:

1- Have the entire game (except for especially long-running tasks) run on the EDT.

2- Have the entire game run on a non-EDT thread.

3- Have clear seperation between a thread to constantly run game logic (a non EDT thread), and a thread to constantly update the screen (the EDT).

By your experience and knowledge, which approach is the most common, and/or the most efficient, and/or the most reasonable programming-wise (aka isn’t relativley very complex to design)? Which approach should I use?

Help would be appreciated (I really want to pick up good habits).

[Drenius]

You can use threads, but there is less advantage than you might think…
But you could or will get problems with accessing lists using it.

[SHC]

Though I don’t recommend using Swing for games anymore, I’d say option #2 is the best way to use swing for games, since you cannot do too much work on the EDT and using two threads for both rendering and logic results in a mess.

[Roquen]

@Drenius

You can use threads, but there is less advantage than you might think…
But you could or will get problems with accessing lists using it.

What I think is that on an N core machine I can get more than a N times increase in through put by having a well chosen number of active threads that’s greater than N. And I’m consistently correct.

[princec]

Hm, YMMV, but I don’t get quite that sort of scaling in throughput.

In other news though… simplest solution is to run the game all on the EDT (if it an arcade game) using active rendering. If it is a turnbased game (ie. UI led) then run it on the EDT as well, but be aware that long-running tasks will freeze the UI completely, and these should be punted to their own thread and the UI updated with progress indication.

Cas

[Roquen]

Absolutely YMMV. It going to depend on your experience, how well you can design the separation of tasks, what they are, when they have to run, etc. etc. My point being there’s this mistaken notion that there isn’t much to be gained by multi-threading…don’t believe it.

[AvivC]

@princec

Hm, YMMV, but I don’t get quite that sort of scaling in throughput.

In other news though… simplest solution is to run the game all on the EDT (if it an arcade game) using active rendering. If it is a turnbased game (ie. UI led) then run it on the EDT as well, but be aware that long-running tasks will freeze the UI completely, and these should be punted to their own thread and the UI updated with progress indication.

Cas

If using one thread, I think it better be a non-EDT thread. Why are you suggesting the EDT?

[princec]

If you’re making an arcade game your game loop has to execute in 17ms anyway (well, it’d be nice if it did at any rate) and thus it doesn’t matter if it’s on the EDT.
If you’re making a turnbased event-driven game, if your game logic executes in just a couple of hundred ms, then no-one’s going to notice, and it’ll be easier to code.

Interacting with Swing when you’re not on the EDT is a bit ugly and annoying, so it’s just easier. By all means run it all in a separate thread, but be aware you can do absolutely nothing to the UI in that thread, and that thread can’t even listen for events on the EDT either. The only way you can communicate with the EDT is to use SwingUtilities.invokeLater() (or SwingUtilities.invokeAndWait()). That is a pain.

Cas

[SHC]

I object that. When I’m learning swing, I’ve used to just override the [icode]paintComponent()[/icode] method. But when my game progressed enough to make a scrolling maps, when all the objects (2-3 enemies and the player on screen and floor is made as tiles), the game started to lag. I’ve then read Brackeen’s Java Game Book and it suggested that using Threads, one could solve this and by moving game loop to the [icode]run()[/icode] and implementing the [icode]Runnable[/icode], it ran very smooth. Later, I’ve made all those tiles as dynamic objects as well, and with almost 30-40 objects on the screen, and the map is scrolling, I’ve achieved 70-90 fps.

[AvivC]

@SHC

I object that. When I’m learning swing, I’ve used to just override the [icode]paintComponent()[/icode] method. But when my game progressed enough to make a scrolling maps, when all the objects (2-3 enemies and the player on screen and floor is made as tiles), the game started to lag. I’ve then read Brackeen’s Java Game Book and it suggested that using Threads, one could solve this and by moving game loop to the [icode]run()[/icode] and implementing the [icode]Runnable[/icode], it ran very smooth. Later, I’ve made all those tiles as dynamic objects as well, and with almost 30-40 objects on the screen, and the map is scrolling, I’ve achieved 70-90 fps.

Does that mean that your game lagged on the EDT, and moving it to a different thread solved the lags? (The entire game run on a non-EDT thread?)

[princec]

Wrong on so many levels :emo:

Active rendering in Swing is where you run the EDT at 60Hz. You paint every 17ms. If you can’t run your game loop in 17ms, rethink your game loop, because something is probably broken. Do not resort to threads until you know how to get this bit right. (See also: make Pong before your first MMO)

Cas

[SHC]

@AvivC

Yes. Now my game is entirely on a new thread.

@princec

I’ve started programming games with this framework tutorial. It said a Game thread and I’ve followed it simply. Also can you say why are you opposing the use of threads for the gameloop by a beginner? Even the first thing mentioned in the newboston’s tutorials or brackeens book is Threads.

[nsigma]

@princec

Active rendering in Swing is where you run the EDT at 60Hz.

That’s not what’s usually meant by active rendering. I’ve yet to see a tutorial, including Oracle’s (well Sun’s! ) own on this, that talks about doing it in the EDT, and the same for the BufferStrategy JavaDoc. I’d also be highly suspect about what the OP means by “Swing”. Are we talking actual UI components, or just drawing on a big canvas?

Usually I’d recommend ignoring the Swing stuff, and use a Frame and a Canvas from the awt package. Create a BufferStrategy from the Canvas, and directly draw into that from your rendering loop, outside the EDT. You can also get a BufferStrategy direct from the Frame / Window, but I prefer the flexibility of using Canvas. It’s also best to set to ignore repaint requests (setIgnoreRepaint()) to avoid any possible conflict with the EDT, and beware of any events fired by the window, etc. which will still be in the EDT.