Re: [AD] Function parameter ordering conventions

["Stephen Apostolopoulos" <stapostol@xxxxxxxxxx>]

On Thu, 21 Jun 2007 19:27:38 (or close to it) +0300, Elias Pschernig  
<elias@xxxxxxxxxx> wrote:

> As I said, they're completely different types of things. To me, saying  
> that they should be treated the same sounds like over designed forced  
> object oriented programming. Object oriented is good, but it shouldn't  
> be overdone. Treating colours on the same footing as bitmaps is  
> overdoing it.

Venturing off-topic now, but what is AL_COLO(U)R missing compared to  
AL_BITMAP? Both are structs with a range of functions that operate on them  
- the distinction between object and attribute is arbitrary, *BUT*:

> That just made me think of something - assume a hypothetical function to
> draw a tinted bitmap, it could then consequently be:
>
> al_draw_tinted_bitmap(AL_BITMAP *bitmap, int x, int y, AL_COLOR *color)

This is a very good example where this distinction makes sense. Which  
means the rule:

"[object - ] position(s) - attribute(s)"

applies to all 3 examples (colour, primitive, bitmap).

The point is to have a very simple rule for parameter order that applies  
to *all* allegro functions. Saying:
1) objects    { AL_BITMAP, AL_SPRITE*, AL_SOUND*  (*)=hypothetical)
2) position   { start_x|y|z, end_x|y|z }
3) attributes { AL_COLOR, AL_BLEND_MODE*, AL_FOO* }
and source comes before dest (or vice versa), would go a long way into  
ensuring a good API.

A few more questions:

1) What is the status on blending functions? I can't find anything in the  
wiki.

2) Also, is the al_draw_rotated_scaled_bitmap really a good idea? Maybe  
functions al_rotate_bitmap and al_scale_bitmap would be a better idea? The  
implementation would be very easy for OGL and D3D, but I can see it being  
difficult for software backends. Maybe the AL_BITMAP struct could be  
augmented to contain scaling and rotation information, which would then be  
used directly by al_draw_bitmap?


Stephen A