Draw module EOR Bug?

Hi

I have been setting up the build environment so I can build RiscPCB on the raspberry Pi
I can now build RiscPCB on the PI but it has a redraw bug I use the draw module to create
a cross-hairs that gets plotted by using EOR. On the Iyonix is works fine but on the Raspberry
PI it fails I have tried it on the latest RC12A and an older ROM so it seems its been there for a while.

I have a simple basic program below to illustrate the problem :-
it can be downloaded from here www.mbelect.co.uk/ex1.zip

On the Iyonix the program produces an animated grey line , on the PI it produces a rainbow effect very
nice but not what I was hoping for :-)

MODE MODE
DIM path% 100
DIM join% 100

OFF

width%=10
x=500:y=500:x1=1000:y1=1000

path%!(0*4)=2
path%!(1*4)=x << 8
path%!(2*4)=y << 8
path%!(3*4)=8
path%!(4*4)=x1 << 8
path%!(5*4)=y1 << 8
path%!(6*4)=4
path%!(7*4)=0
path%!(8*4)=0

join%!(0*4)=&010102
join%!(1*4)=0
join%!(2*4)=0
join%!(3*4)=0

  SYS "ColourTrans_SetGCOL",&80808000,,,0,3
  SYS "Draw_Stroke",path%,0,0,0,width%<<8,join%,0

REPEAT

  Q=INKEY(10)

  SYS "Draw_Stroke",path%,0,0,0,width%<<8,join%,0

  x=x+10:x1=x1+10
  path%!(1*4)=x << 8
  path%!(4*4)=x1 << 8

  SYS "Draw_Stroke",path%,0,0,0,width%<<8,join%,0

  UNTIL FALSE

  END

It certainly works fine here on Iyonix and PandaRO. Not in a position to try it on the RaPi until I get a new monitor sorted and the Pi reactivated.

I can confirm it doesn’t work on a pi. I get a 45 degree about 80mm line moving left to right on an Iyonix. The pi shows a blue and green striped triangle and a long grey rectangle left where the line should have erased.

Its good to hear that the error occurs on another PI

It seems to be only drawfile commands as command like PLOT MOVE etc

all work OK

The error is absent under Virtual Risc PC, but if you load !SpecialFX (which is included in the RC12a SD card image for the Pi [in !Boot.Resources], but is not included as standard on the other platforms) then the error appears in Virtual Risc PC.

It is therefore a ‘bug’ in !SpecialFX (which performs vector anti-aliasing by intercepting calls to the Draw module and uses Computer Concepts’ GDraw module instead). This effect is documented in the information with !SpecialFX and is a by-product of the vector anti-aliasing (the edges of the plotted line are blended but if you plot two images close to each other, the blending can interact [I think]). It is an issue for the screen display, press f12 and redraw and the ‘built-up’ error disappears. It is also not present when printing.

It is easy to configure !SpecialFX not to perform vector anti-aliasing for specific applications.

Thanks for tracking down this bug, I will not be able to try the !SpecialFX fix until Tuesday. I have been using draw to produce the cross-hairs because it was easy to plot lines of different thickness, I might change RiscPCB to use plot,move,draw commands and just have the standard line thickness. Normally as you zoom in RiscPCB increases the line thickness to reflect the zoom level it might be worth changing this feature so that SpecialFX can still be used in other areas of the program.

Thanks again for your help.

If you are doing the plot, rub out, replot within a Wimp_UpdateWindow loop rather than a Wimp_RedrawWindow loop (the former leaves what is there already for you to overdraw just the changed bits and the latter clears the rectangle to the background colour for you to overdraw everything that is to be shown there) then vector anti-aliasing means that when you plot (for example) the cross hairs, the immediately surrounding pixels are anti-aliased so that the cross hairs appear ‘finer’ and more exactly positioned. The down side is that if you move the cross hairs a bit one way, then you need to replot the area behind the previous cross hairs rather then ‘rub out’ (using EOR) the previous cross hairs before replotting the cross hairs in their new position.

In my application !SignalBox, I had the whole graphic formed as a draw file in memory and just drew the changed items (using UpdateWindow) but made sure the items had a small surrounding ‘halo’ of background colour. For moving elements that slid over other elements it got much more tricky (animated mechanical locking) and I traded speed (leaving a trail) for elegance (doing a full redraw for each part of the move) but made sure that it got a full redraw when the elment completed its move. The trail was not from vector anti-aliasing (it was from the trailing edge of the bit that was moving) but the effect was the same.