Transparent Windows

Someone asked how I created the rather nice see-through effect on the Q-Dock window.

The answer is a little complicated and not for the faint of programming heart!

The PE data structures include a facility whereby you can set a bit to cause a menu window not to clear when initialised, in effect, ‘do not do a CLS on this window’. Then, I draw the graphical dock using an ‘alpha-blend’ GD2 sprite, a facility added to the new sprites on some GD2 systems. Actually, I’m not sure if alpha-blend sprites works on all GD2 systems or just ones where Marcel had a hand in the development, like QPC2!

If you want to look up the ‘do not clear window’ in pointer environment (PE) documentation, look for the wda.clfg notes under ‘Window Attributes’. To use it from SBASIC involves some convoluted POKEs direct into PE data structures to set/reset wda.clfg – only for seasoned (and brave!) programmers. The MWDEF function in the example lines below is an Easyptr extension to locate the Menu Working DEFinition.

3940 adr = MWDEF(#0) + HEX('28') : POKE adr,PEEK(adr) || 128 : REMark transparent main window
3950 adr = PEEK_L(MWDEF(#0)+100)+(20*(1-1))+8 : POKE adr,PEEK(adr) || 128 : REMark transparent info win 1
3960 adr = PEEK_L(PEEK_L(MWDEF(#0)+HEX('70'))+(4*(1-1)))+HEX('08') : POKE adr,PEEK(adr) || 128 : REMark transparent app win 1

Not quite sure why I used HEX(’28’) etc instead of the simpler $28 notation?!?

||128 for example means OR 128 while && 127 means AND 127 (to handle bits individually within a byte).

To reset wda.clfg afterwards (to restore normal clearing of the window) you’d need to use something like this:

3820 adr = MWDEF(#0) + HEX('28') : POKE adr,PEEK(adr) && 127 : REMark non-transparent main window
3830 adr = PEEK_L(MWDEF(#0)+100)+(20*(1-1))+8 : POKE adr,PEEK(adr) && 127 : REMark non-transparent info win 1
3840 adr = PEEK_L(PEEK_L(MWDEF(#0)+HEX('70'))+(4*(1-1)))+HEX('08') : POKE adr,PEEK(adr) && 127 : REMark non transparent app win 1

The snag with this technique is that the PE saves the Window background. So if you move Q-Dock’s window, for example, it has to redraw itself immediately as the background will be different in the new location. If another program ‘behind’ Q-Dock moves, it affects the Q-Dock window background, so you then have to manually redraw Q-Dock using the little green arrow on the left of its window. The poor PE was never really designed to cope with all this, bless it.

Wherever possible, this enforced manual redrawing is hidden from the user, e.g. when the pointer is out of Q-Dock’s window for more than a few seconds, it ‘auto-hides’ whereby it closes its windows, then when you move the pointer back to the edge of the screen, it reappears and redraws itself.

3 thoughts on “Transparent Windows

  1. > Actually, I’m not sure if alpha-blend sprites works on all GD2 systems or just ones where Marcel had a hand in the development, like QPC2!

    All GD2 drivers got the treatment. But of course on 8-bit colour systems alpha blending looks a bit more rough…

    > Not quite sure why I used HEX(’28′) etc instead of the simpler $28 notation?!?

    I think $28 is a SMSQ/E feature and cannot be compiled, perhaps that’s why?

  2. Compiling – that’ll be the reason of course. Transparent Windows in Q-Dock can be turned off if you prefer, and of course you can use dock sprites without alpha-masks (bitmap masks) if it looks poor on your system. And readers, I hope you appreciate that without the hard work Marcel and Tony Tebby before him put in on SMSQ/E and GD2 development (GD2 being the “colour drivers” of course) none of this would be possible.

Leave a reply to Dilwyn Cancel reply