If you want clipping you need to blit into a RastPort and not into a bitmap. I don't have the autodocs for CompositeTags here in front of me. If it does not allow to specify a RastPort as destination, then it is not meant to be used to blit into a window.
but this only works if your window is the frontmost one, i.e. not covered by parts of other windows.
Edit: now I read the autodocs and as it seems there is no way to specify a RastPort as destination for CompositeTags.
So if you don't need alpha blending, you should use BltBitMapRastPort instead.
If you need alpha blending, you have to - allocate a new bitmap with BMF_DISPLAYABLE set and the window's bitmap as friend - copy the area of the window you want to manipulate into the new bitmap using ClipBlit() - use CompositeTags() with the new bitmap as destination - copy the new bitmap back into the window using BltBitMapRastPort() or ClipBlit().
Perhaps using a window with WA_SuperBitMap would make things a bit easier.
@LiveForIt I checked what my code does when I don't use a buffer: I make a BMF_DISPLAYABLE friend-bitmap clone of the window's bitmap (effectively a temporary buffer) but only for the area I want to update, then I use CompositeTagList() or BltMaskBitMapRastPort() as appropriate, then I use ClipBlit() to update the window with the modified bitmap.
This should be *relatively* fast since all blits are between bitmaps that are stored in video memory.
@thomas Quote:
- copy the new bitmap back into the window using BltBitMapRastPort() or ClipBlit().
It would be a very BAD idea to use BltBitMapRastPort() to write directly to the window, because on non-composited windows this will overwrite any windows above the window you are modifying.
But yes, there doesn't appear to be any legal way of doing an alpha (or masked!) blit directly into a window.
Er, is everybody missing BltBitMapTags() which is perfectly able to to alpha blits (in fact, it was the only way in 4.0).
Quote:
It would be a very BAD idea to use BltBitMapRastPort() to write directly to the window, because on non-composited windows this will overwrite any windows above the window you are modifying.
This is also wrong, as the rastport will do clipping for you, so as long as you blit to the window's rastport what you blit will only end up in that window.
Actually I didn't know there was a ClipBlit function, and it looks identical to BltBitMapRastPort to me.
is everybody missing BltBitMapTags() which is perfectly able to to alpha blits
My SDK documentation says nothing about alpha blitting for that function. As far as I can see, it is not better/worse than for OS3.x.
Quote:
This is also wrong, as the rastport will do clipping for you, so as long as you blit to the window's rastport what you blit will only end up in that window.
All I can say is that (I believe) I was using BltBitMapRastPort() into my window's rasterport, and I discovered it was overwriting overlapping windows when Compositing was disabled. I was advised to use ClipBlit() to solve my problem (which it did).
Here is what the SDK says about ClipBlit(): Quote:
Performs the same function as BltBitMap(), except that it takes into account the Layers and ClipRects of the layer library, all of which are (and should be) transparent to you. So, whereas BltBitMap() requires pointers to BitMaps, ClipBlit requires pointers to the RastPorts that contain the Bitmaps, Layers, etcetera.
If you are going to blit blocks of data around via the RastPort of your Intuition Window, you must call this routine (rather than BltBitMap()).
So basically, BltBitMap() (and I think probably BltBitMapRastPort() also) do a single blit without taking account of overlapping windows being emulated by Intuition. You need to use ClipBlit() to ensure that works.
is everybody missing BltBitMapTags() which is perfectly able to to alpha blits
My SDK documentation says nothing about alpha blitting for that function. As far as I can see, it is not better/worse than for OS3.x.
Have you been to the optician lately? From my oldest copy of the SDK (so that's older than 53.15 but I'm not sure how much older as files were copied from my AOne and lost their filestamps)
NAME
BltBitMapTagList -- Blit from any source to any destination (V51).
Note the 51 there, BltBitmapTags never existed for 3.x. I'm not sure when it was introduced exactly but I updated AWeb to use it sometime during the prerelease era IIRC
BLITA_SrcType, BLITA_DestType (int32) - specifies the type of the
source (BLITA_Source) and destination (BLITA_Dest). The following
types are supported:
BLITT_BITMAP (default) - a simple bitmap (struct BitMap *).
BLITT_RASTPORT - a rastport (struct RastPort *).
BLITT_TEMPLATE - a monochrome template (PLANEPTR), see BltTemplate()
for more information. Only supported by BLITA_SrcType.
BLITT_ALPHATEMPLATE - an 8bit alpha template, must be as large
as the source bitmap (APTR). Only supported by BLITA_SrcType.
BLITT_CHUNKY - an 8bit chunky buffer (APTR)
BLITT_RGB24 - 24bit RGB buffer (APTR).
BLITT_ARGB32 - 32bit ARGB buffer (APTR).
---snip---
BLITA_AlphaMask (APTR) - the alpha mask to apply, defaults to
NULL. Source bitmap and mask must have the same dimension.
BLITA_UseSrcAlpha (BOOL) - use alpha data stored in the source
object for transparent blits, default is FALSE. BLITA_UseSrcAlpha,
BLITA_UseDstAlpha (see below) and BLITA_AlphaMask are mutually-
exclusive.
BLITA_UseDstAlpha (BOOL) - use alpha data stored in the destination
object for transparent blits, default is FALSE. BLITA_UseSrcAlpha,
BLITA_UseDstAlpha, BLITA_AlphaMask are mutually-exclusive.
All I can say is that (I believe) I was using BltBitMapRastPort() into my window's rasterport, and I discovered it was overwriting overlapping windows when Compositing was disabled. I was advised to use ClipBlit() to solve my problem (which it did).
All I can say is "weird". I have never seen this problem, and I always draw to windows through RastPorts, using various graphics.library functions. I rarely draw direct to BitMaps (and *never* to window or screen BitMaps)
Quote:
So basically, BltBitMap() (and I think probably BltBitMapRastPort() also) do a single blit without taking account of overlapping windows being emulated by Intuition. You need to use ClipBlit() to ensure that works.
BltBitMapRastPort will always take clipping into account, as will any function that draws through a RastPort, rather than direct to a BitMap.
The difference, as Thomas states, is that source is also a RastPort for ClipBlit.
BltBitMap however, will overwrite anything it likes.
I had another look, and it appears that SDK Browser (v1.6) is showing the BltBitMap() stuff when I click on BltBitMapTags(), hence why there was nothing about alpha stuff.
This is a nice discovery, because it means I could add accelerated (alpha) blitting to my graphics engine for AmigaOS4.0.
@chris What is the benefit for BltBitMapRastPort() over ClipBlit() then? The autodocs don't make this clear. (I can try replacing ClipBlit() with BltBitMapRastPort(), if there is an advantage in doing so.)
What is the benefit for BltBitMapRastPort() over ClipBlit() then? The autodocs don't make this clear. (I can try replacing ClipBlit() with BltBitMapRastPort(), if there is an advantage in doing so.
BlitBitmapRastPort blits from a Bitmap to a Rastport
ClipBlit blits from a Rastport to a Rastport.
I'm not sure but I think that ClipBlit takes the cliping in *both* rastports into account.
>cairo operators ...I don’t want to add alien API No no ChrisH was meaning "here there is some docs about the alpha operators used in CompositeTags (same as Cairo)"
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
From my oldest copy of the SDK (so that's older than 53.15 but I'm not sure how much older as files were copied from my AOne and lost their filestamps)
