Public Group

#### Archived

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

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

## 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 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 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 on other sites
I don''t think having a seperate thread for every object in a game is a good idea.

##### 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 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 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 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?

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

##### 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 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?

1. 1
Rutin
26
2. 2
3. 3
JoeJ
20
4. 4
5. 5

• 9
• 9
• 9
• 46
• 41
• ### Forum Statistics

• Total Topics
631750
• Total Posts
3002062
×