[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Hi,
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.
On Wed, 21 Jul 2004 17:13:52 +1000, Peter Wang <tjaden@xxxxxxxxxx> wrote:
> Chris wrote:
>
> > Peter Wang wrote:
> >
> >> 3. Hey, we only get one shot at this, and it has to be 100% absolutely
> >> completely perfect! Let's restart from scratch... Allegro 5! Hurrah!
> >
> >
> > I pretty much agree right up until this. I definately DO NOT want to
> > start from scratch.
>
> Good, that's exactly what I said :-)
>
> > I personally do'nt care about prefixing from a personal standpoint.
> > However, it becomes obvious that without prefixing you'll run into
> > name clashing. This is why C++ introduced namespaces, this is why
> > internal compiler variables start with _.. to give the programmer more
> > freedom in choosing variable and function names without risk of
> > duplicating something already made by someone else.
>
> Sure, but is it worth the trouble of prefixing the entire API for that?
> Personally, I don't think so. To what extent can a compatibility header
> bridge the gap between a unprefixed API and a prefixed API? It's not
> possible to use inline functions for everything, and the C preprocessor
> is shithouse. How do you handle `key', for example?
>
> Now, we have had clashes with other libraries in the past. Those were
> fixed incrementally, e.g. clear -> clear_bitmap and fhypot -> fixhypot,
> whilst maintaining compatibility. I don't expect very many clashes in
> the future, simply because every other library the user is likely to use
> Allegro alongside will probably have prefixes :-)
>
> > Cleaning up the API would also be a good thing. It's quite poor for
> > today's programs. However, what I proposed isn't too different from
> > what's already being done with the *_ex functions. But instead of
> > merely depricating the old functions, we place them into a
> > compatibility header that is, for now, included by default.
>
> Ok.
>
> Peter
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>
--
V Karthik Kumar