Well, that led me down a rabbit hole where I found two problems and now I'm having a third that I need advice on. The main problem was that I was forgot to set the draw op to src when doing the final draw of the window, so it was defaulting to SoverD. Second, unrelatedly, the alpha masks were being doubled (or halved, I guess) when filling an alpha channel because I was using the same id as the src and the mask since they have the same bounds, so the mask was getting multiplied through a second time, but that wasn't affecting the background disappearing since they were opaque colours.
Now, after setting the drawop to src, I'm getting a black background instead of a dark blue one. I tried changing the colours arbitrarily to see if black was just how it represents an alpha channel when there's nothing under it, and with lighter colours it's drawing a yellow background on drawterm and a pink one on the Pi. I've narrowed it down to the fact that the the screen channel descriptor on the Pi is different. When I do cat /dev/draw/new, it's telling me it's an r6g5b6 channel while in drawterm it's x8r8g8b8. I'm not sure how that's possible though, because I'm fairly sure I remember reading in a man page that channels had to be multiples of 8, though I can't find where I read that now. Is there anything I can do about this? I'm fairly sure an r6g5b6 channel should be able to represent yellow as a combination of red and green, but the the format of colours in a draw operation is irrespective of the channel format, so I can't be doing anything wrong there. Oddly, the places where I'm directly replacing pixels in the buffer with 'y', where the channel format *does* matter seem to be fine, but I think that might just be luck because the gradient is mostly red and green. On Sun, May 29, 2016 at 8:58 AM, Charles Forsyth <charles.fors...@gmail.com> wrote: > > On 29 May 2016 at 13:44, Dave MacFarlane <driu...@gmail.com> wrote: > >> Why would the alpha channel work differently with the same image from the >> same code with the same hardware >> depending on the driver? >> > > Because there might be a difference in the way the components inside the > pixel word are being interpreted or used by memdraw. > -- - Dave
