eek, a multiThread heathen
release the hounds!!
For 2D games I would not suggest implementing multi-threading because I think is it not necessary and NO, there is no so much extra work to do to implement these simple physics calculations if you implement it in a base class like an actor.
Also having multiple threads involve synchronizing states which is an expensive task and the VM have to switch the execution context all the time which is also an expensive task for your program.
For most networking situations, a seperate thread is going to be a must. I can also imagine that, depending on the details, a physics thread also makes sense. There’s not necessarily anything wrong with the information he gave…
A separate thread to do the networking code is the only way to do networking. Excellent.
A separate thread to do physics is possibly the worst way to do it that you could conceive of.
Cas 
Oh well, what can I say? 8) I haven’t gotten much into physics yet.
You can code everything and anything for a game into a single thread if you wanted to.
The question here is what makes sense for your game and ‘NO’ you don’t have to syncronize your drawing threads, physics threads and network thread. That would be very foolish. I can’t think of a single reason why you would need to.
If the complexity of your project is great then you need to seperate your tasks and it makes no sense why you can’t use an extra physics thread (independent of frame rate) to change your world at set intervals. This is true for most games but definately is true for 2d rts games that don’t need anything less then pixel accuracy for movement, firing, ect. I can see your point with some 3d games that require a finer resolution. The physics thread would be going too often and may start hurting your games performance. But this is a 2d forum and we are talking about what is a good 2d design.
Most games don’t need to have a super active physics thread. Our game is graphically intensive and our physic thread operates about 1/100 of the time our graphics thread so how does this slow anything down? I’ve tested performace and I get no change in my frame rate with or without a physics thread.
All I know is that by seperating our physics from our Rendering has made our life a lot easier and we have suffered no performace loss from adding it and I’d venture to guess that most graphic intensive games would see similar results.
What harms performance more then anything using the java awt is displaying text on the screen. Some of our game screens can drop from 75fps (max refresh rate) down to 30fps on a p2 400 with adding a few hundred characters of text.
I’ll explain again why Threads don’t work in this situation:
Physics simulation is a function of actual time elapsed where you take regular samples. The samples need to be regular because human beings are very, very sensitive to changes in rate.
If you use a Thread to make your regular samples you will find that your samples are not regular at all but dependent on several platform-independent behaviours like thread switching latency, scheduling algorithms, other threads running in the O/S, etc; in other words, it makes your code non-deterministic.
Apart from human beings picking up in this non-deterministic behaviour very, very quickly and feeling uncomfortable, you have another problem in that you are synchronizing it with another non-deterministic thread which is your rendering thread. This will multiply the irregularity. You probably don’t even realise this but you have already seen what this looks like when you play a network game (although the causes are different) - things stop in mid air momentarily, you freeze solid for half a second etc.
This is not a problem on your dual-processor 2GHz development machine running XP Pro. It just happens to work OK for you - hurrah!
But on my Celery 350 Win98SE box, the rendering thread and physics thread may not interact quite so beautifully all of the time. And remember - your threads are not the only runnable threads - you have to share the OS with whatever else might be running. Who knows what the *nix based systems do?
If you want to make life easier for yourself, you put physics and rendering in the same thread. Then you know that what you are rendering needs no synchronisation, and is an accurate representation of that which you have just calculated. This means you have removed a whole chunk of complexity and arsing around trying to make it deterministic again (the usual Java woes - “Why is it jerky? Why does it pause every now and again? Why is keyboard input sluggish?” etc solved at a stroke). So why it’s less complicated to put it in a separate Thread I have no idea.
Anyway, that’s the way I do things and it means I haven’t had to use the synchronized keyword yet, which must have saved me considerable typing…
Cas
A couple of additional points:
Say your physics works at twice the speed of the rendering thread - you’re now doing twice the work, yet only seeing half the calculated results, and so wasting alot of time. If your rendering is going twice as fast, then you either show the same frame twice (in which case you’d have been better sitting idle and letting the GC get a look in) or you do some sort of interpolation inbetween last and current frame - in which case you’ve overcomplicated things and are likely to get worse results anyway.
[quote]you don’t have to syncronize your drawing threads, physics threads and network thread
[/quote]
Oh yes you do. Either explicitly with syncronisation blocks (which can be hell to code) or with a thread safe collection on anything that overlaps (in which case you’re getting alot of overhead which you won’t appreciate at first).
When our team did CatAttack, we had separate threads for networking, and all was good. Until we started seeing weird logic errors and random crashes. We hadn’t syncronised anything and were just letting the two (or more if you were the server) threads operate on the same data. You lose the integrity of your data structures at random points - and you can’t think “This is so unlikely to happen, its not going to happen to us”, because with both threads looping constantly and rapidly, sods law will mean that the obscure sequence of events you thought impossible will turn up within a few seconds.
(Out solution was a buffer between the threads, where network commands could be queued up, then locked, processed, emptied and unlocked at the end of every frame).
Multithreading bugs are hell to track down and fix, and you gain almost nothing except uncertainty…
Ok, I’ll agree with cas on his point of unexpected lag if you don’t syncronize the physics thread in multiplayer but this is rather simple thing to do (and has nothing to do with using the slow syncronized keyword for the thread). It is relatively simple to syncronize a two player multiplayer physics thread, I’ll agree if you are doing more then this or if your physics thread becomes overly complicated it might be a better design to base physics on elapsed time. Most games 2d games don’t contain overly complicated physics and I’d argue that you are using a ton more cpu to compute physics if you are getting 75fps (which we do on our min required system p2 400) but you only need to update your physics every 50ms (which is the physics interval for our game). So infact we are saving almost 4x the physics calculations by having a seperate thread. By not setting a max to my fps I’m able to create a scrolling game that has very fast response because I don’t have the ton of overhead that comes with updating my physics everytime I want to redraw the buffer and it creates a much better feel to the game overall.
That is why I state that most people would find using a physics thread for 2d games would improve performace if you don’t need to have high resolution for state changes. 3d games would almost certainly require more precise physics and I would agree that having a second physics thread for doing this would slow things down.
I see your point but I also think that with the correct implementation, having an extra physics thread is the better choice for some games.
TheAnalogKid,
How do you implement a good collision detect in time based movement?
Here, sprites don’t move tile by tile so a simple x-y checks don’t not apply well. Time based movement may move two sprites across each other, but still never meet in a coordinate system (A moved 32pixels, B moved 16pixels where A sort of flew through B sprite).
If you get objects leapfrogging others, you will need to look into ‘swept’ volumes, between the old and new positions. A point is swept into a line, a sphere into a lozenge, etc. Then you test these into each other. The real problem is back-tracking to the correct collision point, but most of the time a quick approximation will work fine there.
Where can I find more info about fixing a “leapfrogging” collisision detect problem?
Sorry to dig this up, but I think that the whole concept of fps is kinda missinterpreted here.
Instead of calculating new positions according to fps for every frame, we should be thinking in terms of skipping frames. This way everything works right, no extra animation frame calculations, and no added multiplications.
So, here’s a little (pseudo)code:
update: Ya ain't worth it. Bye
DO NOT USE MULTIPLE THREADS IN GAMES
i agree to princec, ever thought about synch all variables between render and physics thread ? if u DO NOT SYNC EM your game will go berserk.
DO NOT CUT FPS
why do u wanna cut off the fps rate ? let it flow, u want FPS based movement ? hmmm think about it.
do avatar movement based on time ( for e.g. you scroll screen by 1 ( or whatever you want ) every 50ms, its really easy to achieve this in ONE THREAD.
I wrote alot of stuff n games under DirectX and WE DO NOT CUT OFF FPS grrrrrrrr
DO NOT DRIVE ME CRAZY
Using big fonts is like shouting, people will notice it but it doesn’t make you right. (not that I know if you are or not). Its also fairly irritating.
Kev
Maybe I’ll just nip back and edit me comment on page 2!
Ah, just be thankful Java_VRML_Animator hasn’t appeared in the thread.
Cas
argh … Java_VRML_Animator, you wrote it
[quote] Maybe I’ll just nip back and edit me comment on page 2!
Ah, just be thankful Java_VRML_Animator hasn’t appeared in the thread.
Cas
[/quote]
Cas, a suggestion: Write up the argument you’ve become famous for ;D in an article, and introduce it / title it something like “Real-Time Games”.
Part of the problem with this issue is that your viewpoint is definitely not always correct for every game…and a lot of people find themselves in a situation where it isn’t actually best. Unfortunately, they seem to have difficulty appreciating that you are describing a very mainstream technique, one that should be part of their toolbox - many interpret it as “do it this way; all else is wrong”.
Give it a name, and I think a lot of people will interpret it more sensibly. For people who don’t know precisely what RT means, it probably will also make them think “Hey, I bet that’s a way of making my game go faster!” and so you’ll grab the attention of lots of people just with the title. And you wouldn’t even be misleading them
It also makes it extremely easy to have a section “When should I be using Real Time programming?” - and easy to provide links to the many many many CompSci courses on the web which have nice, simple, easy to understand lecture slides on RealTime scheduling.
Just a thought…
Oh, and everyone else [naming no names] please stick to reasoned arguments with supporting evidence…it makes the conversation more interesting.
[quote]Cas: I’m currently having a thread for each triangle in my 3d shooter. Each triangle is then given a dynamic priority depending on how close it is to the camera. Then all triangles will do
while (true) {
synchronized (this) {
Renderer.display(this)
}
}
to have itself rendered. The Renderer in turn does this
synchronized (this) {
if (num_triangles < MAX_TRIS_PER_FRAME) {
gl.makeCurrent();
tri.render();
}
}
That way I can control how many triangles is rendered, and by using threads, I’m assured the maximum throughput (every triangle renders as fast as they can, no more waiting for a traditional single threaded rendering loop to render it).
However, I might be forced to redo this in C++ as the JVM is really bad at handling threads :(((. My approach only gives me about 1-2 fps for a quake modelviewer test. My guess would be that using C++ would give me about 60-100 fps. Do you think I should file a bug report to SUN or are they too lazy to respond to serious game programmers like me?
- elias
[/quote]
ROFLMAO.
[quote][…]
DO NOT CUT FPS
why do u wanna cut off the fps rate ? let it flow, u want FPS based movement ? hmmm think about it.
[…]
[/quote]
I cut fps if it makes sense.
In my TinyRivers game I aim for approx 60… and it’s ok that way. On kinda up to date machines it runs with 2000 - 13000 fps and that doesn’t make any sense - obviously
If the window isnt active I cut em even down to approx <10 fps… just enough for beeing able to draw itself (if you move another window infront of it).