Script API: support anti-aliased operations of DynamicSprite / Filter setting

[ivan-mogilko]

A user sent a request to me recently, asking about adding anti-aliased variants of Resize and Rotate functions to DynamicSprite.
Technically this is possible to do, and there seem to be ready implementations for both AA scaled blit and rotate in aastr library which we use.

But I have concerns about making such change future compatible, specifically in relation to #2059 (hardware accelerated dynamic sprites). If the sprite would internally be a list of operations, how would that affect the choice of API for adding Anti-Aliased option?
Because while sprite transformations are separate operations for software renderer, they are a single merged transform operation for hardware renderer.

I suppose that then such AA option could be not a parameter per operation, but a DynamicSprite's property, applied to ALL operations, where it makes sense: Resize, Rotate, and when something is drawn upon this dynamicsprite.
In other words, I suppose, it may be something like attribute bool DynamicSprite.Antialiased;, and this property would tell which filter to use when rendering the texture (it may be later renamed into attribute eGraphicsFilter DynamicSprite.Filter).

But on the other hand this will complicate the situation with regular software operations. Because, while with hardware renderers, the filtering is delayed until the sprite is finally rendered, and also may be changed anytime, the same is not true in software mode. Suppose you set AA mode, and perform Resize or Rotate, and then switch AA mode back to default off. In software mode the operations have already been performed, and cannot be "redone". Unless we actually store the whole list of operations in the software mode too, to allow full sprite's recreation. We must also somehow define that this option affects all operations, regardless of where is it set before the drawing operations, or after.

So, these concerns make things uneasy.

Alternatively, we could support this as an parameter to Rotate and Resize for the time being, and consider what to do with this later when working on a hardware-accelerated dynamic sprite, knowing that likely some things will get change in logic, or deprecated.

[AlanDrake]

Ideally, one would be able to specify different filters for upscaling and downsampling.
The software renderer doesn't have to support advanced drawing operations, we could only have base functionality there.

[ericoporto]

There is an option to make the property DynamicSprite.Filter something that can be set only at the dynamic sprite creation and the property itself being read-only.

Edit: reading aastr library code, it seems the stretch can only really make the size bigger with anti-alias, but not smaller (unless I am misreading the code, I haven't actually tried to build to see if resizes down correctly)