Threading for an RTS.

Java 2D
#1

How should I thread a swing based RTS? I was previously using ignoreRepaint(true) for all my components and repainting manually all in one thread to avoid concurrent mod exceptions. What is the correct way to do this? For smoothness, efficiency, etc. I imagine it would be a nightmare to program every in game entity to know when it needs repainting, so updating the gui at fixed intervals still seems desirable. Thoughts!

#2

hmm, just curious why do you want to thread you game? is it to improve performance?

if it is for faster performance, I’d try move away from using swing first rather then multithread the app.

#3

my game is based on mouse interaction, and swing makes that aspect simple to implement.

#4

there are two reasons I see why you should update all your entity every frame (but inded still depending on your game => those advices can be wrong) :

  • most entity will probalby have moved / changed (animation/rotation) at each frame ( but may be not ? )
  • you should not have any perf trouble until you try to render hundred of thousand entity ( but may be yes ? )

anyways as said above… you should really & fastlly forget about implementing entity as swing component, implementing some mouse event on sprite is not hard work, and far easier than making a RTS game.

I would recommend you to do something similar as the following :


//first way threat mouse input asynchronously setting some flags on entity for example (no real action)
run()
{
 while(mustRun)
 {
  
  performEntitiesMoveAndLogic();
  
  renderFrame();
 }
}

onMousePressed(.....)
{
 entity=getEntityAtLocation(mx,my);
 if(entity!=null)
  entity.setMousePressed(true);

}

or


//or you may synchronize mouse event with your thread...
run()
{
 while(mustRun)
 {
  events=popMouseEvent();
  performTaskForMouseEvents(events); 
  
  performEntitiesMoveAndLogic();
  
  renderFrame();
 }
}

onMousePressed(.....)
{
 pushMouseEvent(event)
}
#5

note that synchronising mouse input make sens because until the entity is rendered to screen change made to it wont be visible to the user so making all change just before rendering ii is just “making things” at the right time.

#6

It doesn’t seem like a completely lost cause, the swing usage that is. I just need to fix the concurrent mod exceptions and occasional glitchiness.

#7

do how you like but remember that you will have been advised …

#8

How about advice on how to do it this way? Not just “do it like everybody else does”

#9

Instead of advising about how to do it your way, let me just say that Swing is performing wildly different in just about every JRE update. Making it work fast on your machine is not that hard, but getting it to work on every JRE that your players will be running will probably drive you crazy.

Better to stick to an JRE independent framework, so that you control which version is running on the players machine.

#10

the problem is that you try to make something with an inapropriate tools (swing is for GUI as menu/container/etc…), it is like using hundreds of components (one for each pixels) to build an image it would be not the right way even if it could work ? so I dont really see what I could argue that can help you in using swing this way except if you try a swing technical demo performance ?

you got tens of others better options : pulpcore, java2d, slicks,etc… it is possible to make any kind of game in console mode but it is inapropriate right ? this is the same here, swing is not to be used this way and basically swing is not to be used at all ( but inded this is only my very personal opinion :slight_smile: )

EDIT: but if you still want to continu this way… (really you should not…) but… pseudo-source code snipets posted above may help to avoid concurent exception ( the second one starting with “//or you may synchronize mouse event with your thread…” )