I need quick transparent blitting

[meynaf]

Hi all coders !

As the title says, it's about gfx blitting. I have code to do this, but without transparency.

Do someone here have fast and reusable code for that ?
Goal is code that I can later use in games - whatever the game will be must be irrelevant for the blitting code (it's about reusability).

It's not as obvious as "just use the blitter". First, I'm not sure that it's faster than 030+ (my target). Second, it
must be able to blit to/from chipmem and fastmem. Most common case will be from fast to chip. Advantage of fastmem : you can go to town with a much bigger amount of graphics.
And third, it must work under OS, so beware about too much hardware poking. Of course I could use OS itself for that, but what I fear is : S.L.O.W.

What I have is an interleaved bitmap (all planes for first line, all planes for second line, and so on) - both source and destination will be like that, including screen (I'm not against more generic code, though ).
Might be anything from 1 to 8 bits per pixel (usually from 4 to 8) - and code must cope with that, if possible
without having one routine per case.

The best thing for me is a routine which takes a bitmap and a region (x,y,w,h) as input, and blits that to another bitmap, at any place in it - using a transparency color and/or a mask plane. My bitmap structure can be rearranged
to include whatever fields are needed.

Most important thing : it must be reusable. So don't ask me what the main program is, as it could be anything requiring a blit.

So what ? Where are the hardcore people ?

[Thorham]

Originally Posted by meynaf

Second, it must be able to blit to/from chipmem and fastmem.

Why do you have to blit from chipmem?

[meynaf]

Originally Posted by Thorham

Why do you have to blit from chipmem?

Completeness ?

Well, i don't really need this. But if you can blit from fastmem, then you can also blit from chipmem so don't care about that case.

What i need is generic blitting with transparency to be included into my system frame, no more no less.

[Toni Wilen]

Fast _and_ reusable/generic transparent blit does not exists in Amiga land

[meynaf]

Originally Posted by Toni Wilen

Fast _and_ reusable/generic transparent blit does not exists in Amiga land

Then one has to be written

But if it's not possible, then i need a reusable/generic transparent blit and i will make it as fast as possible.
Or i could take a non generic, but fast, blit, and try to make it more generic.

Do you have examples ?

[Kalms]

For the sake of clarification -

for the transparency, how would you specify it?
using an extra transparency plane?
all bits 0 in all bitplanes?
pixel value #N (where N is an input parameter to the blit call)?

Are source and destination always of the same bitdepth?
If source has less planes than destination, how should extraneous planes in destination be handled? don't modify those? Perform source->dest blit with the assumption that the missing source planes contain all zeroes?

[Samurai_Crow]

@meynaf

The only tricks to copying interleaved bitplanes with the CPU is that you only load the mask plane every N pixels in height where N is the number of bitplanes in the image and take 32 pixels at a time for width. The blitting routine can be reused for additional width by putting it inside a loop.

[meynaf]

Originally Posted by Samurai_Crow

@meynaf

The only tricks to copying interleaved bitplanes with the CPU is that you only load the mask plane every N pixels in height where N is the number of bitplanes in the image and take 32 pixels at a time for width. The blitting routine can be reused for additional width by putting it inside a loop.

Not so easy. Planes needs to be shifted and masked because the source isn't just aligned with the target.
So you have start mask, inside mask (all 1's if you're just copying w/o trans), end mask.
Btw a regular (i.e. without transparency) blitting already eats all available cpu registers.

Originally Posted by Kalms

For the sake of clarification -

for the transparency, how would you specify it?
using an extra transparency plane?
all bits 0 in all bitplanes?
pixel value #N (where N is an input parameter to the blit call)?

As several gfx can have different transparent color so you lose none of your palette entries, i'm using pixel value #n.
But i have code to "hide" this by precomputing a transparency plane which is used like a cache.

So choose the method that better suits performance

Originally Posted by Kalms

Are source and destination always of the same bitdepth?

Yes they are - at least for now. Different bit depths are for a distant future - if i ever need this, which i doubt.

[Kalms]

I've been doodling around a bit with this over the past few days. Haven't done any test runs on real hardware yet.

Here's a routine which accomplishes the following:
* copies a rectangular region from source to destination
* supports 1..8 bitplanes
* bitplanes must be either interleaved or contiguous
* only 32-bit large, 32-bit aligned memory reads/writes are used

Stuff not yet done properly:
* it will always read the entire destination buffer
* no transparency support

Is this in the right ballpark with regards to performance and functionality?

Also, if you are having a lot of transparency in your 32pixel runs it might be advantageous for the sprite blitting to maintain a copy of the framebuffer in fastram as well (for the destination reads). Is that an option for you?
It would then affect all rendering code, not just the code that needs bitmap blits.

Routine link:http://unitedstatesofamiga.googlecod...-Kalms-0.5.zip

[Kalms]

I implemented a masked version tonight.

Available in this package:http://unitedstatesofamiga.googlecod...-Kalms-0.6.zip

Due to how it's implemented (it's processing vertically) it is wasteful with memory bandwidth on any platform that reads and/or writes 16-byte segments against fast memory.

I'm not very keen on doing a rewrite to reduce the memory bandwidth waste right now. It might turn out that you need one routine for 020/030 and one for 040/060.

Profiling results on 68060@50:
Copy fast->chip, with 8bpl output...
Mask is all empty: processing 2.1MB/frame
Mask contains mixed data: outputting 43kB/frame
Mask is all set: outputting 64kB/frame

Rewriting the routine would likely make it run at up to 60kB/frame for mixed data and 90kB/frame for an all-set mask.

[meynaf]

Originally Posted by Kalms

Is this in the right ballpark with regards to performance and functionality?

This looks good enough anyway.

Originally Posted by Kalms

Also, if you are having a lot of transparency in your 32pixel runs it might be advantageous for the sprite blitting to maintain a copy of the framebuffer in fastram as well (for the destination reads). Is that an option for you?

It would then affect all rendering code, not just the code that needs bitmap blits.

This is why i said i needed to be able to blit from/to chip/fast : it must be possible to use fastmem backbuffers if a lot of blitting goes on.

Originally Posted by Kalms

I implemented a masked version tonight.

Available in this package:http://unitedstatesofamiga.googlecod...-Kalms-0.6.zip

Due to how it's implemented (it's processing vertically) it is wasteful with memory bandwidth on any platform that reads and/or writes 16-byte segments against fast memory.

