Ticket #541 (Fixed)Tue Jan 04 22:37:05 UTC 2022

Unmangled prog segment:
2590 : a=(1<<16)*COS*zoom
2600 : b=(1<<16)*0.1*SIN*zoom
2610 : c=0
2620 : d=(1<<16)*zoom
2630 : e=-(ddReg%!24)*zoom+256*cx%pw%*zoommm%*zoom
2640 : f=-(ddReg%!36)*zoom+256*cy%mm%*zoom
2650 : stZ%=stX%
2660 : fnZ%=fnX%
2690 : ddtran%!0=a
2700 : ddtran%!4=b
2710 : ddtran%!8=c
2720 : ddtran%!12=d
2730 : ddtran%!16=e
2740 : ddtran%!20=f
2760 : SYS “DrawFile_Render”,0,bufmd%stZ%,fnZ%-stZ%,ddtran%

The 2nd error is expected; no version of SpriteExtend offers to shear a JPEG (because JPEGs are kept compressed in memory, and a shear operation requires random access to source pixels, and that’s not conveniently possible with a compressed data stream) – you’d need to turn it into a sprite then shear that.

The 1st error is the odd one. The mystery markup the bug tracker uses has mangled your program, try to ZIP it and attach instead. Can’t immediately think of why DrawFile_Render wants to read from SCSI:

If you put a plus sign at the beginning and end of each blob of green …

Unmangled prog segment:
2590 : a=(1<<16)*COS *zoom
2600 : b=(1<<16)*0.1*SIN *zoom
2610 : c=0
2620 : d=(1<<16)*zoom
2630 : e=-(ddReg%!24)*zoom+256*cx%pw%*zoommm%*zoom
2640 : f=-(ddReg%!36)*zoom+256*cy%+mm%*zoom
2650 : stZ%=stX%
2660 : fnZ%=fnX%
2690 : ddtran%!0=a
2700 : ddtran%!4=b
2710 : ddtran%!8=c
2720 : ddtran%!12=d
2730 : ddtran%!16=e
2740 : ddtran%!20=f
2760 : SYS “DrawFile_Render”,0,bufmd%+stZ%,fnZ%-stZ%,ddtran%

on an ARMX6 running RISC OS 5.2312 Jan 2018

If you put a plus sign at the beginning and end of each blob of green …

Unmangled prog segment:
2590 : a=(1<<16)*COS(theta)*zoom
2600 : b=(1<<16)*0.1*SIN(theta)*zoom
2610 : c=0
2620 : d=(1<<16)*zoom
2630 : e=-(ddReg%!24)*zoom+256*cx%+pw%*zoom+mm%*zoom
2640 : f=-(ddReg%!36)*zoom+256*cy%+mm%*zoom
2650 : stZ%=stX%
2660 : fnZ%=fnX%
2690 : ddtran%!0=a
2700 : ddtran%!4=b
2710 : ddtran%!8=c
2720 : ddtran%!12=d
2730 : ddtran%!16=e
2740 : ddtran%!20=f
2760 : SYS “DrawFile_Render”,0,bufmd%+stZ%,fnZ%-stZ%,ddtran%

on an ARMX6 running RISC OS 5.2312 Jan 2018

Gives ‘Unknown or missing variable at line 2590’
I’m not sure what the program segment provided is trying to show, other than a SYS call to DrawFile_Render.

Can you provide a minimal working example (eg. with a Draw area in memory, or a sample DrawFile and matching program that loads it), because I don’t think you’ll get many takers to investigate the SCSI$Path error if they first have to invest a load of time trying to recreate the error.

I have a repeatable set up that produces the error each time a particular page is turned, in a version of the !RingBind programme before I included error trapping for skewed JPEGs.

DrawFile_Render produces this error (System variable ‘SCSI$Path’ not found at line 2760) when it renders a draw file that includes a JPEG where the transformation matrix in R3 is skewed (i.e. b<>0). It renders the image correctly skewed (so long as the error box does not overlap the affected page) but with the JPEG concerned missing. !RingBind then continues to work if the error is accepted and the page widens to the next image, then the error comes again. Once the page is fully turned, the JPEG is no longer skewed and renders with no error.

While !RingBind is running, if I press f12, set SCSI$Path to SCSI::$ then press ENTER (redrawing the desktop), I either get a bad error pointer from SWI 400xx (didn’t manage to note it down) or an error SCSI$Path refers to itself (not unexpected) or a strange error ‘(Number)’ in each case from the line that first invokes DrawFile_Render as a (non skewed) image is rendered. So it seems that when DrawFile_Render invokes SpriteExtend to render a skewed JPEG, the error buffer returned is unpredictable.

I now have an example, attached.

<code><pre> 10 : REM >Test
20 :
30 : DIM buf% 4000000 , tm% 24
40 : P=OPENIN
50 : len%=EXT#P
60 : CLOSE#P
70 : OSCLI)
80 : theta=0.1
90 : zoom=0.5
100 : cx%=10
110 : cy%=10
111 : shift%=0
120 : a=-(1<<16)COSzoom
130 : b=-0.1*(1<<16)SINzoom
140 : c=0
150 : d=(1<<16)zoom
160 : e=-(buf%!24)zoom+256*cx%
170 : f=-(buf%!36)*zoom+256*cy%
180 : tm%!0=a
190 : tm%!4=b
200 : tm%!8=c
210 : tm%!12=d
220 : tm%!16=e
230 : tm%!20=f
231 : REM LOCAL ERROR
232 : REM ON ERROR LOCAL shift%=8
240 : IF shift% AND 8 THEN b=0
250 : SYS “DrawFile_Render”,0,buf%,len%,tm%
260 : REM RESTORE ERROR
261 : END</pre></code>

I now have an example, attached. Running it on a cleanly booted machine produces the error ‘System variable SCSI$Path not found’. Running it again rpoduces ‘Transformed JPEG plotting is not supported …’.

On the Titanium, the error message is ‘System variable ADFS$Path not found’ in case that helps.

Thanks for the test case; I get ‘(Number)’ when run here. I suspect, as you say, there’s some bogus error block being returned and all we’re seeing is a previous error from whoever last called MessageTrans. That’s the puzzle to unpick.

To be clear though, for RingBind, you’ll not get past that (as explained on 6th Jan) JPEGs can’t be transformed on the fly. You’d be much better plotting the Draw file flat into an off screen sprite for the current mode, then using OS_SpriteOp to do the skew/transform – that avoids having to render the Draw file dozens of times, so would probably be quicker overall anyway.

The error ‘(Number)’ (from OS_EvaluateExpression, I think) is telling you (badly) that DrawFile_Render is failing to render the text in the Draw file because the font ‘Arial’ is not present on your system. It should render the text in the System font and not produce an error at all. It is, of course, a bogus error block.

Could you try the attached? This DrawFile module copies the error away at the point it is raised so that at the end of the render you get the true error not some stale pointer.

Tried it and replied by PM.

In !RingBind I just trap errors from DrawFile_Render and try non-skew plotting in place of skew plotting and then skip the render if that errors too.

Fixed in DrawFile 1.62.