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

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.

_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.

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

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.

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.

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)...

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

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.

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?