Window Manager programming in Assembler

[mk79]

And by the way EasySource outputs well commented assembler source code for the menu definition, so there is no magic to it, it's just much easier this way.

[mk79]

Page 104 ...

Wm.swinf, Wm.swlit, Wm.swapp etc set the window to the info window, loose item, application sub window. Then you can use wm.rname or wm.ename from page 124 to edit text in the appropriate area, or us other code to do other stuff with that area.

I've no idea at present, how to set the window back to full size again afterwards! Maybe wm.rptr copes. Never tried it in pure assembly to be honest. As far as I remember ....

Actually I think you simply don't... WMAN will change it if it needs to.

[NormanDunbar]

Tobias informs me that WM.WDRAW is required.

Cheers,
Norm.

[mk79]

Tobias informs me that WM.WDRAW is required.

QPAC2 does it wrong then

[NormanDunbar]

Ha ha!
To be honest, I've never done it in straight assembly. I've always used Easy menu stuff in the past and now George's Easy peasy. So, I'm still learning. Tests will be done at some point soon. I hope.

Cheers,
Norm.

[NormanDunbar]

Thanks Dilwyn,

Unfortunately there's nothing in the text file for pe, Geraint, ee, pointer or whatever else I tried, so no joy there. There used to be a PE disc when I was a librarian, but the online catalogue seems not to mention it, sadly.


Cheers,
Norm.

[Martin_Head]

No response to question 2. Is it that tricky then? I know there are programs for designing sprites and creating the assembler for them. But I would like to know how it works. That,s why I am trying to avoid things like EasyPointer that do some of the hard work for you.

The sprite format is pretty well documented. QL format in the Qptr manual, extended colour sprites for example here:
http://www.kilgus.net/smsqe/display.txt

Not sure if the latter is incorporated into the new Qptr manual. Any specific questions?

I have seen that documentation, which seems to make sense for GD2 drivers. But I am looking at standard QL sprites for example this is the code for the MOVE sprite from my QPTR package.

Code: Select all

*
* Sprite movespr
*
*       Mode 4
*       +------|-------+
*       |aaaaaaaaaa    |
*       |awwwwwwwwa    |
*       |awwrrrrwwa    |
*       |awwrrrrwwaaaaa|
*       |awwrrwwwwwwwwa|
*       -awwwwwwwwrrwwa-
*       |aaaaawwrrrrwwa|
*       |    awwrrrrwwa|
*       |    awwwwwwwwa|
*       |    aaaaaaaaaa|
*       +------|-------+
*
        xdef    move_spr
        xdef    mes_move
mes_move
move_spr
        dc.w    $0100,$0000
        dc.w    14,10,6,5
        dc.l    sc4_movespr-*
        dc.l    sm4_movespr-*
        dc.l    0
sc4_movespr
        dc.w    $0000,$0000
        dc.w    $7F7F,$8080
        dc.w    $617F,$8080
        dc.w    $617F,$8080
        dc.w    $677F,$F8F8
        dc.w    $7F7F,$98F8
        dc.w    $0607,$18F8
        dc.w    $0607,$18F8
        dc.w    $0707,$F8F8
        dc.w    $0000,$0000
sm4_movespr
        dc.w    $FFFF,$C0C0
        dc.w    $FFFF,$C0C0
        dc.w    $FFFF,$C0C0
        dc.w    $FFFF,$FCFC
        dc.w    $FFFF,$FCFC
        dc.w    $FFFF,$FCFC
        dc.w    $FFFF,$FCFC
        dc.w    $0F0F,$FCFC
        dc.w    $0F0F,$FCFC
        dc.w    $0F0F,$FCFC

I know it works, But I cannot understand how the data corresponds to the bit patterns that appear on the screen.

Martin Head

[mk79]

I know it works, But I cannot understand how the data corresponds to the bit patterns that appear on the screen.

The data is in exactly the same format as the QL screen. In this case Green Byte, Red Byte, Green Byte, Red Byte. 8 pixels per byte. Look at the values in binary and you'll more or less see the sprite already.

Bits that are set in the mask are copied to the screen. Bits cleared in the mask are IIRC xored. In this case all xored bits are 0 anyway, so nothing happens in this case.

[tofro]

I have seen that documentation, which seems to make sense for GD2 drivers. But I am looking at standard QL sprites for example this is the code for the MOVE sprite from my QPTR package.

I know it works, But I cannot understand how the data corresponds to the bit patterns that appear on the screen.

Martin Head

Martin,

what you see here is a "native QL mode 4" sprite (marked by the $0100 in the sprite header). That is a direct representation of the bytes in screen memory. And the "weird" format you see here has nothing to do with the Pointer environment, but rather with the QL's hardware design.

QL screen memory in mode 4 is layed out like

Code: Select all

Green        Red
7654321076543210
GGGGGGGGRRRRRRRR

So, every row of 8 pixels occupies one memory word in the screen memory. The first byte is the "green value" of the eight pixels, the second the "red value". A single white pixel (that is, both green and red...) at position 6 (from the left) surrounded by 7 black pixels would look like

Code: Select all

0000010000000100

in binary, and

Code: Select all

$0404 

in hex.

The mask simply says what pixels are "valid" and end up on the screen (1) and what lets the background shine through (0).

Tobias

[Silvester]

1. How do I determine how much memory I need to reserve for the Window Working Definition...

If you use the macro library supplied with QPtr then there is a variable which keeps a running total for the working definition:

ww[l].[currw]

where [l] is name of layout for current window [currw].

But of course, to use the macros you first need a good understanding of QPtr and its data arrays