Hi,
On Mon, Jul 23, 2018 at 1:15 PM, Bret Johnson wrote:
>
> Multiple issues. First, if you're going to do it in "pure C", you can't
depend on anything like MMX.
MMX is deprecated in lieu of "better" SSE2, though. Of course, that demands
P4/AMD64, but most people have those by now. (I hate to
On Mon, 23 Jul 2018, Rugxulo wrote:
I'm just saying, I suspect that Jim wants to (eventually?) mirror this
to iBiblio, and he will of course want "full" sources. But I realize
this isn't finalized yet, just a preview snapshot. It's sadly too easy
to overlook full sources and dependencies, so
If you think you can do ti with subtraction and bit-shifting (without
requiring MMX or something similar) please show it to us.
With multiplication:
new_mask = color & alpha_mask;
new_mask >>= 6;
new_mask *= 0x7F;
Without multiplication:
new_mask = color & alpha_mask;
new_mask <<= 1;
Multiple issues. First, if you're going to do it in "pure C", you can't depend
on anything like MMX. You're going to need to virtualize the
multiple-byte-functions-at-the-same-time manually, taking advantage of CPU and
data storage characteristics (little-endian, two's complement, etc.).
Hi,
On Tue, Jul 17, 2018 at 6:21 AM, TK Chia wrote:
>
> I have uploaded updated packages at
> https://github.com/tkchia/build-ia16/releases/tag/20180616-update-20180708 .
Okay, I've downloaded this now but haven't tried it yet.
Please don't feel pressure from me about this, but
Hi,
On Mon, Jul 23, 2018 at 11:54 AM, David McMackins wrote:
>
> I have two oppositions to this. First, I'd like to be able to do this in
> pure C. Second, this appears to be a byte-level operation, but the whole
> point of doing this is to work on multiple bytes simultaneously.
>
> I think I
Hi,
On Mon, Jul 23, 2018 at 5:58 AM, Eric Auer wrote:
>
> Hi! I am not sure whether I understand your method, so
> maybe you can explain it in more detail. Is the alpha
> mask 1 byte per pixel, either 00 or ff per pixel? The
> multiplication is costly.
Since when is MUL costly? Or only because
Hi,
On Mon, Jul 23, 2018 at 5:27 AM, Eric Auer wrote:
>
> Hi, just a quick extra idea: You could read about
> the PCX file format for 8-bit colors and define one
> color to be "opaque".
>
> https://www.fileformat.info/format/pcx/egff.htm
This reminds me of Benjamin David Lunt's webpage, where I
I have two oppositions to this. First, I'd like to be able to do this in
pure C. Second, this appears to be a byte-level operation, but the whole
point of doing this is to work on multiple bytes simultaneously.
I think I might be able to do it with a subtraction and two bitshifts,
though.
One way around this might be to use CBW, which essentially copies the high bit
of AL into all the bits of AH. Using your example, if this is the value in AL:
0100
^ the alpha bit You can put a saturated mask in AH with two instructions:
SHL AL,1
CBW Or put a saturated mask in AH and leave
The multiplication does appear to be costly indeed. I'm now trying to
find a way to get around it. I'll explain the method using a 1-byte
example, but the logic scales up:
Our dear color:
0100
^ the alpha bit
Alpha mask:
0100
The color on screen doesn't matter, as will be
Hi! I am not sure whether I understand your method, so
maybe you can explain it in more detail. Is the alpha
mask 1 byte per pixel, either 00 or ff per pixel? The
multiplication is costly. You can also use bit test
and "set conditionally" (to 0 or 255) and "move
conditionally" byte sized 386
I'll take a look at that. An idea I came up with last night while I was
asleep was a method that uses my current encoding.
With 4 pixels loaded in a 32-bit register:
AND the input pixels with the alpha mask
SHR this result so that the bit is in position 0
Multiply so that this bit is expanded to
Hi, just a quick extra idea: You could read about
the PCX file format for 8-bit colors and define one
color to be "opaque". Then you can store your image
in PCX format in RAM and do run length coded BLOCKS
of either overwriting or not overwriting pixels on
screen, without needing per-pixel
Hi!
1) new pixels = (old pixels & mask1) | (new pixels & mask2)
Where mask1 and mask2 are the negated forms of each other.
>> That one only works for boolean masks, but it works on 386.
> By boolean mask, do you mean something like all 1s over the colors for
> opaque and all 0s
On Sun, 22 Jul 2018 19:48:20 -0500, David McMackins wrote:
> By boolean mask, do you mean something like all 1s over the colors for
> opaque and all 0s for transparent? The way I've got it now is just 1 bit
> in the color byte represents opacity. It's either opaque or transparent,
> and then the
16 matches
Mail list logo
