Earlier I wrote:
>Another tip came from Albin Hessler himself (author of Easyptr). As
it
>happens, I had got this right, but it's worth passing on. When
setting
>loose item justification, you need to think of where the sprite
origin
>will be. If the default of centre justification is used for the loose
>item and the origin is top left, the origin is drawn at the centre of
>the loose item and so the sprite cannot fit unless the loose item is
>proportionately larger than the sprite. As it happens, if the sprite
>is assigned by name MITEM #channel%,loose_item,-2,'spritename' you
>always get either an out of range error or invisible sprite, so this
>didn't help.
I slightly misunderstood this and got it wrong, as it's not this
simple, sorry. I have just tried putting 32x24 sprites (linked to
ptrmenr_cde resident, interpreted) into a loose item of the same size.
The origin of the sprites is top left, this would only work if centre
justified, not left justified sorry (I got this the wrong way round by
misreading the author's suggestion).
For those who like to probe such things:
I appended 3 test sprites (a1_spr, a2_spr and a3_spr) to ptrmenr_cde
then rebooted with this resident so the test program could find the
sprites appended in memory rather than from disk to get around the
name problem.
PRINT SPRA(1),SPRA(2),SPRA(3) gave the correct addresses in memory.
PRINT SPRA('a1'),SPRA('a2'),SPRA('a3') gave 'not found' error. I also
tried SPRA(a1) SPRA(a1_spr) and SPRA('a1_spr') etc permuations to
ensure I understood the naming conventions correctly. So, I am now
convinced Thierry is right and Easyptr has problems coping with
sprites referenced by name, but handles sprites referenced by address
or number OK. I guess this has not really become apparent before due
to the fact that you don't often want to assign sprites to loose items
in interpreted programs very often, it's just that my program allows
users to select preferred sprites for the icons in the program.
OK, this won't mean a thing to those not conversant with Easyptr, QPTR
etc, but it's as well to get these facts about our programming tools
out in the open to be aired in case other QL programmers encounter the
same problems. I just hope I can persuade the author to address this
little problem with Easyptr (and upgrade it to better handle GD2
facilities perhaps!)
--
Dilwyn Jones
[EMAIL PROTECTED]
http://www.soft.net.uk/dj/index.html
