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,
Ctrl and
Alt.
I suggest:
int glutGetKeyboard(char key);
int glutGetSpecial(int key);
int glutGetMouseButton(int button);
int glutGetJoystickButton(int button);
to compliement glutGetModifiers...
Cheers,
Nigel Stewart
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
application directly.
I can't think of any reason that this cannot be done in the
client.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
logical way?
One more refinement to my suggestion:
int glutGetKeyboard(char key);
int glutGetSpecial(int key);
int glutGetMouseButton(int button);
int glutGetJoystickButton(int button);
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....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=338692
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,
Ctrl and
Alt.
I suggest:
int glutGetKeyboard(char key);
int glutGetSpecial(int key);
int glutGetMouseButton(int button);
int glutGetJoystickButton(int button);
to compliement glutGetModifiers...
Cheers,
Nigel Stewart
Logged In: YES
user_id=854844
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
application directly.
I can't think of any reason that this cannot be done in the
client.
Logged In: YES
user_id=338692
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,
logical way?
One more refinement to my suggestion:
int glutGetKeyboard(char key);
int glutGetSpecial(int key);
int glutGetMouseButton(int button);
int glutGetJoystickButton(int button);
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....