RE: [AD] new_api_branch: al_create_display and blit patch

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

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

I found out when playing with FBlend that this is actually slower (when
blending) than:

- Figure out the rectangular portion of the screen you need to blend to.
- Redraw the non-transparent objects of that portion into a memory
bitmap.
- Blend temp * transparent bitmap -> screen.


Now the problem is that this technique doesn't work too well when
hardware accelerated blending is supported. In that case, it's a -lot-
faster to just tell the GPU what to do.



> -----Original Message-----
> From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> developers-admin@xxxxxxxxxx] On Behalf Of Evert Glebbeek
> Sent: Sunday, May 15, 2005 12:32 AM
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] new_api_branch: al_create_display and blit patch
> 
> 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
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers