SpriteExtend bug for sprite Append?

Has anyone else found a problem with OS_SpriteOp,35 (Append) which I think is provided by SpriteExtend ?

I have an example of a small program to Append two sprites, which works fine if the sprites do not have masks, but creates a corrupted sprite area/file if they do have masks.

I have tried this on the following RO versions, with SpriteExtend version…
RISC OS SpriteExtend
v4.39 v1.57 04/05/2004
v6.10 v1.83 14/04/2007
v6.1? v1.91 15/09/2009
v5.16 v1.21 19/01/2010
v5.18 v1.47 19/01/2010
… so it looks like a long-standing bug!?

Or it could be a silly error in my test program…

 10 : REM > Append
 30 :
 40 : alen% = 10000
 50 : DIM area% alen%
 60 : FOR I% = 0 TO alen%-4 STEP 4
 70 :   area%!I% = &78563412
 80 : NEXT
 90 :
100 : area%!0  =  alen%
110 : area%!4  =  0
120 : area%!8  = 16
130 : area%!12 = 16
140 : SYS "OS_SpriteOp",&109,area%                      :REM Init
170 : SYS "OS_SpriteOp",&10A,area%,"RAM:Sprites"        :REM load
240 : PROCmerge("nomask","nomask","newnone",0)
241 : PROCmerge("mask","mask","newmask",0)
260 : SYS "OS_SpriteOp",&10C,area%,"RAM:Sprites2"       :REM save
280 : END
290 :
300 : DEF PROCmerge(s1$,s2$,to$,hv%)
310 : SYS "OS_SpriteOp",&11B,area%,s1$,to$              :REM copy 1
330 : SYS "OS_SpriteOp",&11B,area%,s2$,"temp"           :REM copy 2
350 : SYS "OS_SpriteOp",&111,area%                      :REM verify before
370 : SYS "OS_SpriteOp",&123,area%,to$,"temp",hv%       :REM append
390 : SYS "OS_SpriteOp",&128,area%,to$ TO ,,,w%,h%,m%,t%:REM info
410 : REM SYS "OS_SpriteOp",&111,area%                  :REM verify after
430 : SYS "OS_SpriteOp",&128,area%,to$ TO ,,,w%,h%,m%,t%
450 : ENDPROC

The test sprites are 8×8, no palette, Mode 20, containing a red offset +. The nomask sprite has no mask and a grey background, and mask is all red but masked where the grey was.

The Dump of the Sprites2 file shows the problem: The Append creates a mask that is twice as large as it should be, and so the pointer to the next sprite is &40 more than it should be, and this is included in the saved sprite file.

If the rubbish is removed from the file, and the newmask next offset corrected, the sprite file is usable and looks correct.

Can anyone confirm my findings, or say what I am doing wrong?!

Dump of Sprites2 File

 +  0 : 04 00 00 00 10 00 00 00  20 02 00 00 : header

+  C : 6C 00 00 00 : → next @ +78
+ 10 : 6D 61 73 6B 00 00 00 00  00 00 00 00 : “mask”
+ 1C : 00 00 00 00  07 00 00 00  00 00 00 00  1F 00 00 00
+ 2C : 2C 00 00 00  4C 00 00 00  14 00 00 00
+ 38 : BB BB BB BB   sprite
+ 3C   BB BB BB BB
+ 40 : BB BB BB BB
+ 44   BB BB BB BB
+ 48   BB BB BB BB
+ 4C   BB BB BB BB
+ 50 : BB BB BB BB
+ 54   BB BB BB BB

+ 58 : 00 FF 00 00   mask
+ 5C   00 FF 00 00
+ 60 : FF FF FF FF
+ 64   FF FF FF FF
+ 68   00 FF 00 00
+ 6C   00 FF 00 00
+ 70 : 00 FF 00 00
+ 74   00 FF 00 00

+ 78 : 4C 00 00 00 : → next @ +C4
+ 7C : 6E 6F 6D 61  73 6B 00 00 00 00 00 00: “nomask”
+ 88 : 00 00 00 00  07 00 00 00  00 00 00 00  1F 00 00 00
+ 8C   2C 00 00 00  2C 00 00 00  14 00 00 00
+ A4 : 11 BB 11 11   sprite
+ A8   11 BB 11 11
+ AC   BB BB BB BB
+ B0 : BB BB BB BB
+ B4    11 BB 11 11
+ B8   11 BB 11 11
+ BC   11 BB 11 11
+ C0 : 11 BB 11 11

