Re: [Ql-Users] WM_INK etc
Dilwyn Jones wrote: Well, the format is well-explained. Without knowing what colour is passed, we can't know happens... Will await a copy of the info to be sent to me before going any further. OK, this is the minimal code to reproduce the problem 100 XM = SCR_XLIM 110 YM = SCR_YLIM 120 WINDOW#0,XM,YM/8,0,YM-(YM/8):WM_BORDER#0,6,1027 130 WINDOW#1,XM,YM-(YM/8),0,0 The problem is a bit complicated, but stems from the fact that QL borders have a ratio of 2:1 and the way this is implemented. For optical reasons WMAN provides some non-standard 1:1 borders and those can wreak havoc when used wrongly (because the rest of the system still assumes borders are 2:1). Because of this I also provide several compatibility modes for the new borders, which let's them have a 2:1 ratio. In this case a non-standard border is chosen and afterwards the unmanaged outline is changed using the second WINDOW call. This causes some calculations to go terribly wrong because they assume a 2:1 border ratio. Solutions: use a QL compatible border, in this case for example $483 (1155). Or make the window a managed one, for example by inserting a OUTLN XM,YM,0,0 line before the WINDOW calls. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WM_INK etc
%1rgb 15 bit RGB As you san see, since in $ff bit 15 is set, this will be treaated as a 15 bit RGB value. I've looked at the code, this will ignore any value in the upper word. Ah, this variation had passed me by somehow, sorry. Well, the format is well-explained. Without knowing what colour is passed, we can't know happens... Will await a copy of the info to be sent to me before going any further. Dilwyn ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] WM_INK etc
I was asked to resolve a QPC problem with a boot program at the Quanta event this number. We managed to resolve it, but are not sure how. The member concerned had (mistakenly) used WM_INK and WM_PAPER to try to set 24-bit colour numbers after using a COLOUR_24 command. The computer concerned started up OK, colours looked OK, but after running an executable program, the emulator locked up after you quit from the first program executed. We trimmed the boot program down until all we had left was colour commands and this seemed to confirm that the issue lay with the mistakenly used WM_ commands. I can’t remember the exact colour numbers used, but they were 24-bit hex values. WM_xxx commands expect a 16-bit value usually, e.g. WM_PAPER #0,$0201 would set paper colour to the system palette’s main window background colour. However, we noticed that if the boot program set something like this: 100 COLOUR_24 110 WM_PAPER #0,$FF : REM trying to set white 120 WM_INK #0,$FF : REM trying to set blue 130 WM_BORDER #0,3,??? : REMark a 3D border (??? because I can’t remember the value used) I would probably have expected line 110 in particular to throw up an out of range or some such message. Anyone familiar with SMSQ/E sources able to explain what was going on? Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WM_INK etc
100 COLOUR_24 110 WM_PAPER #0,$FF : REM trying to set white 120 WM_INK #0,$FF : REM trying to set blue In these lines, the top word will be ignored, even though he won't get blue but some kind of stippled colour in line 120. (the $ff will be trated as $, i.e. a 15 bit rgb colour and the code for that will, in the end ignore the upper word. The $00ff will be treated as a normal Ql colour since the the upper byte of the lower word is 0). 130 WM_BORDER #0,3,??? : REMark a 3D border (??? because I can’t remember the value used) Darn - it would be a good idea to find out. I'd bet that is the problem. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WM_INK etc
Wolfgang Lenerz wrote: 100 COLOUR_24 110 WM_PAPER #0,$FF : REM trying to set white 120 WM_INK #0,$FF : REM trying to set blue In these lines, the top word will be ignored, even though he won't get blue but some kind of stippled colour in line 120. Most likely that's incorrect memory on my part - have asked him for the actual values used. (the $ff will be trated as $, i.e. a 15 bit rgb colour and the code for that will, in the end ignore the upper word. Even though it's a WM_ command? Would they still use the 16 or 24 bit values even though it should have a system palette colour reference $02xx? The $00ff will be treated as a normal Ql colour since the the upper byte of the lower word is 0). So black/white stipple QL colour 255. Don't remember seeing that so need to wait until I hear from him what values were used. 130 WM_BORDER #0,3,??? : REMark a 3D border (??? because I can’t remember the value used) Darn - it would be a good idea to find out. I'd bet that is the problem. Have had problems with some 3d borders before (and discussed it with Marcel some time ago) - usual sympton drawing triangles from top and bottom which overlap in the centre of the window and freeze the program instead of just drawing the 3d border. Dilwyn ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WM_INK etc
Op Tue, 16 Apr 2013 20:59:04 +0200 schreef Dilwyn Jones dil...@evans1511.fsnet.co.uk: (...) 130 WM_BORDER #0,3,??? : REMark a 3D border (??? because I can’t remember the value used) Darn - it would be a good idea to find out. I'd bet that is the problem. Have had problems with some 3d borders before (and discussed it with Marcel some time ago) - usual sympton drawing triangles from top and bottom which overlap in the centre of the window and freeze the program instead of just drawing the 3d border. As far as I know and tested, WMAN2 will produce a red/white stipple (238) for any illegal value. For 24 bit values only the lower 16 bits are seem by WM_XXX. $239 to $2FF is illegal; undefined System Palette Reference. The colour defined for a legal reference could itself be out-of-range though. $4C6 to $4FF is illegal; undefined 3D border. $500 to $3FFF is not defined as anything. None of these produced a hangup in my tests. Maybe the 3D border value itself was legal but the window didn't have the room for it? Some of those borders take up more than 3 pixels. Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WM_INK etc
On 16/04/2013 20:59, Dilwyn Jones wrote: Wolfgang Lenerz wrote: 100 COLOUR_24 110 WM_PAPER #0,$FF : REM trying to set white 120 WM_INK #0,$FF : REM trying to set blue In these lines, the top word will be ignored, even though he won't get blue but some kind of stippled colour in line 120. Most likely that's incorrect memory on my part - have asked him for the actual values used. (the $ff will be trated as $, i.e. a 15 bit rgb colour and the code for that will, in the end ignore the upper word. Even though it's a WM_ command? Would they still use the 16 or 24 bit values even though it should have a system palette colour reference $02xx? The definitions for the colour word are set out in the documentation % exactly as before %0001 palette %0010 system palette %0011 gray scale %0100cc00tttd 3d border (border calls only!). %01ssxxyy palette stipple. see below %1rgb 15 bit RGB As you san see, since in $ff bit 15 is set, this will be treaated as a 15 bit RGB value. I've looked at the code, this will ignore any value in the upper word. The $00ff will be treated as a normal Ql colour since the the upper byte of the lower word is 0). Which is the exactly as before above. If you look at the code (in ee_wman_trap3_asm) you will see that first a test is made whether this is a 15 bit rgb colour, then whether this is a palette stipple, then whether this is an old colour, then a palette colour, then a system palette, then gray colour, then 3d border colour. Have had problems with some 3d borders before (and discussed it with Marcel some time ago) - usual sympton drawing triangles from top and bottom which overlap in the centre of the window and freeze the program instead of just drawing the 3d border. Well, the format is well-explained. Without knowing what colour is passed, we can't know happens... Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
