AFAIK all BltBitMap#?() calls are software-only. I've never seen any evidence of hardware acceleration there, even when doing simple alpha-supporting blits (BLITA_UseSrcAlpha).
AFAIK all BltBitMap#?() calls are software-only. I've never seen any evidence of hardware acceleration there, even when doing simple alpha-supporting blits (BLITA_UseSrcAlpha).
Wrong! You don't honestly think that all blitting is done in software, do you? All graphics would be painfully slow in that case, particularly on the high-resolution screens that we use these days.
Regarding "simple alpha-supporting blits," that's a recent fairly addition to the API that is actually more complicated than blits without transparency. Yes, BltBitMapTags() does alpha blits in software, but you should be using CompositeTags() for that task, anyway.
OS4 team, please release the popupmenu..library fixed.
It seems that Banana is affected too by Popupmenu.library problem (like CPUDock and x1ktemp.docky).
DSI when RMB (not often but sometimes)
*sigh* I was moaning about this for over two years and it's only now that programs show up that are affected by it?
Oh well, at least it's fixed. I can finally remove upteen workarounds and add some other things I've been holding off when it gets released.
Techy note: it is caused by the allocation of signals. If other code can be removed that allocates signals, the chances are that popupmenu will stop crashing.
Wrong! You don't honestly think that all blitting is done in software, do you? All graphics would be painfully slow in that case, particularly on the high-resolution screens that we use these days.
All I know is that BltBitMapTags is much much slower than CompositeTags for alpha-supporting blits. I made the assumption that it was slower for normal blits too, although I'd never noticed nor tested this. I was wrong, sorry.
Quote:
Yes, BltBitMapTags() does alpha blits in software, but you should be using CompositeTags() for that task, anyway.
Why shouldn't BltBitMapTags hardware accelerate that task too?
Especially as BltBitMapTags is a lot more flexible than CompositeTags - for example, it can blit Alpha Templates, which CompositeTags can't do. It would be a great help to me if this particular functionality was hardware accelerated, as at the moment it is a relatively painful operation.
Why shouldn't BltBitMapTags hardware accelerate that task too?
That would require new functions in the driver API that don't exist. Drivers would have to be updated to implement those new functions too. In the case of the RadeonHD driver, those functions would have to be implemented several times, once for each chipset series. That's not impossible, but would be a lot of work.
Quote:
Especially as BltBitMapTags is a lot more flexible than CompositeTags - for example, it can blit Alpha Templates, which CompositeTags can't do. It would be a great help to me if this particular functionality was hardware accelerated, as at the moment it is a relatively painful operation.
Personally, I think that CompositeTags() is much more flexible than BltBitMapTags(). That's why its autodoc entry is several times longer.
BTW, you could probably simulate your alpha templates using CompositeTags() with vertex arrays. It won't be as convenient as BltBitMapTags(), but you could get the same effect (excluding some draw modes like INVERT). The reason for using the vertex array mode would be so that you could put your foreground colour in a tiny source bitmap (you should only need 1 pixel in that colour), and use that with your alpha mask.**
Hans
** NOTE: Vertex arrays don't have a software falback yet, so you'd still have to use BltBitMapTags() as a backup.
That would require new functions in the driver API that don't exist. Drivers would have to be updated to implement those new functions too. In the case of the RadeonHD driver, those functions would have to be implemented several times, once for each chipset series. That's not impossible, but would be a lot of work.
Hmm, interesting. So how does CompositeTags achieve the same results without this?
Quote:
BTW, you could probably simulate your alpha templates using CompositeTags() with vertex arrays. It won't be as convenient as BltBitMapTags(), but you could get the same effect (excluding some draw modes like INVERT). The reason for using the vertex array mode would be so that you could put your foreground colour in a tiny source bitmap (you should only need 1 pixel in that colour), and use that with your alpha mask.
I don't want to "simulate" an alphatemplate, as I'm getting my alphatemplates from elsewhere. If I can convert an alphatemplate to a vertex array in code without too much overhead then I'm interested, although I have no idea where to even start with this.
Hmm, interesting. So how does CompositeTags achieve the same results without this?
A function was added to the driver's API specifically for CompositeTags(). It's by far the most complex function that the driver has to implement.
Quote:
I don't want to "simulate" an alphatemplate, as I'm getting my alphatemplates from elsewhere. If I can convert an alphatemplate to a vertex array in code without too much overhead then I'm interested, although I have no idea where to even start with this.
Sorry, I meant "simulate" an alphatemplate blit operation. You're trying to render a solid coloured shape using an alpha template, right? Well, here's how I would do that with CompositeTags(): - Write the foreground colour to a single pixel in a tiny source bitmap - Use CompositeTags() to render that single pixel to a region on-screen with the alpha template as the source alpha mask
The reason for using vertex arrays instead of a regular rectangular composite, is that you can provide independent coordinates for the source bitmap and alpha mask.
A function was added to the driver's API specifically for CompositeTags(). It's by far the most complex function that the driver has to implement.
I feel like I'm going in circles, but why can't BltBitMapTags also use this? The functionality is already there!
Quote:
Sorry, I meant "simulate" an alphatemplate blit operation. You're trying to render a solid coloured shape using an alpha template, right? Well, here's how I would do that with CompositeTags(): - Write the foreground colour to a single pixel in a tiny source bitmap - Use CompositeTags() to render that single pixel to a region on-screen with the alpha template as the source alpha mask
Right, great. I did try this at some point in the past but with a bigger bitmap and no vertex arrays. I didn't get the results I was expecting.
So, I need to use my 1px colour bitmap as the source, and the AlphaTemplate as the SrcAlphaMask? Then I do something I don't understand with vertices?
Some example code would really help here as I don't have a clue about vertex arrays.
Quote:
The reason for using vertex arrays instead of a regular rectangular composite, is that you can provide independent coordinates for the source bitmap and alpha mask.
That's probably at least part of the reason it didn't work last time.
I feel like I'm going in circles, but why can't BltBitMapTags also use this? The functionality is already there!
The driver's compositing function is designed specifically for CompositeTags(). In theory BltBitMapTags() could internally call CompositeTags() when appropriate, but that adds extra overhead. Why not avoid the extra overhead and just call CompositeTags() directly?
For the cases that CompositeTags() can't handle (e.g., an alpha template in INVERT draw mode), you're still stuck with software rendering, so you haven't gained anything.
Quote:
Right, great. I did try this at some point in the past but with a bigger bitmap and no vertex arrays. I didn't get the results I was expecting.
If you didn't get the results that you wanted using a larger bitmap (filled with a solid colour), then vertex arrays won't help you either.
There's a chance that you used the wrong settings (e.g., forgot to use COMPFLAG_IgnoreDestAlpha).
Quote:
So, I need to use my 1px colour bitmap as the source, and the AlphaTemplate as the SrcAlphaMask? Then I do something I don't understand with vertices?
Some example code would really help here as I don't have a clue about vertex arrays.
Unfortunately, I don't know of any simple example code. There is source code to Composite3DDemo, but it's pretty complex. However, the CompositeTags() documentation does have a good explanation.
In brief: in vertex array mode, you render a set of triangles, with the coordinates for each vertex stored in an array. Since you want different coordinates for the source and alpha bitmaps, your vertex data would look like:
typedef struct VertexDSA_s // DSA = dest, source, & alpha coordinates
{
float dstX, dstY; // The coordinate on the destination bitmap
float srcS, srcT, srcW; // The coordinate on the source bitmap/texture in homogeneous coordinates
float alphaS, alphaT, alphaW // The coordinate on the alpha bitmap/texture in homogeneous coordinates
} VertexDSA
VertexDSA vertexData[] = { /* Insert vertex data here */ };
NOTES: - For the structure above, COMPTAG_VertexFormat should be set to: COMPVF_STW0_Present | COMPVF_STW0_Present - Unless you're doing warping/perspective projection, set srcW & alphaW to 1.0, and the S & T coordinates to the location on the source & alpha bitmaps where you want to read the data from - For the single colour instance, (srcS, srcT, srcW) = (0.0, 0.0, 1.0). This means that the colour of source pixel (0,0) is used for all output pixels
You could take a look at the Qt sources. I use Hans' method for rendering glyphs. The file qt/src/gui/text/qpaintengine_amiga.cpp should give you some pointers (look for ::drawFreetype() function, I think).
The driver's compositing function is designed specifically for CompositeTags(). In theory BltBitMapTags() could internally call CompositeTags() when appropriate, but that adds extra overhead. Why not avoid the extra overhead and just call CompositeTags() directly?
Errr, because it would magically speed-up software that doesn't use CompositeTags (for whatever reason). If the overhead is not negligible, then they can always try using CompositeTags later.
I really don't understand the logic that "we won't optimise an OS function because the speed-up would be smaller than everyone rewriting their apps".
Its a bit complex, too (and sometimes a bit weird ;) ), but its not as complex as Hans´ demo (which is great, btw.!).
It´s nearer to the application you´d have for CompositeTags(), because its typical 2D programming (replace blits by CompositeTags() using vertex mode and several source bitmaps, including some bitmaps bigger than the "blit" target).
I learned a lot about vertex mode reading this code.
@Hans
Would it be a good idea to use the CompositeTags() call to replace standard Blt...() calls (like BltBitMapRastPort())? E.g. for blitting a background buffer to a window? Would it be faster?
Edit: oh, missed that somebody already mentioned it
Yes, that makes more sense than the Autodocs, thanks.
@alfkil
Quote:
You could take a look at the Qt sources. I use Hans' method for rendering glyphs. The file qt/src/gui/text/qpaintengine_amiga.cpp should give you some pointers (look for ::drawFreetype() function, I think).
That is more-or-less exactly what I need. However, I can't find it. Did you mean qfontengine_amiga.cpp? There's no reference to Composite in that file.
@others
I had a quick look at CompositePOC and it made my SAM reset itself...
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
