A small (and dangerous) new years gift for the os4 community :)

@alfkil

Hi, Only to report that Bananabar crashes my Sam440EP OS4.1.6.
Happy NewYear for all

@alfkil

Got it now, thanks!

I'm a bit confused that you seem to have both a vertex and a non-vertex routine - why the difference?

@Chris

Because I only use the vertex version for affine transforms. I don't know if there is any speed difference btw the two, but if you are just plotting square letters, then there is no need to use triangulations.

@alfkil

Ah, OK. I did try your non-vertex code but I get nothing plotted on-screen. I suppose I'm doing something wrong.



versus old working code



The Autodoc has tags for co-ordinates for AlphaMasks which is confusing me a bit. I decided to ignore those as you haven't used them.

@Chris,

Compositing direct to a window rastport bitmap will not trigger an update of the windows display on a screen with effects enabled.

@broadblues

That's not the window's RastPort/BitMap, it's a temporary BitMap which then gets blitted to the window later (via the RastPort).

@ChrisH
Quote:

That's because you're not factoring in the limited resources that we have, and the large number of other higher impact tasks that OS developers have. Once you factor those in, things look different.

AFAIK, BltBitMapTags() didn't exist before AmigaOS 4 update 1, so its use will be limited, and its highly likely that the software in question is being actively developed. There's always a chance that someone will enhance BltBitMapTags(), but there are plenty of other (higher impact) tasks demanding attention. So, I wouldn't count on it happening soon.

In the meantime, I'm encouraging developers to use CompositeTags() directly.

Hans

@Chris

Quote:

Okay. Thought I'd mention it as there was rp->BitMap term, and it's an easy mistake to make when changing functions.

Would be really useful to know if there was way to set the "damaged area" of a rastport when blitting to it's bitmap.

Clearly there is a way, as dedicated functions with the rport as target do so, but I've not seen any public code to do it (might well use private methods and strcutures ofcourse).

@AlphaRomeo

It doesn't work on old Radeons yet. Well, it does but I haven't released it.

@Chris

Looks correct from here. Have you tried disabling DestAlphaIgnore? Are you sure, that the AlphaMask is given as a bitmap? I cannot remember, and I don't have access to the autodocs ap.

@alfkil

I actually added the IgnoreDestAlpha to try and fix the problem

SrcAlphaMask is a struct BitMap* according to the AutoDocs, so I think that's right.... ah, but the glyph itself is raw data, not a struct BitMap. That means I need to blit that - with alpha - to a BitMap before doing the Composite. That's the blit I'm doing anyway, so the Composite is actually an extra operation in this scenario.

So, I repeat my original question, is there any way to hardware-accelerate the blitting of ALPHATEMPLATE bitmaps (which are raw data returned from BulletAPI, not struct BitMap*)?

@Chris

Quote:

Not really, blitting ARGB32 data into an 'empty bitmap' doesn't require any alpha blending so whilst it may not be hardware accelaerated it's not neccessarily slow either.

Quote:

You need your data on the graphics card, the only way to get it onto the card is via a bitmap. So no. Not in the way you ask the question.

As far as I can see you fastest process would be

Aquire data from BulletAPI

Blit to friend bitmap of screen (I suppose you could lock the bitmap and manually write the data if you think you do abetter job of optimising that transfer, unlikely IMHO)
This stage might be cacheable if you are reusing glyphs a lot.

Composite to destination

Blit destination to Window rastport

@broadblues

It's ALPHA8 rather than ARGB32, but good point on the blending. Allocate bitmap, blit, composite, free bitmap seems a bit overheady but I'll give it a try. (and as you say, I might be able to cache the glyphs, or re-use the bitmap, or something).

@Chris

Quote:

Caching the glyphs is definitely the way to go. Otherwise you'll be copying the glyphs from RAM to VRAM for every character. Also, if you cache multiple glyphs into one bitmap like OGLFT does, then you could render multiple characters with one CompositeTags() call using vertex arrays.** It would be great if we had a shared library that handled this, so that people wouldn't have to reimplement this from scratch.

