Re: [AD] Proposal for first step towards new api

["Henrik Stokseth" <hstokset@xxxxxxxxxx>]

Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote:

> I personally would be more conservative: I'm rather for:
> - just adding 'al_' to every platform-independent symbol:
>     adjust_sample --> al_adjust_sample
>     getpixel --> al_getpixel
>     _getpixel --> _al_getpixel
<snip>
> - using a special rule for platform-specific symbols, in order to make
> them more distinguishable:
>     win_get_window --> alwin_get_window
>     qnx_get_window --> alqnx_get_window

this makes much sense to me, however in the spirit of prefixing thing i'd
prefear that internals were prefixed with alint_ rather than _al_. don't you
think so too?

Also, all defines and variables will need to be prefixed of course. but if
we just al_ prefix them or do alvar_variablename or aldef_definename or
something simmilar can be discussed. it's perhaps a good idea if it can make
generation of export definitions simpler?

Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:

> A couple thoughts:
> o al_main(int argc, char **argv) - new initialization func.
>                 called by real main() (no need for END_OF_MAIN() with
this)

I'm afraid it's a bit harder than that. END_OF_MAIN() does two things. it
renames the users main function to mangled_main and then it defines it's own
OS specific entry point which in turn calls mangled_main. I will see what I
can do about rewriting the existing hack to use al_main() and eliminate the
need for END_OF_MAIN().

> o al_adjust_sample/adjust_sample - should be removed in favour of the
easier
>                  and more powerfull voice api (as per Shawn's suggestion.)

now is a good time to give the audio API an overhaul indeed, if somebody
voluntairs.

> o al_clear - gets obliterated. (replaced by al_clear_bitmap)

of course, there's no need to keep such API backwards compatibility macros
laying around anymore.

> o most of the cpu/os vars can be removed.

be careful about removing too much here. think objective: what can be useful
to have here as a game programmer for instance to code os-specific
workarounds or to code optimalisations for mmx processors or different
generations of intel compatibles?

Sincerely Henrik Stokseth.
-----------------------------------------------------------------------
E-mail: hstokset@xxxxxxxxxx  Homepage: http://hstokset.n3.net