Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

JoshG

Review Engine

This topic is 6107 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

Hello, I''ve been experimenting with the idea of building a game engine for the experience. I want it to be 3D and to be in OpenGL. I have had a few ideas in the way that i would implement it, and seeing I have had no previous experience doing such a thing, I''d like your opinions. I was planning on spliting the engine into 5 threads. (is this a common thing to do?) Graphics Thread (o) - Manages displaying things on the screen Sound Thread (o) - Manages playing sounds Input Thread (i) - Takes input from user and changes required values Physics Thread (io) - Manages projectiles, and Particle Emitters Network Thread (io) - Manages getting updated information from the network Each thread would hold a pointer back to a class full of values that can be altered by any thread, and then be displayed by the other treads. Each main function of the thread would be placed inside a .dll file, so they can be changed easily and updated. I was wondering if this kind of design would have any effect on performance, ie, does it sound like it will be slow? are there any other common methods for implementing an engine? I''ve heard of Finite State Machines, but I''m not quite sure I want to go there. Thanks for your input! --Josh

Share this post


Link to post
Share on other sites
Advertisement
Decoupling the physic''s calculations from the graphic''s rendering isn''t a great idea, unless you plan on optimizing for and runniing on SMP computers. There''s nothing new to show if the tokens haven''t moved.

A high priority thread to fill sound buffers is a virtual requirement, as such many APIs provide this functionality. If you haven''t finished the physic calculations, you can''t make (good) decisions about sound sources.

Whether or not an input thread is needed depends on the API and your timing requirements - the best you can do (again without SMP) is buffer the input and give it a better time-stamp.

A pool of threads to handle network IO is generally used for high-performance applications. I''ve seen them simply de-serailize the packets out of the low-level IO buffer to be processed by the game-loop later, and seen them parse the packets and buffer events for the game-loop to handle later.

Share this post


Link to post
Share on other sites
So you are saying I should probably have:

Graphics/Physics/Input thread
Sound Thread
Network Thread

is that right?

What is your opinion on having the threads in Dlls?

Share this post


Link to post
Share on other sites
You can also put the network stuff in the graphics/game logic thread. In the network code you usually look if you received any packets and you send a packet to the server with your new gamestate. This is not really timecritical and can be done once each frame.

Also, these threads should share the same process. There''s no need to make them external.




Share this post


Link to post
Share on other sites
Strange, I posted a reply last night but it must not have gone through... so I guess I''ll do it again.

quote:
Original post by Magmai Kai Holmlor
Decoupling the physic''s calculations from the graphic''s rendering isn''t a great idea, unless you plan on optimizing for and runniing on SMP computers. There''s nothing new to show if the tokens haven''t moved.



I don''t have a lot of experience in this area, but it seems to me that it''s best to decouple the physics from the graphics.

IMO, you should update all your objects at once using the physics module. Then you shold go through and pass all your objects information to your graphics renderer which should just hold everything in a linked list or something. When everything is done being passed, the renderer can sort them by model and texture, and do whatever else it wants to gain a performance increase. Then it would go and process and display the data.

As far as nothing new to show if the tokens haven''t moved, most games redraw everything (with the possible exceptions of menus) every frame, because the screen is constantly moving. Not to mention that if nothing on the screen changes position then it doesn''t matter if you redraw everything because nobody would even notice if you were running at 1 fps or not . Either way, even if an object hasn''t moved how are you going to know whether or not another object was in front of the first object and has since moved out, so it needs to be redrawn? I thought the graphics card takes care of the z-order stuff for you?


- Houdini

Share this post


