Is there a way to tell from inspection or reflection (within the Java program) on the host computer, how many processors there are?
int processors = Runtime.getRuntime().availableProcessors();
Don't you just love Java for these kind of functions? xD Note that this gives you the number of LOGICAL processors; e.g. my i7 760 gives me 8 logical processors, (4 physical cores) * 2 because of Hyperthreading. That doesn't really change anything though, as I see no reason NOT to utilize Hyperthreading. xD
Using ExecutorService to make a thread pool is also pretty cool. Making new threads repeatedly supposedly has some overhead which can be avoided if you instead take a premade one from a pool. I'm finding ExecutorService is pretty easy to use. (I learned about it via Core Java vol 1--Horstmann).
I've been looking at the standard Executors and ThreadPools, but I believe I need some functionality that is not very well supported in these classes. For example, I'd like all threads to do different parts of the same task. These classes wouldn't be optimal, and I don't think it'll be very hard to write my own thread pool.
Starting new threads every frame would be a very bad idea, as the VM gives no guarantee on WHEN the thread is actually started, only that it will be in the future. In my earlier example, both the worker threads and the culling threads would be either be wait()-ing or locked by a CyclicBarrier
when they are not doing anything. They would only be started once.
Allowing culling to be a frame or more behind (because of thread starvation) seems like a bad idea. If I start turning the camera really fast, I could spin to an area that was culled off the screen the last time the frustum culling was computed. Then nothing would show up for a frame or two and then things would pop into being in the middle of the screen.
Of course it may not be so obvious, it just pop in at the edges of the screen, or you're never actually starving the CPU enough that frustum culling gets far enough behind. It just seems like a recipe for headaches later on.
If you look at my first post I had this in my example code:
The culling results can be either completely correct or one frame old, but never more than a single frame old. Also, I dare you to notice the difference. For RTS-games the problem should be blatantly obvious. If you click on the minimap and move the camera to a whole different section of the map, the old culling results will be completely invalid. Have you ever noticed the screen being completely black for a single frame? I don't think anyone can notice these problems at 60 FPS, though at a really low frame rate it could be a noticeable but then the real problem would be the low frame rate... Speeding up the frame rate in all cases at the cost of quality in worst case scenarios only seems
like a good idea to me.
I believe using one frame old results are standard for both frustum culling and occlusion testing, especially for occlusion testing as it requires two-way communication between the CPU and the GPU. Rendering the occlusion geometry and then immediately asking for the results would starve the CPU while it waits for the GPU to do the actual z-test, and then starve the GPU due to an empty command queue. Waiting a frame before getting the result solves both problems.
IMO, though, a better approach is to use threads to maximize the number of cores used but still require that everything (or all game logic tasks) complete for a frame. You can then have much lower priority tasks, such as texture IO running in the background across multiple frames. If you allow threads to be starved and not have every piece of logic execute at regular times, it seems likely that your games behavior will be non-deterministic and highly dependent on the quality of the player's machine.
Yes, I seem to have forgotten an important part of the game: the game loop.
As I need my game to be deterministic to keep the server and all clients in sync to minimize network traffic I can't use a dynamic delta-time game loop. (I'm practically using the same idea as Warcraft 3 and its infamous 250 ms sync time. xd) I need a fixed frame rate for updating objects to ensure that all clients gets the same result as the server. Currently I am thinking of targeting 30 UPDATES per second. Please refer to the last technique in this EXCELLENT article:http://www.koonsolo.com/news/dewitters-gameloop/
This means that some things will run at 30 FPS (e.g. game state updating), while rendering can run at any speed. I think I'll need to make a list of what has to be done for each update and for each frame to find the best way the utilize threads... I'll be back!
Again, thanks for the replys!!!