[AD] C/Asm integration (was [AD] Improvement on alpha blending...)

[Bob <ohannessian@xxxxxxxxxx>]

Hi,

I started working on changing the blending mechanism to work line by 
line instead of pixel by pixel, but I have encountered a small problem.
The new blenders will have the prototype:

	void blender_func(void *source, void *dest, unsigned long num_pixels, 
unsigned long alpha);

They can then cast to whatever type they need (short for 16 bit, etc).

The problem however comes from the assembly primitives. They mix a 
constant color with a destination pixel (putpixel for example, or hline).
I managed to make it blend by pushing the color value on the stack
and sending the blender the address of the color (on the stack). For the 
destination pixel, I can send the destination address directly, since it 
will be blended with that anyway. However, it is entirely possible that 
the pixel must be read (and written) to a different address space. 
Normally, the mov's ae prefixes by the %es selector, which points to the 
correct memory 'segment' (for lack of a better word).

Is there a way I can pass a C function that %es, or instruct it to use 
%es on memory moves? How would this affect blenders which use look-up 
tables or malloc()s ?
Is there another way around this mess?

Thanks.

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/