any success with parrallel threads?
Posted 09 October 2007 - 01:25 PM
get through by splitting it up into threads for my dual core, and hopefully
quad core when I get my next computer.
Id like to hear if anyone has done this and got any success from it, what
it was, how you did it, and how much performance you got from it, because
it would help me out a bit.
Thanks for anyone willing to share anything.
Posted 09 October 2007 - 04:36 PM
Posted 10 October 2007 - 01:10 AM
Im taking a 3d poly object, and converting it to a voxel model by using a 3d triangle raster comparing it to a 256x256x256 array so i dont repeat voxels.
Its taking about 6 seconds to do a 256 cubed sphere.
The Nut- thats a damn shame, I hope I get some improvements. Otherwise
whats the point in buying a dual core if its not much benefit anyway...
Posted 10 October 2007 - 08:05 AM
Actually, that's not entirely true. You won't get much of a speed improvement if you are running at maximal FPS even on a single core already.
However, there are some other advantages in going multithread:
- Logics and rendering frame rate become independent.
This allows for quite high a logics rate (such as 100 logics frames a second), coupled with a much lower rendering frame rate (30 frames per second). This might just be a personal feeling, but the game seems to respond more fluidly if the logics framerate is that high.
- Logics doesn't break in when rendering does.
There might be small in-between peaks in rendering (such as looking around in a terrain) and your rendering time will fluctuate rapidly. This actually causes much more visible "lag" than just a low FPS. In a single-threaded design, this lag also grows into your game logics, which adds to the unfluid feeling and may give problems with other timing-critical code, such as networking. Multithreading however, takes some of this problem off by distributing time among your threads.
(Note you could simulate both by just storing all rendering commands, and processing a certain number of these after each logic frame, but it's more complicated than multithreading, and you don't use that second / ... / core of your computer -- just running a rendering frame every n logic frames does give a little hickup if rendering takes too long)
- Loading screens are so much nicer to add when your rendering system is already multithreaded. Just pass control of the renderer to an extra thread (loading thread), which then can do some sort of animation while your main program thread parses game data.
However, I'm not sure if that is worth the extra code and extra design needed for implementing a threaded solution - after all, it's more difficult to ensure the correctness of a multithreaded application versus the correctness of a singlethreaded one.
For a simpler problem (and a basically parallel one!) such as the 3D rasterization problem provided by the original poster, threading definately is the way to go.
Posted 19 October 2007 - 07:55 AM
So splitting your logic from your render on different cpus makes a lot
of stuff easier to do.
I definitely might implement it next time im writing a game.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users