Link to post
Share on other sites
Putting each thread in it's own dll isn't a bad idea - you could also make it one dll with a different exported function for each thread. (Using dlls doesn't mean you need more than one process if Countach gave you that impression. Using more than one process _would be a bad idea.)

If using threads can eliminate some FSMs, and doing so doesn't significantly impact the performance, use them.

quote:
Original post by Houdini
IMO, you should update all your objects at once using the physics module. Then you shold go through and pass all your objects information to your graphics renderer which should just hold everything in a linked list or something. When everything is done being passed, the renderer can sort them by model and texture, and do whatever else it wants to gain a performance increase. Then it would go and process and display the data.


In other words, they're tightly-coupled with respect to execution order (which is the topic at hand, i.e. threading). It's a very good idea to seperate those things in the code, but Josh was asking about breaking them into seperate threads.

If their execution order were decoupled, you could draw them and move them in any order, at any time - a very useful thing if you have one or more additional processors to throw at the physics processing. That way the physics engine could be churning away, while the GPU and other CPU rendered the intermittent state.

quote:

Either way, even if an object hasn't moved how are you going to know whether or not another object was in front of the first object and has since moved out, so it needs to be redrawn?


One of the many reasons why you _don't want to use multiple threads for rendering and physics.

On a single processor machine there's some decoupling if you don't wait for v-sync and have a GPU (>=GeForce), as the rendering will happen asyncronously. If that call blocked you would want seperate threads. Well... you could block waiting for v-sync, and run the game-loop/phsyics thread in the mean time... that way you only render once per monitor refresh. The problem is getting all the timing right to actual present infomation with less latency. It may end-up being alot of work for a poorer visual effect.

It may be possible to tweak performance using a multi-threaded system (definetly on a SMP machine) but it wouldn't be a trivial task.


Magmai Kai Holmlor


Edited by - Magmai Kai Holmlor on December 30, 2001 4:31:45 AM

Share this post


Link to post
Share on other sites
ok, I''ll keep the functions in the dlls if it won''t cause a performance drop. the main reason I had them in the Dlls was for easy Update of the engines.

I''m not going to have the game on computers with more than one processor, Unless they decide to become allot cheaper in the next few months.

So you are saying i SHOULD use threads?
What kind of execution order is common?
ie:
Process Input
Process Physics
Render

meanwhile there is the Network and sound thread in the background?

--Josh

Share this post


Link to post
Share on other sites
Ah, you are absolutely right Magmai, the physics and graphics renderer definately should be kept in the same thread.

However, I do think we were refering to different kinds of coupling. I still think the physics and renderer should not be coupled together, as in they shouldn''t know about each other. The execution order would be taken care of by a mediator of some sort. I think you were refering to coupling thread wise tho, in which case you are right.


- Houdini

Share this post


Link to post
Share on other sites
quote:
Original post by JoshG
ok, I''ll keep the functions in the dlls if it won''t cause a performance drop. the main reason I had them in the Dlls was for easy Update of the engines.

I''m not going to have the game on computers with more than one processor, Unless they decide to become allot cheaper in the next few months.


The Athlon MP will do this whenever it''s finally released and widely available. ~$600 will get you a MP mobo and two CPUs.
9x doesn''t support multiple processors, btw.

quote:

So you are saying i SHOULD use threads?
[/quotw]
Yes, a few.

[quote]
What kind of execution order is common?
ie:
Process Input
Process Physics
Render

meanwhile there is the Network and sound thread in the background?


Sounds good



...
quote:

However, I do think we were refering to different kinds of coupling.


We definetly were

Share this post


Link to post
Share on other sites
I know of at least one recent major game release that uses only one thread in single player, with an additional thread in multiplayer for handling the communication.

I think its wise to try for one thread and add threads when their need really becomes apparent.

This single-threaded game (Battlezone II) does encounter frame-freeze when certain files loaded, i.e. a sound played for the first time. Therefore a helper thread or two may have been in order to alleviate that. I would restrict those new threads as much as possible to prevent collisions.

My approach is to add additional threads as you encounter the need or benefit. There is great comfort in having only one thread. I don''t think I''d plan 4 or 5 threads up front in the design, without a solid justification for each added thread. I welcome any other viewpoints on this though.


Share this post


Link to post
Share on other sites

  • 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!