Jump to content
  • Advertisement
Sign in to follow this  
Mastadex

Engine design using multi-threadding.

This topic is 4844 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Im not sure if this is the right place to post this, but I have several questions on how to design a mature engine. Ive made several engines before but they were not efficient and they basically were 'beginner' engines I build from reading books. My first question is timing. different computers will have different speeds at which they render at. So my problem was that on my home computer I was getting a fast speed, but on a friends computer it was unbearable to watch. the frame rate died and with it all animations slowed to a crawl. I though about this long and hard and I was thinking of implementing a multi threadded system with one thread devoted to rendering and one to input or animations etc. I did a search for oppinions on multi threadded engines and there were huge flame wars on how good or bad it is. I just need a concrete answer before i design this engine. Secondly, If threadding is a good thing, how should i break my engine down? I was thinking of making a thread of each one of these areas: Input, Rendering, Sound, Networking. I have done thread programming before so i know msot of the details on how to implement it correctly. Also, would it be a good idea to use hyper threadding for one of these threads, such as sound or input or something... Im trying to make an engine that would be easy to maintain and enchance once I learn about more complex concepts - I/F knematics, scripting, shaders, physics...etc. Lastly, I would like to get a hold of some books that talk about those topics, if anyone would like to suggest any that would be wonderful.

Share this post


Link to post
Share on other sites
Advertisement
You don't need it. My project is very easy to manage, consists of about 135 source files, and has two threads. The second thread is just to update a timer. But if you use QueryPerformanceTimer (?), you won't even need a second thread.

Threads have their uses. They're nice if you want to do background loading of objects. It's easier to put a singe load call into a seperate thread rather than timing it's processor usage then breaking and continuing as your game updates.

But if anything, I would think they make most tasks more complex rather than easier to manage. For example, if you do the background loading, your game world needs to make sure it doesn't mess with the data being loaded until it's ready. A timer variable that is updated in one thread can change between two lines of code in another thread. You have to plan for the fact that the data is dynamically changing outside of the current algorithm.

Share this post


Link to post
Share on other sites
I've used single-threaded engines in the past, and it's really not that much work to get consistent .. uhh, performance across several systems. I say "consistent performance" to mean that while the framerate will change, the objects and animations will move at the same speed, although choppier-looking on slower systems. All you need to do is work out a delta-timing system so that you multiply any rates (such as movement and rotation) by a multiplier that is dependent upon how long it takes to render a frame. That way, an object that moves 60 units/sec will go the same distance in one second, no matter what the framerate is. Even if you used multithreading, you'd have to do the same thing, so multithreading wouldn't really gain you anything.

And another bonus for animations - if you're using the built-in D3DX animation interfaces, the ID3DXAnimationController::AdvanceTime function takes a time delta argument, meaning that all the animations will be automatically "scaled" to fit the framerate for you.

Share this post


Link to post
Share on other sites
Everything is moving towards parallel computing. Good multithreaded design is a must for any engine you are planning to use in the future.
Did someone check the performance lose of using the D3DCREATE_MULTITHREADED flag? I couldn't as I'm just adding a Direct3D renderer to my engine. (Been using OpenGL for years, so hi d3d guys!) [smile]

Share this post


Link to post
Share on other sites
Having multiple threads can be quite useful.. although I would only use a single thread to talk to D3D. Other threads I would use for async file reads, playing sound, database queries, animating bones, etc.. Here are my rules-of-thumb for using threads in a game engine:

* Access D3D from a single thread. Just for sanity.. and so you don't need to use the D3DCREATE_MULTITHREADED flag.

* Access filesystem from a single thread. Multiple threads issuing reads can cause the disk to seek pathologically.

* Don't create more CPU-bound threads than the OS reports CPUs. They'll just compete with eachother in non-cache-friendly ways.

* Use threads to handle any processing which may impact framerate. Design your engine so that it never stalls on data if it can help it. Its often better to just not draw something until it is loaded, than to stall until it is loaded.

* Run your background threads at a lower priority than your foreground (D3D) thread.

xyzzy

Share this post


Link to post
Share on other sites
xyzzy00 basically said what i was kinda thinking. Everything D3D related will be located in one thread, everything else on another.

Is hyperthreadding a good thing to utilize in a game? I know the UT engine uses HT for sound or something along those lines.

Share this post


Link to post
Share on other sites
If you detect an HTed CPU you can use 2 threads instead of one but it is not always worth it. My engine has a scaleable design with variable number of threads depending on the amount of CPUs (logical and physical).

Share this post


Link to post
Share on other sites
vNistelrooy, i would really like to get to know how your engine works, like which areas of the engine will get put into threads if the computer supports it. Is it even worth it, performace wise? for example, using a single thread engine on a multi cpu computer.

But since the new pentium M and pentium D and dual core CPUs that are coming out, it would be a waste to abandon the idea all together...especially with cell processors coming out soon.

Share this post


Link to post
Share on other sites
Well I design my engine for >1 CPU machines, however the performance lose is really minimal in 1 CPU environment.
PM me if you want details. I'm off to bed.

Share this post


Link to post
Share on other sites
Quote:
Original post by vNistelrooy
Everything is moving towards parallel computing. Good multithreaded design is a must for any engine you are planning to use in the future.
Did someone check the performance lose of using the D3DCREATE_MULTITHREADED flag? I couldn't as I'm just adding a Direct3D renderer to my engine. (Been using OpenGL for years, so hi d3d guys!)

It's a very intense performance loss. Like xyzzy mentioned, it is good to keep D3D in one thread, for many reasons. However, WGF2 is being designed a little more towards multithreading, due to the apparent future of computing. So look for peformance to increase before it gets worse [smile]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!