nanogui: Re: [FIX] add alpha channel into GdDrawImage software handling
Subject:
Re: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From:
"Greg Haerr" ####@####.####
Date:
12 Mar 2010 05:47:10 -0000
Message-Id: <0d5701cac1a7$7288d630$6564a8c0@winXP>
> 1) I have tested modified GdDrawImage() code on SCREEN_PIXTYPEs below.
> ( only for little endian. )
SCREEN_PIXTYPE = MWPF_TRUECOLOR8888
SCREEN_PIXTYPE = MWPF_TRUECOLOR0888
SCREEN_PIXTYPE = MWPF_TRUECOLOR888
SCREEN_PIXTYPE = MWPF_TRUECOLOR565
SCREEN_PIXTYPE = MWPF_TRUECOLOR555
> It works well. (perfectly)
Great!
> 2) I have modified a few. ( GdDrawImage() )
> modifying struct RGB565,RGB555 field order on big endian. (
> conditional compile )
> In case rgb565/rgb555 for big-endian, I guess that a byte swap
> operation which is the last
> step of > GdDrawImage() is not proper. I think that it is proper to
> modify like your
> rewritten struct ARGB.
No, I originally wrote it like that, but I don't think so.
You are saying that
struct {
unsigned char r:5;
};
allocates the TOP (MSB) bits in big endian? I don't think so.
I agree it allocates the top BYTE in big endian, but the
bits in the byte are still allocated from 0 up, not 7 down.
This will still allocate the LOWER 5 bits in either endian,
I think.
So the issue is that bytes are re-ordered, but NOT bits,
in little vs big endian.
Because of this, I ordered the bits the same way as
little endian, and then byte-swapped them on write.
Obviously we need to look at compiler output to
know how bits are ordered on big-endian.
Comments?
> 3) Additionaly, test for tiff alpha channel image have been completed.
> It works well.
Thanks, I'll add some test tiff images to git.
> 4) very trivial patch code for korean language.
> MWTF_DBCS_KSC -> MWTF_DBCS_EUCKR in 1demo.c
Done.
> I have ever tried to construct a big endian test environment. It may be
> possoble by using QEMU.
> A simple big-endian program can run on i386 pc by QEMU.
I will look into this!
Regards,
Greg
