Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualServant of the Lord

Posted 29 January 2013 - 08:59 PM

You don't want to 'store' it anywhere, because it's something you use and then discard. It's not supposed to persist for longer than the event-handling code persists. 

 

Perhaps something like this:

 

//Your main loop:
while(the game is running)
{
    //-------------------------------------
    //Handle all the events.
    //-------------------------------------
    
    SDL_Event event;
    while(SDL_PollEvent(&event))
    {
        //Hands the event (temporarily!) to the GameState. GameState doesn't store it anywhere, it
        //just uses it then returns. GameState also hands the event (temporarily!) to other class' HandeEvent() functions so they also have a chance to deal with events.
        gameState.HandleEvent(event);
    }
    
    //-------------------------------------
    //Handle all the updating.
    //-------------------------------------
 
    //Hand the current time to the gameState to update itself. It'll pass the time along to other class' Update() functions.
    //I personally prefer converting the SDL_GetTicks() result to a float first and dividing by 1000, I find it easier to work with. (1.0 equals one second. 0.5 equals half a second, and so on).
    gameState.Update(SDL_GetTicks());
 
    //-------------------------------------
    //Handle all the drawing.
    //-------------------------------------
    
    //Clear the screen.
    SDL_FillRect(screen, ...);
    
    //Hand the GameState the SDL_Surface, temporarily!
    //GameState uses it and hands it (temporarily!) to other classes that need it.
    gameState.Draw(screen);
 
    //Apply the changes by swapping the double buffer.
    SDL_Flip(screen);
}
 
It doesn't have to be exactly like that, but that's the general idea. SDL_Event is only valid from one call of SDL_PollEvent() to the next, so it should be held onto indefinitely, just used and discarded. Actually, we use and reuse and reuse it until there are no more events to process, then it gets discarded at the end of the loop, then created at the start of it again, but that's just semantics. happy.png
Mentally, we use it once then we discard it and get a new one for the next event, though in actuality it is reused.
 
SDL_Event is only valid from call to call of SDL_PollEvent(), and is invalid after the last SDL_PollEvent() call for that frame. By keeping SDL_Event local to your main loop, you enforce that it is only used inside of HandleInput() calls, which is good, because any usage outside of those calls will give buggy results. Instead of monitoring your own code usage, "Am I even able to use my global SDL_Event during this function or is it invalid?", you make your compiler work for you, and give a compiler error in situations were you can't use it. smile.png
 
In my previous post I said, "I like it when my program tells me what the problem is, rather than me having to spend time hunting for the problem".
I like it even better when my compiler won't even let me compile certain kinds of mistakes, when I am able to enforce safety in code (which isn't always possible).

#1Servant of the Lord

Posted 29 January 2013 - 08:58 PM

You don't want to 'store' it anywhere, because it's something you use and then discard. It's not supposed to persist for longer than the event-handling code persists. 

 

Perhaps something like this:

 

//Your main loop:
while(the game is running)
{
    //-------------------------------------
    //Handle all the events.
    //-------------------------------------
    
    SDL_Event event;
    while(SDL_PollEvent(&event))
    {
        //Hands the event (temporarily!) to the GameState. GameState doesn't store it anywhere, it
        //just uses it then returns. GameState also hands the event (temporarily!) to other class' HandeEvent() functions so they also have a chance to deal with events.
        gameState.HandleEvent(event);
    }
    
    //-------------------------------------
    //Handle all the updating.
    //-------------------------------------
 
    //Hand the current time to the gameState to update itself. It'll pass the time along to other class' Update() functions.
    //I personally prefer converting the SDL_GetTicks() result to a float first and dividing by 1000, I find it easier to work with. (1.0 equals one second. 0.5 equals half a second, and so on).
    gameState.Update(SDL_GetTicks());
 
    //-------------------------------------
    //Handle all the drawing.
    //-------------------------------------
    
    //Clear the screen.
    SDL_FillRect(screen, ...);
    
    //Hand the GameState the SDL_Surface, temporarily!
    //GameState uses it and hands it (temporarily!) to other classes that need it.
    gameState.Draw(screen);
 
    //Apply the changes by swapping the double buffer.
    SDL_Flip(screen);
}
 
It doesn't have to be exactly like that, but that's the general idea. SDL_Event is only valid from one call of SDL_PollEvent() to the next, so it should be held onto indefinitely, just used and discarded. Actually, we use and reuse and reuse it until there are no more events to process, then it gets discarded at the end of the loop, then created at the start of it again, but that's just semantics. happy.pngMentally, we use it once then we discard it and get a new one for the next event, though in actuality it is reused.
 
SDL_Event is only valid from call to call of SDL_PollEvent(), and is invalid after the last SDL_PollEvent() call for that frame. By keeping SDL_Event local to your main loop, you enforce that it is only used inside of HandleInput() calls, which is good, because any usage outside of those calls will give buggy results. Instead of monitoring your own code usage, "Am I even able to use my global SDL_Event during this function or is it invalid?", you make your compiler work for you, and give a compiler error in situations were you can't use it.
 
In my previous post I said, "I like it when my program tells me what the problem is, rather than me having to spend time hunting for the problem".
I like it even better when my compiler won't even let me compile certain kinds of mistakes, when I am able to enforce safety in code (which isn't always possible).

PARTNERS