Input via callbacks or functions

G'day,

I've been trying my luck with a bit of simple game development. One thing that has got me stumpted is whether to use callbacks for input, or poll the input and store the values in a table which various functions check.

Basically, my table is an array of:

Code:

struct keyRow_s
{
    int status;             /* if the key is down */
    double lastQuery;       /* last time checked for hit */
};

Then using, pretty much a hash table to lookup the key in the array. Basically, when the user pushes a key should I send the key to either say, the game or a text-edit field based on the state. Or have the game and text-edit 'modules' check for input themselves?

I'm asking because I haven't really seen the method above in other projects (they all seem to use callbacks) -- and I was wondering if it was a wise idea. ie, "tell me when there's input" OR "I'll find out for myself when there's input"?

FYI, I store the last time it was checked so I can control various things like 'sticky keys'.

Code:

/* returns true if a key has been pressed */
int input_keyboard_was_pressed(int key)
{
    float diff = 0.0f;
    double now = 0.0;

    if(key < INPUT_KEYBOARD_TABLE_SIZE)
    {
        if(keytable[key].status == GL_FALSE)
            return GL_FALSE;

        now = timer_seconds_since_start();
        diff = (float)(now - keytable[key].lastQuery);          /* *should* be small
                                                                    TODO: Possible bug if the keys aren't used for hours */
        if(diff >= input.stickyTime)
        {
            keytable[key].lastQuery = now;
            return GL_TRUE;
        }
    }

    return GL_FALSE;
}

Is how I currently do it, and another simple function where time is not important (ie just returns true if the key is down)

The problem with using polls is that you might miss some events. So you have to poll at least as often as you would get events if you used an event-driven system. Additionally, input devices are usually implemented on the hardware level with interrupts, not polls, so it wouldn't really make sense to use polls on the application side.

Any overhead you have from extra polls would be time that could be scheduled for something else.

Polling is actually what you want to do in a game setting. Buffered input works well for applications but not very well for games. During your update you just poll the keyboard and devices to find out the new inputs and respond accordingly. Given that your game normally runs 60 to 100 FPS I'm sure you won't miss any device states.

Hmm thanks.

I've been looking a lot at quake3 recently -- it seems a bit of both methods are used. I only render at 60-100FPS, my 'thinking' is usally 21,000 or so FPS (at the moment). Not sure if that's wise?