FMSLogo can do some anti-aliasing, but not always.
So for example I used a recommended display resolution of 1920 x 1080 and a size of 100%.
In this case lines and circles were done in alias-mode without any smoothing.
It is funny that a size-change from 100% to 125% all of a sudden gave me anti-aliasing
for lines and circles and even areas.
Is it possible that the operating system itself has to do anti-aliasing
to go away from physical pixels to the virtual pixels of another resolution?
On the other hand, using Fonts in FMSLogo makes it easy for me to switch between alias and anti-alias,
because I can switch between 3 and 4 somewhere in the property list.
My remaining question: Is there a way to use anti-aliasing in FMSLogo-graphics
in every pre-chosen Windows-screen resolution and every size-percentage?
The operating system only does anti-aliasing when asked. Everything is drawn on a raster and there's a lot of programming elements in FMSLogo which depend on this. This drawing is not anti-aliased. When you zoom in/out, the raster doesn't change, only how the raster is drawn on the screen. FMSLogo scales the raster image and, in some cases, the scaling does use anti-aliasing, even though the raster remains pixelated.
There are two other places that do anti-aliasing that you didn't mention:
BITFITand(BITMAPTURTLE "true).Except for the fonts, none of the anti-aliasing behavior is documented and it's subject to change in a future release if it becomes burdensome. For example, the turtle's triangles used to be anti-aliased when zoomed and now they're not. This changed when I was trying to make bitmapped turtles on huge drawing surfaces faster for your "copter" requests because it was too hard to keep the memory usage low, keep the bitmapped copter fast, and also anti-alias the turtles that were drawn with lines.
Regardless of the size of the drawing surface, whenever you ZOOM, the image is anti-aliased on the screen. At 100% scale (
ZOOM 1), there is no anti-aliasing on the screen.You can use
PIXELandSETPIXELto implement your own anti-aliased line drawing.Thanks a lot for your comprehensive information.
I now found out that my observations have been misleaded in a remarkable way
when I used the following procedures to do some anti-aliasing-experiments:
I called 'draw_pattern' and looked at the result on the screen. To investigate it further, I needed a BMP-file to get it into paint.net, which is my favourite educational graphics program.
I used two different ways to achieve it: the first was a Windows-screenshot to be taken from the clipboard into paint.net, the second was a BITSAVE-file made by FMSLogo directly to be loaded by paint.net.
The comparison as shown in the attachments was astonishing:
The screenshots all appeard anti-aliased, while the BITSAVE-produced images were pixelated!
So my conclusion is that the anti-aliased results did not come from FMSLogo directly but from a transformation done along with the screenshot. Considering that the screenshot could not rely on the algorithms based on line- or circle-formula, its results are remarkably good.
What kind of algorithm may they have used? Could it be used by FMSLogo directly, too - for any kind of drawing? Because it should be clear that treating lines with BRESENHAM- and WU-algorithms can only be the beginning. The edges of all kinds of areas have would also to be anti-aliased like in fonts. So it is a promising idea to anti-alias a drawing as a whole by a common algorithm. Sorry, I know too little of it.
So practically everything is clear, and we have all we need for the moment, expecially as the most important of all, the fonts, can be pixelated or anti-aliased just as desired. FMSLogo-drawings are always pixelated, and a ZOOM can loose a lot of information while it does some kind of anti-aliasing or interpolation, but it's safe, because there is always an unchanged original image behind it, as I know or at least hope.
How to pick apart the whole confusing subject while explaining it to students, will be a challenge of its own for us.
But for the moment we have all to go ahead.
You mententioned our still pending copter-project. There was a hurdle: If some user would play around with the scrollbars, there would be no way to know where the copter is. But we need this knowledge only when the copter has to be reset, and not continuously. So everything is solved with the newest extension of machine. We have an other problem with machine, but I better tell this in a separate ticket. Copter still is waiting for more progress, but may be next spring we can finish it as a project for older students (starting with 17).