+ C4 : 6C 00 00 00 : → next @ +130
+ C8 : 6E 65 77 6E 6F 6E 65 00  00 00 00 00: “newnone”
+ D8 : 01 00 00 00  07 00 00 00  00 00 00 00  1F 00 00 00
+ E4 : 2C 00 00 00  2C 00 00 00  14 00 00 00
+ F0 : 11 BB 11 11  11 BB 11 11
+ F8   11 BB 11 11  11 BB 11 11
+100 : BB BB BB BB  BB BB BB BB
+108   BB BB BB BB  BB BB BB BB
+110 : 11 BB 11 11  11 BB 11 11
+118   11 BB 11 11  11 BB 11 11
+120 : 11 BB 11 11  11 BB 11 11
+128   11 BB 11 11  11 BB 11 11

+130 : EC 00 00 00 : → next @ +21C * Why! * Should be 1DC = +AC
+134 : 6E 65 77 6D  61 73 6B 00 00 00 00 00 : “newmask”
+140 : 01 00 00 00 07 00 00 00  00 00 00 00  1F 00 00 00
+150 : 2C 00 00 00 6C 00 00 00  14 00 00 00
+15C : BB BB BB BB  BB BB BB BB
+164 : BB BB BB BB  BB BB BB BB
+16C : BB BB BB BB  BB BB BB BB
+174 : BB BB BB BB  BB BB BB BB
+17C   BB BB BB BB  BB BB BB BB
+184 : BB BB BB BB  BB BB BB BB
+18C : BB BB BB BB  BB BB BB BB
+194 : BB BB BB BB  BB BB BB BB

+19C : 00 FF 00 00  00 FF 00 00  mask
+1A4 : 00 FF 00 00  00 FF 00 00
+1AC : FF FF FF FF  FF FF FF FF
+1B4 : FF FF FF FF  FF FF FF FF
+1BC : 00 FF 00 00  00 FF 00 00
+1C4 : 00 FF 00 00  00 FF 00 00
+1CC : 00 FF 00 00  00 FF 00 00
+1D4 : 00 FF 00 00  00 FF 00 00  end of mask

+1DC : BB BB BB BB  BB BB BB BB  <<< rubbish !!!
+1E4 : BB BB BB BB  00 FF 00 00
+1EC : 00 FF 00 00  FF FF FF FF
+1F4 : FF FF FF FF  00 FF 00 00
+1FC : 00 FF 00 00  00 FF 00 00
+204 : 00 FF 00 00  12 34 56 78
+20C   12 34 56 78  12 34 56 78
+214 : 12 34 56 78  12 34 56 78
+21C eof

I can’t see anything you’re doing wrong, so it must be SpriteExtend.

Thanks Sprow for the confirmation I was not going mad! After an afternoon spent investigating, I think I now know what is wrong…

In Tungsten.mixed.RiscOS.Sources.Video.Render.SprExtend.Sources.SprExtend, after label Go_AppendSprite and just before label chunterblock there are lines (all with comment ; merged from 0.62 (GPS))…

        LDR     R14, sp_mode                                      
        MOVS    R14, R14, LSR #27       ; New or old format mask? 
        DebugIf EQ,ag,"Old format chunterblock to be executed"    
        BLEQ    chunterblock            ; process old format mask 
        DebugIf EQ,ag,"New format chunterblock to be executed"    
        BLNE    maskchunterblock        ; process new format mask 

Looks to me like a classic case of depending on BL preserving flags!

I also suspect the second DebugIf EQ should be NE?

For my test case, changing the BLNE maskchunterblock to NOP resolves my problem, but obviously it needs fixing properly.

Can someone with the ability to change the source verify my diagnosis, and fix this please?

Thanks

BLEQ … BLNE

Interesting find! Seems to be broken in RISC OS 3.60 too, so this is a bug trapped in amber.

v4.39 and v6.10 also have the problem! If I get chance I will see if I can check if the return from chunterblock restored flags or not.

I’ve checked in a change (two places doing the same thing), and used your BASIC program to append all 16 combinations of old/new/mask/no mask/H/V successfully.

Brilliant! The old bugs are the best ones to squash. Thanks. Is there any way I can get the new module? (without running 5.19, that is – I still softloading 5.18 until I have finished other testing).