Get the state of a key instantenously.
int GetKeyboardState(char Keyboard);
Logged In: YES
Yes, I agree that FreeGLUT should track keyboard state and
provide an alternative to individual key up/down events.
For interaction-intensive applications such as games,
multiple keypress combinations are common.
There is already a glutGetModifiers interface for Shift,
int glutGetKeyboard(char key);
int glutGetSpecial(int key);
int glutGetMouseButton(int button);
int glutGetJoystickButton(int button);
to compliement glutGetModifiers...
Logged In: YES
IMHO, adding such a feature to freeglut adds undue
complication, especially since you already get it in the
event-driven code that is at freeglut's core.
If this is such an issue for some, perhaps we can provide an
"example" program that shows how to track this state
information---and allows the (few, I think) programs that
need this feature to just snarf the code into their
I can't think of any reason that this cannot be done in the
Certainly an example program would help with this,
but it would be certainly more convenient for
FreeGLUT to support this directly, rather than forcing
cut-paste-maintain code re-use.
This is probably a more widespread issue than it may
seem - many games actually poll the entire keyboard
state rather than handling individual events - I would
like to see FreeGLUT evolve to accomodate these styles
of interactive 3D applications. (I have students every
semester that complain that the event handling model
is inconvenient for their purpose) (I have also seen this
popup in the OpenGL newsgroups from time to time)
Considering that supporting this extension to the API
is orthogonal and complementary to the event-oriented
handling approach - is there a good reason that this
_shouldn't_ go into FreeGLUT?
Put another way -
Should glutGet(GLUT_WINDOW_WIDTH) be removed
from the GLUT API simply because this could be
tracked by the client via the resize callback handler?
Isn't it a benefit to code clarity that the GLUT API
is rich enough to provide this kind of query in a tidy,
One more refinement to my suggestion:
Where each returns the elapsed time in milliseconds
since the key/button was pressed, and zero indicates
that the key/button is not currently pressed.
Am I willing to code this up myself? Well, not this week,
but eventually - yes....