OpenGLEAN
OpenGLEAN User Support
Home page | Introduction | Documentation | Files | Examples | Proposals | Authors | Links


OpenGLEAN Device Support Development
Summary | CVS | (discussion via home page) | (contact via home page) | (suggestion box) | License | Todo | Bugs

Todo List

The latest list is available at http://OpenGLEAN.SourceForge.net/dev/todo.html.

Global gleandevGetd
Consider moving to a table-based approach rather than a switch(), letting us move to modular functions.

Add queries for all of the other joystick parameters that are available in glut* functions in joystick.c.

Change the ogWarning() calls to silently set a queryable gleandev error-condition so that you can do something like gleandevGeti (GLEAN_GET_ERROR). There's really no need for this function to print anything.

Global gleandevSetd
Change the ogWarning() calls to silently set a queryable gleandev error-condition so that you can do something like gleandevGeti (GLEAN_GET_ERROR). There's really no need for this function to print anything.

See also:
gleandevGetd(), gleandevSetf(), gleandevSeti()

Group joystick
Generally for many joystick functions: Need to add checks on the ident and axis numbers to be sure that they are in-range.

The old GLUT API for joysticks used timer-based pseudo-events. But ultimately, GLUT would poll the hardware for joystick events. A preferable API would perhaps have been to define functions to allow the application to poll the joystick, and let the application use GLUT timers scheduling the pseudo events, if timer-based checks are desired.

freeglut defined, but did not originally implement an extended API for pollinng the hardware. The definition was informal, in the form of stubbed out functions at the bottom of joystick.c. In 2004, John Fay re-implemented the freeglut joystick support, and added support for these stubbed functions.

OpenGLEAN inherited both of these API forms indirectly through OpenGLUT. OpenGLEAN had intended to expose and support these functions in a separate joystick-only library. In response to what seemed a consensus amongst freeglut developers to move forward with exporting that API, OpenGLEAN opted to expose the same API in order to avoid a compatibilit gap. After a month or two of discussion, but before any release from freeglut with this feature, OpenGLEAN finally added the functions---and literally on the same day, the freeglut project leader turned freeglut away from exporting the API.

On the one hand, this has resulted in OpenGLEAN adding under-designed features that freeglut seemed to want to include. On the other hand, now that freeglut is backing away from their API extension, and gleandev in a very experimental state, gleandev has revised the joystick API substantially.

The old GLUT API is still available in the OpenGLEAN core library as of this writing---and will remain so up through OpenGLEAN 1.0. But a more flexible API is now provided in gleandev.

The new API is two-pronged: One side is a revised set of functions (due to be renamed to avoid historic conflict with freeglut); these form a small constellation of joystick-related functions. The other side is a gleandevGet*() suite of functions, after the style of glGet*(), and likewise a gleandevSet*(). The latter part is more in keeping with OpenGL and the GLUT approach, so will probably be used in preference to the former---though a way to read multiple joystick axes at once (and perhaps support for arrays for reading multiple joystick buttons, rather than bitmasks) may be added.

See the Deprecated API Features section.

Global glutJoystickInit
If there is any library-wide initializion to do, it should be in a function that is not joystick-specific. Library-wide initialization should not be presuming exactly 2 joysticks. So this function should probably vanish, though in practice it is presently required.

Global glutJoystickOpen
Probably should either dispense with the explicit open call, or else have the open call return the descriptor. Possibly allow the client to have some say over what kind of joystick is being sought, as with windows. (E.g., number of axes could be a client criteria. Or possibly the client could even prefer/require a USB joystick, letting the client first request USB sticks, then after opening all that it can, switch to unqualified joysticks.) Certainly, as long as the client is requesting the joystick by number, there needs to be a way to (a) find out how many joysticks are available and (b) indicate success/failure.

Global glutJoystickReadAxis
Should provide a means to store the joystick data for all axes and require an explicit "nudge" to re-read the data. Re-reading all axes, correcting them, then throwing away all but one axis's worth of information seems silly. However, for now I'm willing to assume that there are no significant performance impacts. Then again, maybe oghJoystickRawRead() can be made to only read selected bits of info?

Global glutJoystickReadButtons
Should provide a means to store the joystick data for all axes and require an explicit "nudge" to re-read the data. Re-reading all axes, correcting them, then throwing away all but the button information seems silly. However, for now I'm willing to assume that there are no significant performance impacts. Then again, maybe oghJoystickRawRead() can be made to only read selected bits of info?

Global glutJoystickShutdown
Maybe instead just close inidividual joysticks? And/or have a global gleandevShutdown() that supports all devices?





SourceForge.net Logo Supported in part by SourceForge.net.

Generated on Fri Sep 9 18:01:32 2005 for gleandev by doxygen 1.4.3
The OpenGLEAN project is hosted in part by SourceForge.