multithreading

Before using threads, try to figure out if threads are really neccessary to solve your problem. They can often be more pain then gain.

For example, what will happen if the OS decides to let your keyboard thread run slower then the actual game thread? Your keyboard might get polled every second, while the game itself runs at 100 fps. Once the user presses a key, the game will receive the same input 100 times.
If you manually set the keyboards thread-priority higher, your computer might be so busy polling the keyboard that the game runs sluggish...
Clearing the input queue after reading might be a solution, but there''s more trouble ahead...

//thread [1]

input.getKeyboardStatus();

//thread [2]

input.getValue();
game.useValue();
input.clearValue();

//This is what the scheduler might do:


[2] input.getValue();          //there''s none yet.

[2] game.useValue();           //...

[1] input.getKeyboardState()   //hooray, user input

[2] input.clearValue();        //Ooops ;)

Semaphores...

I see nothing wrong with the concept except the main program will need to (a) be told when the next character is ready. Just testing the previous state will miss repeats; and (b) be able to tell the thread that the last character has been taken and the buffer is empty.

For this you might use a global boolean.... set true by the thread when a character is ready, and set false by the application when it is read. (My favourite name for such a boolean is DataReady.)

By this means, your thread can hold a buffer of characters for the application, passing the next one whenever DataReady turns false.

Just an idea.





Stevie

Don''t follow me, I''m lost.

Wildfire,
I would have thought your arguments would have been FOR multithreading. If a user is running on a slower system, and the fps are lower than optimal, then without multithreading the user input will appear sluggish. Using multithreading, and using a thread to poll for input, would ensure that the input would be recieved more regularly wouldnt it? Designing a system to use that input optimally may be a lot harder, but as i see it, it would essentially be frame rate independant.


Aface

Instead of storing it in a variable, use a queue. After you''re read the keypressed, dequeue it, and do the next one.

And the keyboard thread should only clear it after it''s queued.