Hans


** Once again, note that there is no software fallback for vertex arrays, so you'd need your own fallback for graphics cards that don't support this feature.

>you could render multiple characters with one CompositeTags() call using vertex arrays

Once again: just look in CompositePoc how the text is drawn on screen...
(It use CompositeTags() + vertex arrays + all fonts in a bitmap)

Alain

@Alfkill

Hello,

how you managed to do accelerated blitblt with transparent areas? Do you used cliprect or other composite tags function?

I have problem blitting to a temporary bitmap ( i get some graphic glitches) and the image is not clipped.

@AmigaBlitter

What do you mean "transparent areas"? Are you talking about text rendering (a la Qt) or BananaBar?

In bananaBar, the transparency is controlled via a ClipRegion, which points to an ALPHA8 bitmap, which then designates the degree of transparency. The problem here is painting to the Alpha bitmap in a system compliant way.

In Qt clipping is done via Qt's own clipping system (which is really dumb and complicated, by the way), and for every drawing operation I need to manually specify COMPTAG_DestX, DestY, DestWidth and DestHeight for the call to CompositeTags.

But then again, I don't really know, what your problem is.

@Alfkill

"What do you mean "transparent areas"? Are you talking about text rendering (a la Qt) or BananaBar?"

BananaBar in this case.

I load a png32, then i blit the bitmap to a temporary bitmap. After this i blit the image to the window->RasPort.

I get some error error (graphics glitches) for the image i blit onto the window and the image is not clipped.

@AmigaBlitter

Which blitting function are you using? What do you mean be "not clipped"? For transparency effects, you need to somehow isolate the alpha channel and copy it to a separate ALPHA8 bitmap, that you then attach to a ClipRegion. And by the way: Every time you update this alpha bitmap, you need to do a correcponding call to SetWindowAttrs() to reset the clip region (can't remember the name of the tag).

Also: Which compositing operation are you using? Src_Over_Dest or just Src or something else? Maybe you should post a code snippet here to make it more clear, what you are doing.

@alfkil

struct BitMap *inv_buffer_bm;
struct RastPort inv_buffer_bm_rp;

const int32 inv_buffer_width = inv_width, inv_buffer_height = inv_height;
inv_buffer_bm = IP96->p96AllocBitMap(inv_buffer_width, inv_buffer_height, 32, 0, NULL, RGBFB_A8R8G8B8);
if (inv_buffer_bm == NULL) {
IP96->p96FreeBitMap(inventory_bm);
fprintf(stderr, "Failed to allocate bitmap.\n");
return RETURN_FAIL;
}

int32 img_x = 0, img_y = 0;

IGraphics->InitRastPort(&inv_buffer_bm_rp);
inv_buffer_bm_rp.BitMap = inv_buffer_bm;


IGraphics->CompositeTags(COMPOSITE_Src_Over_Dest, ball_bm, inv_buffer_bm,
COMPTAG_SrcWidth, inv_width,
COMPTAG_SrcHeight, inv_height,
COMPTAG_OffsetX, img_x,
COMPTAG_OffsetY, img_y,
COMPTAG_Flags, COMPFLAG_IgnoreDestAlpha,
TAG_END);

IGraphics->BltBitMapTags(
BLITA_DestX, win2->BorderLeft,
BLITA_DestY, win2->BorderTop,
BLITA_Width, display_width,
BLITA_Height, display_height,
BLITA_SrcType, BLITT_BITMAP,
BLITA_Source, inv_buffer_bm,
BLITA_DestType, BLITT_RASTPORT,
BLITA_Dest, win2->RPort,
BLITA_UseSrcAlpha, TRUE,
TAG_END);


This doesn't works well. The images is blitted, but there are some glitches.

For transparent blit i mean this: http://msdn.microsoft.com/en-us/library/aa915021.aspx

@AmigaBlitter

Why not provide a screen shot of the corruption you get.

What is that composite step suppoed to be doing?