Sign in to follow this  

SDL - simple beginner questions

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

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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by Coder21
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?

While I have to agree with Sutter that concurrency is the future of computing, I don't think that you as a game programmer should worry about it, unless you have events that must be handled asynchronously.

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()??

I'm by no means an SDL expert, but what exactly is the problem? SDL_PollEvent is supposed to return no events if none events are available; its very purpose is to check to see if there are any pending events but continue if there aren't. In a game, you don't want to wait for user input: Handle it if it's there, otherwise go on and wait for the next iteration to check again.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by Coder21
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.

Which is, of course, why you use SDL_PollEvent.

Quote:

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

That's pretty much how it's done.

  • Get user input, if any

  • Respond to user input

  • Update game state, including enemies etc.

  • Repeat

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by Drew_Benton
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.

Even the P4 only has a single core, though the hyperthreading unit apparently allows several threads to execute in parallel, to some degree—but it's still only one processor. The CPU's slated to hit the market this year are dual core CPU's, not quad core, and will be more or less equivalent to dual processor systems. (I've no idea if or how hyperthreading fits into Intel's scheme; I'm no hardware guy.) Of course, it's already possible to run multiprocessor systems (and today's N-socket 939 boards are tomorrow's 2*N CPU boards ...).

Quote:

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?

Of course, it gets worse. If you did have a multiprocessor system, you'd have a nightmare of locks with any shared/global data structures, and thread synchronisation; it's tricky enough, sometimes, with simulated concurrency, but gets worse with the real thing.

As a general note: Concurrency is a wonderful thing, but some problems lend themselves more easily to parallelisation—and some not at all.

Share this post


Link to post
Share on other sites

This topic is 4689 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this