I'm not very keen on doing a rewrite to reduce the memory bandwidth waste right now. It might turn out that you need one routine for 020/030 and one for 040/060.

Profiling results on 68060@50:
Copy fast->chip, with 8bpl output...
Mask is all empty: processing 2.1MB/frame
Mask contains mixed data: outputting 43kB/frame
Mask is all set: outputting 64kB/frame

Rewriting the routine would likely make it run at up to 60kB/frame for mixed data and 90kB/frame for an all-set mask.

I will have a closer look and i can't tell much from now.

But i've read you're processing data vertically. Might make things simpler, but i'm afraid there will be some kind of display tearing if blit isn't made fully line by line...

[meynaf]

I now have the blitting code i wanted. Thx to anyone who helped.
If some of you wants to have a look at it, then you can either ask here or PM me. As the code is integrated into my asm framework, it's not easy to post (it's not a simple, separate routine).

[Thorham]

Originally Posted by meynaf

I now have the blitting code i wanted. Thx to anyone who helped.
If some of you wants to have a look at it, then you can either ask here or PM me. As the code is integrated into my asm framework, it's not easy to post (it's not a simple, separate routine).

So you wrote it from scratch? Must've been a pain in the backside Why don't you attach your system frame here? That way people anyone can have a look at your code

[meynaf]

No, i didn't write it from scratch.
As a basis i used my regular (non-transparent) blitting routine, in which Don Adan (thx to you !) has been able to free enough registers (or better use them) to support transparency.

About posting my system frame, it's already more than 4000 lines of code, with (as usual ) french comments.

Besides, i hesitate in spreading it too much.
Of course it would be cool to see it widely used - and you can be sure it helps in making programs simpler.
But if i did so, i'd be flooded with feature requests (probably) and i would no longer be able to alter things in an incompatible way (which i sometimes do ; only requires some searching on my HD).

[kamelito]

Originally Posted by meynaf

I now have the blitting code i wanted. Thx to anyone who helped.
If some of you wants to have a look at it, then you can either ask here or PM me. As the code is integrated into my asm framework, it's not easy to post (it's not a simple, separate routine).

Hi Meynaf,
I'd like to look at it

[meynaf]

After 10 years ? Ok then. Check your PM