| Re: [AD] C/Asm integration (was [AD] Improvement on alphablending...) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
George Foot wrote:
[snip]
I might be misunderstanding the problem but AFAICS there are two
options -- either the buffers are in the main segment (so you
have to copy from source and dest to there, and copy back to
dest afterwards) or they're not (so you have to pass the
segments through along with the
pointers-which-aren't-really-pointers).
Doubling the memory movement would seriously impede on the performance,
especially when it would be possible to read/write the destination data
directly (but only if the correct segment is specified).
As a compromise, you could copy the source into the main segment
(if it's not there already) and use bmp_select on the dest
bitmap, then require the blender to use bmp_read and bmp_write
macros to access the dest buffer.
I'll see if the assembly procedure can manage the calls to
read/write_line. Yes, bmp_writenn() will have to be used in the C code
anyway.
But as I said I might be misunderstanding -- I'm not really sure
what these blenders are. Are they user-supplied?
No, but they could be.
Allegro comes with a few blenders, which are awefully slow. The idea
is to be able to work with full lines of pixels at a time, instread of
just 1 pixel at a time. This would greatly reduce the overhead of
function calls in the blender, and also allow working with several
pixels at a time to speed up computations.
I wanted to open the API up so users can use their own custom line
blenders, as well as provide backward compatibility support for pixel
based blenders (yb using a dummy blender which calls back the pixel
blender for every pixel). I'm not sure that's entirely doable now.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/