Re: [AD] new_api_branch: al_create_display and blit patch

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Sunday 15 May 2005 02:10, Chris wrote:
> Personally, I'd prefer the flags to come after the two bitmaps. Either 
> immediately after, or at the end, or something. 

So would I, in fact. Normally, at least. I decided to stick with the design 
document in this case because I assumed Bob had a good reason for choosing 
this particular design, and having though about it I think I agree in this 
case. I'm open to change it though.

The reasons for doing it this way, I think, are twofold. Previously, one 
would do
masked_blit(...)
blit(...)
but now, that becomes
al_blit(AL_MASKED, ...)
al_blit(0, ...)
staying a bit closer to the original semantics. It also introduces a 
symmetry between the different blitting functions that I find appealing. 
It's:

flags,
source bitmap, source coordinates, source dimensions,
destination bitmap, dest coordinates, dest dimensions

where unused coordinates or dimensions are simply not present in the 
argument list. This makes it fairly easy to remember what arguments are 
passed and in what order. Tagging the flags at the end breaks the pattern 
a bit and I'm sure I'd personally forget to include them more easily.

Now, I also have a question/comment about al_blit_region_3.
What this does is more or less the same as the regular blit, but it takes a 
third bitmap to read from when doing things like software blending, which 
is slow if you need to read from video memory. My question is about 
implementation: I would expect that creating the blended destination image 
and then sending that in one chunk to the video card would be the fastest 
way to implement this. So something like

blend source and background on a temporary bitmap
blit temporary bitmap to screen

Am I right?

Evert