| Re: [AD] Proposal for first step towards new api |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Sven Sandberg wrote:
[snip]
I agree with what was above and below this.
What should we do about the order of arguments to draw_sprite() & co? It
would be good to always have source before dest IMHO. But I also think
that we should rename (not only prefix) each function that changes
behaviour, because otherwise people will do an automatic search and
replace and not understand why it doesn't work any more.
What about removing draw_*_sprite and using blit() for everything? This
would mean that blit would also hanble RLE & compiled bitmaps (which is more
consistent). We could also add a al_blit_trans() function, which would be
equivalent to draw_trans_sprite(), but have the extra clipping parameters.
[snip]
Is `xor_mode()' still useful? I don't mean we should remove the ability
to draw xor'ed, I mean we should force people who draw xor'ed to use
`drawing_mode()', because I think it is a too uncommon thing to do to
have a shortcut for it.
Yes. Perhaps this could also be collapsed with the blenders too?
al_set_blender(AL_BLENDER_XOR)?
[snip]
Do you think we should change e.g. `int key[]' to
`inline int al_key_is_down(int)' or something like that? It seems a bit
more logical because you shouldn't write to it and it's not _that_ time
critical. The full list (I think) of such variables would be:
Yes, this would remove the 'volatile' constraint, which makes Allegro more
portable to other languages which don't know about volatileness :)
DIALOG *active_dialog --> DIALOG *al_active_dialog()
MENU *active_menu --> AL_MENU *al_active_menu()
Could we make a destination bitmap argument to al_do_dialog()? I think this
is better than the have the user overwritting 'screen' to a memory bitmap.
int cpu_capabilities --> int al_cpu_capabilities()
Right, but I want a regular int somewhere inside Allegro to handle the asm
code. Also, this would reduce some of the performance of add-ons (like
FBlend), since there's an extra function call to do per blit, although it's
not *that* significant. Every bit helps :)
int cpu_family --> int al_cpu_family()
int cpu_model --> int al_cpu_model()
char cpu_vendor[] --> const char *al_cpu_vendor()
It's like to see those go away. They're too unflexible, and don't serve any
useful purpose. I'd rather see a single user parsable string instead. This
would allow extension to other platforms. Plus, it's not very time-critical.
int os_multitasking --> int al_os_multitasking()
int os_type --> int al_os_type()
int os_version --> int al_os_version()
int os_revision --> int al_os_revision()
Can we do the same here? This is really not time critical, so it can all be
put in a string.
volatile int retrace_count --> int al_retrace_count
Can we use a (say) 100 Hz timer instead? This would allow user programs to
sync themselves without the need to hook their own timer routines, since
Allegro already does it.
Is it really all that useful to have it perfectly synched to the vretrace?
[snip]
I also think it can be good to wait a little more to actually implement
everything, until 4.0 feels more stable, so that we reduce the number of
bugfixes that need to be applied to both prefixed and non-prefixed
versions. Sure, it will be a nice improvement, but if we lived with the
old API for years it can't hurt to keep it a month or so more. It's not
like it seems likely that people are going to forget about it :-) But
it's of course still a good idea to discuss it.
I agree. Someone should keep a list of stuff to do though, so we don't forget :)
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/