#270 AreaMove/AreaDraw does not support negative coordinates

[Yannick Erb]

While using AreaMove/AreaDraw you can't submit negative coordinates.
If you do so, display is corrupted and all further use of AreaMove/AreaDraw leads to corrupted display (even if only positive coordinates are passed).

While porting AmiFIG I had to add additional Polygon Clipping Algorithm
I've used the Sutherland_Hodgeman algorithm that's very easy to implement and might be implemement in graphics.libray
(http://www.aftermath.net/library/articles/clippoly/)

[Pavel Fedin]

If you know what to fix and where, why don't you apply the fix yourself?
However, please note that perhaps the problem is deeper. May be you should implement clipping in lowlevel graphics routines. Do i understand it right that on AmigaOS it's valid to Move() to a negative offset and "draw" something there?
If so, the clipping should be implemented in DoPixelFunc() and DoRenderFunc(). Our graphics drivers do not check coordinates against negative values, and, of course, you hit wrong memory.
You may also verify the problem on hosted. It's likely that it won't appear there, because host bitmap routines handle clipping perfectly.

[Yannick Erb]

Issues with AreaFill

[Yannick Erb]

There is more than this, negative coordinates can't be handled for sure because coordinates are stored in UWORDs.

But, if you look at the attached picture, you'll see what happes when you use the function on big bitmap (> 1000 x 1000 shows this) with big numbers of points (around 700 in the example).
After some lines, the filling starts again at the top line with some horizontal shift.

[Yannick Erb]

I might have found the issue, would be nice if someone can try.
in areafill.c (from graphics.library), the function LineInTmpRas() uses a UWORD for the variable index.
If the temp rastport is too big, there is certainly an overflow of the index and you start to draw from the beginning again.
index should be converted to ULONG.