hey everyone, I just started to learn game programming with SDL and i have some simple questions : 1. I know that threads are good to use with real-time counters in games , but how about enemies? shall i create a seperate thread for each enemy that will appear in the screen or what? 2. I've read that SDL_PollEvent() keeps returning no events (unlike SDL_WaitEvent()) wich consumes the whole CPU , how do i get around this problem with SDL_PollEvent()?? any help is much appreciated [Edited by - Coder21 on February 12, 2005 10:43:04 AM]

1) Short answer: no.
Long answer: The cpu switches between the threads to simulate multitasking
and this cost cpu cycles and having one thread for each enemy would cost to
much.

2) I don't have all this in the head but there are easy to udnerstand examples at
www.libsdl.org.

So shall i use one thread for all of the enemies for example?

I don't need examples for the mouse btw , i just want to know how to get the y and x axis of a click via the SDL_Event structure

*EDIT* i found out about the mouse.

[Edited by - Coder21 on February 12, 2005 10:26:26 AM]

To prevent your program from consuming 100% CPU just add a small delay to the end of your game loop - somethin like SDL_Delay(50); which shouldn't cause too much of a performance hit.

That works spudder , but it makes the game much slower. Any other solutions?

Quote:Original post by Coder21
1. I know that threads are good to use with real-time counters in games , but how about enemies? shall i create a seperate thread for each enemy that will appear in the screen or what?

I think the only things that you would ever need threads for is if you had networking code in your SDL game, and that's assuming SDL_Net or whatever library you use doesn't already operate that way. Other than that, threads will just kill your SDL game. SDL is built upon a base that does not support threads, so adding in the threads to it will not really help out - assuming you are making a 2D game. If you are making a 3D game using OpenGL via SDl, then you may have some uses for SDL.

Quote:
2. I've read that SDL_PollEvent() keeps returning no events (unlike SDL_WaitEvent()) wich consumes the whole CPU , how do i get around this problem with SDL_PollEvent()??

Let me explain. SDL_WaitEvent "Waits indefinitely for the next available event, returning 1, or 0 if there was an error while waiting for events." Now this is fine for some little SDl app that doesn't do much but it is horrible for a game if you want to do other things in the game. You will be wanting to do more than just collect events if none are present, If you use this function, you will not be able to process other stuff correctly.

Now SDL_PollEvent "Polls for currently pending events, and returns 1 if there are any pending events, or 0 if there are none available." This is *exactly* what you want to use for a game. If you poll for events, and there are none, then you go on with your drawing and processing loop. If there are events, you simply handle them, but you will always know since poll event will return true or false if there are any events.

However Since you do not want to use a lot of CPU as you have said, replace the PollEvent with WaitEvent. Normally you would have this:

while ( SDL_PollEvent(&event) ){   ... Code for events ...}

Now you will just have something like this:

if( SDL_WaitEvent(&event) ) // 1 is no error and 0 is error I believe from docs{   ... Code for events ...}

I could not suggest adding a delay to the end of your game loop simply because you never know how it is going to affect all computers. I know on mine (3.4 P4) it will not matter one bit, but on a slower one, it *could* kill your game logics/graphics if you did not test it on various computers, but that's just my opinion.

- Drew

Thanks for replying Drew and Miserable.

The problem with SDL_WaitEvent() is the fact that it "delays" the program untill an event occur , so basically none of the things that come after WaitEvent() will show up untill it gets an event.

Now if threads aren't good as you say, then how do i update a few enemies on the screen at one?

I'm thinking of a primitive method to do this. Assume we have 3 enemies in the game :

1. Update enemy 1 coords
2. Update enemy 2 coords
3. Update enemy 3 coords
4. Blit enemy 1 in updated coords
5. Blit enemy 2 in updated coords
6. Blit enemy 3 in updated coords

is this the right way to do it? because (apparently) enemy 2 won't move untill enemy 1 does , so i don't know

Quote:Original post by Miserable
...

Agreed! I Couldn't have said it any better.

Quote:Original post by Coder21
Now if threads aren't good as you say, then how do i update a few enemies on the screen at one?

Now it's not that they aren't any good. I think you do not have a full understanding of how threads work. On windows, even though it is a 'multi-threaded' system, general threads are still executed one at a time. This is because most computers do not have 2 cores/cpus to work with. I know on my P$ w/ HT, I can do 2 because it is the way it is engineered. On the new computers that are soon to come, they will have 4 cores so they can execute 4 at once.

Now with that really vague and probabally politicall incorrect background, this is how it would work in your game without threads.

Main Loop   - Process      - Input      - ...   - Update      - Enemies1, ..., EnemiesN      - Player      - ...   - Draw      - Enemies1, ..., EnemiesN      - Player      - ...

And that's it. You just have one function that goes through the process of everything it needs to do with no overhead.

Now I cannot illustarte the same W/ Threads because of the complexity, but it gets more confusing and complex. Basically if you had a threaded system, you would launch a thread for every enemy. This adds additional memory and cpu usage. Now you must sync all of the enemies so that they are only updated once per frame, this adds more cput and memory processing. Then you must make sure that all threads have finished before you can continue on in the main loop, drawing everything, once again more cpu and memory usage being wasted. Do you kind of see what I am talking about?

Yuu know that you need to update and draw your game logics in a certain order and a limited amount. You don't want the draw function to draw twice a frame and the update function only update once per 3 right? Threads will not help you in this situation. I hope this explanation is sufficient enough. If it is not, then by all means, try to use threads and you will see what I am talking about.

- Drew