Archived

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

Multithread?

This topic is 5505 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. Anyone knows how to start a new thread, possibly without using MFC? I''m speaking of Visual C++ 6... And, in a game, what''s better, menaging all the moving objects in the main loop or with a single thread for each one? Think to Starcraft... "Your time has long pasted... Be gone now... You are ancient history..." - Vampire Night

Share this post

Share on other sites
In Win32 you can create a thread with CreateThread(...) and destroy the thread (which is necessary) by using CloseHandle(...). If you want to steer clear of windows functions, just use the standard _beginthreadex(...) and _endthreadex(...). The parameters are pretty well documented in MSDN except for maybe the security attributes which can be a pain but luckily aren''t necessary for most applications. All functionality of the thread should be encompassed in their respective thread proc.

Share this post

Share on other sites
_beginthread and _beginthreadex are no more standard than CreateThread, it''s just that _beginthreadex is "CRT" aware. If you''re going to be using the CRT in your thread, then you should be using _beginthreadex.

There aren''t any "standard" functions for creating threads and so on since it''s a very platform-specific thing.

If I had my way, I''d have all of you shot!

codeka.com - Just click it.

Share this post

Share on other sites
I don''t think having a seperate thread for every object in a game is a good idea.

Share this post

Share on other sites
Big thing to remember with threads. If they are not done properly (most of the time they are not) they will slow the game/app down rather than increase the speed. I''ve seen some systems that do the drawing in one thread, but the overhead of maintaining syncronization usually isn''t worth it. Also, if it is run on a single processor you will waste a lot of cpu cycles on wait states.

Always remember, you''''re unique. Just like everyone else.

Share this post

Share on other sites
So say I have a shoot function in a 3d shooter -

Every time the Fire button is pressed, I need to calculate ALOT of things, like projectory, collision, bullet count etc.

Now, wouldnt something like this be ideal to be used within a thread?
Therefore all the other objects in the 3D world can be drawn in the main render loop as usual, unaffected or slowed down by this irregular mass of CPU intensive calculations?

In short, I know what threads are, but not when they are best to be used, in, say, an OpenGL application. Any suggestions?

WWW.SPANNERWORX.CO.UK - Coming soon.

Share this post

Share on other sites
Sounds like a good idea to me, but only if you REALLY know what your doing.
Remember that using a lot of threads will cause a lot of thread-switching. This can slow you down if not dealt with properly.
Also, take priorities into account. Don''t just whack a heap of threads together, all of equal priority, and expect it to work well. (Not 100% sure but I think Windows uses a separate Round-Robin queue for each priority so make use of it.)
Collisions may not be easy to check in a thread. Doing so would probably create the need for even more synchronization (between the bullet and all other dynamic objects to check collision with).

quote:

Also, if it is run on a single processor you will waste a lot of cpu cycles on wait states.

I think windows automatically runs the scheduling algorithm whenever a process blocks, so I don''t think cpu cycles will be wasted. (I could be wrong)...

Share this post

Share on other sites
quote:
Original post by tuita
(Not 100% sure but I think Windows uses a separate Round-Robin queue for each priority so make use of it.)
...
I think windows automatically runs the scheduling algorithm whenever a process blocks, so I don''t think cpu cycles will be wasted. (I could be wrong)...

Right on both counts (with regards to NT, anyway).
quote:
Original post by Dark_Streak
Every time the Fire button is pressed, I need to calculate ALOT of things, like projectory, collision, bullet count etc.

Now, wouldnt something like this be ideal to be used within a thread?
Therefore all the other objects in the 3D world can be drawn in the main render loop as usual, unaffected or slowed down by this irregular mass of CPU intensive calculations?

Think carefully about this. Let''s say you are performing your rendering loop in thread X, and your collision detection in thread Y. Suppose thread X is humming along nicely, until you press the Fire button. Then, thread Y kicks into action, sucking up large amounts of CPU time. What happens to thread X? It no longer gets as much CPU time as it did before. Unless your main rendering loop is not CPU bound, you now have two compute-bound threads fighting for the CPU, which is not a good thing. On a multiprocessor machine, this type of threading can often work quite well, but with a single processor, it can be rather troublesome.

ReactOS - an Open-source OS compatible with Windows NT apps and drivers

Share this post

Share on other sites
Ok, I agree with you, the rendering process and the collision engine should stay in the main loop. But, as I told in my first post (see up), think about Starcraft (I say starcraft since I suppose you all know it, right?). Then suppose I have 200 units (max). It''s probably that all those units (especially in 3vs3 games) are shown on the screen. For each of those units, I have to menage in realtime the remaining life, the energy (which is automatically recharged), the AI, the collisions etc... Ah, and the animations, too, which is 2D. So I need to calculate the appropriate frame each loop. What do I choose?

1) All menaged in the main loop. In this way, the main loop must contain a secondary loop as for(int z=0; z TotUnits; z++). Well, cycling throug all those on-screen guys is slow... I could play at 20fps on the latest PC

2) I make 200 threads, every one with the same priority (let''s say normal). If the unit is outta screen, i jump, or better, I pause the thread. But there are 200 loops... How long before the next refresh? Should I buy an Athlon 2700 to play Starcraft?

So, I suppose there should be a faster way to menage every unit.

Share this post

Share on other sites
No need for multi-threading for a Starcraft type game. We''re not talking about an extraordinary amount of processing. Managing animation frames takes no time at all (several milliseconds maybe), same with managing unit stats. Collision detection and AI take a little more processing, but nothing major for a decent mid-range system these days.

What makes you say that managing a lot of units is slow?

Share this post

Share on other sites
Well, I used to program under Visual Basic 6. With DirectX7 a simple SDK exemple, which showed a few non-animated sprites bouncing on the screen, was running at about 60fps here (P2 350Mhz, Asus V7100). Increasing those objects to 90-100, the frame rate went to 30 (!!!). Ok, I know that C++ is more powerful than VB, but try counting the loops needed in a cycle for Starcraft, supposing there are 200 units on screen. If it runs at 40fps, we have 200 * 40 = 8000 loops per second, where 40 are for blitting operations, input... And there is DirectSound which is playing something in background. I don't think all this is possible nowdays, even for C++.

[edited by - AnitraZ on November 19, 2002 9:28:47 AM]

Uhh, yes it is.

Share this post

Share on other sites
Hm very few things are impossible with a computer nowadays.
Some time ago one even sliced me into 240 images and I survived
(it used only 1 thread to do so BTW)

Share this post

Share on other sites
Besides, you probably had vsync on With vsync on, if your frame rate drops slightly the refresh rate of your monitor, you''ll end with half the frame rate. You always have an actual frame rate which is a factor of the refresh rate (i.e. 60, 30, 15, 7.5, etc).

Anyway, that''s not the point. The point is that a game like Starcraft, even with a 1000 units is pretty measly for today''s systems - remember starcraft is a couple of years old now...

If I had my way, I''d have all of you shot!

codeka.com - Just click it.

Share this post

Share on other sites
You only have to check each unit every half a second, not every frame, silly.

Ohhh! I see

• Forum Statistics

• Total Topics
628732
• Total Posts
2984436

• 25
• 11
• 10
• 16
• 14