Page 2 of 4
Re: Window Manager programming in Assembler
Posted: Sun Oct 23, 2016 7:56 pm
by 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.
Re: Window Manager programming in Assembler
Posted: Sun Oct 23, 2016 8:10 pm
by mk79
NormanDunbar wrote: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.
Re: Window Manager programming in Assembler
Posted: Sun Oct 23, 2016 10:27 pm
by NormanDunbar
Tobias informs me that WM.WDRAW is required.
Cheers,
Norm.
Window Manager programming in Assembler
Posted: Sun Oct 23, 2016 10:33 pm
by mk79
NormanDunbar wrote:Tobias informs me that WM.WDRAW is required.
QPAC2 does it wrong then
Re: Window Manager programming in Assembler
Posted: Mon Oct 24, 2016 11:23 am
by 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.
Re: Window Manager programming in Assembler
Posted: Mon Oct 24, 2016 10:29 pm
by 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.
Re: Window Manager programming in Assembler
Posted: Tue Oct 25, 2016 10:53 am
by Martin_Head
mk79 wrote:Martin_Head wrote: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
Re: Window Manager programming in Assembler
Posted: Tue Oct 25, 2016 11:59 am
by mk79
Martin_Head wrote: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.
Re: Window Manager programming in Assembler
Posted: Tue Oct 25, 2016 12:09 pm
by tofro
Martin_Head wrote:
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
in binary, and
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
Re: Window Manager programming in Assembler
Posted: Tue Oct 25, 2016 2:39 pm
by Silvester
Martin_Head wrote:
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
