CompositeTags() in gfx.lib definitely is. BltBitMapTags() people keep telling me is, but I don't believe it as it's dog slow compared to the same operation using CompositeTags() (and ditto wrt BitMapScale())
I'm still looking for a hardware-accelerated way of blitting an ALPHATEMPLATE to the screen applying a particular solid colour. BltBitMapTags() isn't it, and CompositeTags() isn't either, as you still have to use BltBitMapTags() before you can call it...
I'm still looking for a hardware-accelerated way of blitting an ALPHATEMPLATE to the screen applying a particular solid colour. BltBitMapTags() isn't it, and CompositeTags() isn't either, as you still have to use BltBitMapTags() before you can call it...
In correct you use WritePixelArray to move it to video memory (DMA operation), once the gfx is in video memory, you can composite the graphics as many times you like.
BltBitMapTags() always do clipping, while CompositionTags() never do clipping. CompositionTags() is there for slightly faster if you don't need clipping. CompositionTags() scales and rotates, BltBitMapTags() does not.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
CompositeTags() in gfx.lib definitely is. BltBitMapTags() people keep telling me is, but I don't believe it as it's dog slow compared to the same operation using CompositeTags() (and ditto wrt BitMapScale())
It depends on what you're doing with BltBitMapTags. A straight blit between two bitmaps is HW accelerated provided that both bitmaps have the same pixel format. Anything that involves converting between pixel formats or scaling isn't accelerated.
@LiveForIt Quote:
BltBitMapTags() always do clipping, while CompositionTags() never do clipping.
You mean clipping to a rastport? Yes, CompositeTags() renders straight to bitmaps. However, as you know, you can use DoHookClipRects() with CompositeTags() to render into a rastport; it takes care of the clipping. Just remember to lock the layer beforehand so that the window/layer doesn't change between reading its dimensions and the actual rendering.
So does the full screen need to be redrawn in OWB with every update?
While I haven't seen the source code, I rather doubt it. On the other hand, I do believe that (intentionally) Timberwolf does redraw the whole screen with every update (and you can see the impact that has on it's speed).
But as Chris says, that's just a software optimisation issue.
It depends on what you're doing with BltBitMapTags. A straight blit between two bitmaps is HW accelerated provided that both bitmaps have the same pixel format. Anything that involves converting between pixel formats or scaling isn't accelerated.
Yes, sorry, I did actually make a big error here. It's only blits involving alpha channels that are noticeably very slow. I accept that normal blits are hardware accelerated.
>you can use DoHookClipRects() with CompositeTags() very interesting : do you have a piece of code that show how to do that ?
Yes, the following snippet shows how:
/** Contains data needed by compositeHookFunc().
*/
typedef struct CompositeHookData_s {
struct BitMap *srcBitMap; // The source bitmap
int32 srcWidth, srcHeight; // The source dimensions
int32 offsetX, offsetY; // The offsets to the destination area relative to the window's origin
int32 scaleX, scaleY; // The scale factors
uint32 retCode; // The return code from CompositeTags()
} CompositeHookData;
/** The hook for performing compositing to a rastport.
*
* Thanks to Fredrik Wikstrom (a.k.a., salass00) for the example code...
*
* @param rastPort pointer to the RastPort to render to
* @param msg pointer the backfill
*/
ULONG compositeHookFunc(struct Hook *hook, struct RastPort *rastPort, struct BackFillMessage *msg) {
CompositeHookData *hookData = (CompositeHookData*)hook->h_Data;
/** Composites a bitmap to fill the given window (the window's interior).
*
* @param bitmap the bitmap
* @param window the window to render to
*
* @return uint32 the compositing operation's return-code
*/
uint32 fillWindowWithBitMap(struct BitMap *bitMap, struct Window *window)
{
ILayers->LockLayer(0, window->RPort->Layer);
// Need to composite onto the window's rastport. Since CompositeTags() only renders to bitmaps,
// we use ILayers->DoHookClipRects().
CompositeHookData hookData;
struct Rectangle rect;
struct Hook hook;
I wanted to avoid caching at point B, as it's a PITA. But, if there's no route direct from A to C then I'll have to give it another try.
Well you can lock bitmap and paint into any bitmap, but you don't wont to do that. You should not plot pixel into VRAM, because you can't do DMA an pixel, it's better to move things in big chunks using DMA.
So things you need to paint do it in RAM, things you can blend do in on VRAM.
Sure you might waste a bit of RAM having to keep two versions of the Bitmaps, but is the only way you can get best performance.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
No we need AGA graphics or maybe AAA graphics No one likes PC hardware. People fall off shares scramming Ammmmmiiiiigggggaaaa Ammmmiiiiiggggggaaaaa Ammmmiiiiggggaaaa at Demo parties looking at 320x200 graphics
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
About the HW colors transform, it's something difficult to implements?
What exactly do you mean with "colors transform?" Do you mean things like converting from ARGB to BGRA? If so, then that's pretty easy on the driver side; in fact, CompositeTags() effectively already does it. You can composite a 32-bit bitmap onto a 16-bit screen and vice-versa. Updating the graphics libraries to use HW accelerated pixel format conversion would take a bit more effort, though.
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
