[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, 2004-07-21 at 01:04 -0700, Chris wrote:
> guilt wrote:
> > We can handle it the way DirectInput does :) It will be useful to the
> > user if he could have a method for setting keyboard buffers. The
> > dinput methods allow u to pass a 256 byte buffer and retreive the key
> > scancodes in them. Why not have such a thing in allegro itself? It
> > doesn't look robust to me when we have access to pointers such as in
> > screen, desktop_palette, font or key. (Then, logically, it must have
> > also been possible to directly writ to the sound device, right?)
> >
> > So please consider the more robust, but less faster alternatives.
>
> I don't mind access to the global pointers. IMO, using functions like
> get_key_array are rather inefficient for low-level programming. The key
> array, the screen bitmap, etc, are designed to hold real-time data..
> showing the state of the device at any given moment in time. Polling
> goes counter-intuitive to this, and IMHO, should be avoided unless
> there's no other choice. Allegro has been, and should continue to be,
> designed to give the programmer low-level access.. as low-level as
> possible given the OS, anyway. If the programmer wants to implement a
> polling scheme on top of this, then great. But it shouldn't be Allegro's
> job to do it.
>
To me, global variables just don't look clean. So instead of key
[KEY_ESC], you'd do al_key(KEY_ESC). It just looks cleaner to me, no
performance or functional or other difference.
For screen, I'd have: screen = al_set_graphics_mode (..); It would be a
normal user variable the user can name however he/she wants. Or maybe
screen = al_get_screen(); Or screen = al_get_pointer (AL_SCREEN);
Font would be handled the same, as well as palettes. al_get_font().. or
maybe even al_get_poinet(AL_FONT). There won't be any performance
difference - just a cleaner and much more appealing API. Right now some
things just feel messy and hackish.
--
Elias Pschernig