GitLab

Detail:
  s/StartUp - When the alpha drop shadow is in use, the foreground sprite is one row+column larger than normal, to allow the shadow to be feathered. However the drag box calculations weren't taking this into account, resulting in slightly wonky coordinates that can result in redraw issues in some situations (specifically, the screen area under the sprite's current location is filled with a plain colour if the bounding box overlaps the graphics window in a certain manner). Introduce orig_x_size and orig_y_size variables so that the drag box calculations can be correct regardless of how much padding is added to the image (with the limitation that the padding must be on the right / bottom)
  Also, fix the AtPointer support so that the pointer is placed at the centre of the input sprite, not the padded sprite.
Admin:
  Tested on Raspberry Pi
  Resolves ticket #402, and similar corruption with animated windows (e.g. start a drag of a sprite which overlaps !Alarm's icon)


Version 0.21. Tagged as 'DragASprit-0_21'

Detail:
  s/StartUp - Avoid unnecessary remainder calculations in DivRem macro
Admin:
  Tested on Cortex-A15


Version 0.20. Tagged as 'DragASprit-0_20'

Detail:
  s/Drag - When moving the dragged sprite, avoid plotting over the top of its old location in order to prevent flicker caused by overdraw. This flicker wasn't so apparent with the older translucent or hatched sprite plotting, but is a lot more noticeable with ABGR sprites.
  s/StartUp - Use 50% alpha for the ABGR sprite in true colour modes, to match hatching & non-drop shadow variants. Also make the drop shadow completely invisible when behind the sprite - better than having it there but making it almost completely imperceptible in order to try and hide the fact that it always looks a bit funny
Admin:
  Tested on Iyonix


Version 0.19. Tagged as 'DragASprit-0_19'

Detail:
  Drop shadows were disabled in DragASprite 0.17 when using translucency due to them looking a bit ugly. This change brings them back, but implemented in a different manner to produce a better result.
  Instead of using a standard sprite and rendering it with translucency, we create a sprite with an alpha channel and use the alpha to control the relative intensity of the dragged sprite and its shadow. The alpha channel also allows us to feather/blur the shadow, getting rid of the hard edges that were mostly resposible for the previous version looking so poor.
  s/Drag - Adjust TranslucentPlot to support plotting of the ABGR sprite
  s/StartUp - Adjust drag startup logic so that >2bpp uses an ABGR sprite, 2bpp uses a translucent plot (+ hard shadow), and 1bpp continues to use dithering/hatching. Add new GenerateTranslucentDropShadow routine that's responsible for creating the ABGR sprite. Adjust GetByteSizeOfSprite to return separate values for the size of the foreground (masked/ABGR) and background sprites.
  s/Support - Add new check for whether the kernel supports ABGR sprites
Admin:
  Tested on BB-xM
  Fixes issue #390:
  https://www.riscosopen.org/tracker/tickets/390


Version 0.18. Tagged as 'DragASprit-0_18'

Detail:
  s/StartUp - By popular demand, automatically disable the drop shadow when we're performing a translucent drag, as general opinion seems to be that translucent drags will look better without it. Reportedly this also matches the behaviour of ROL's version of the module.
Admin:
  Tested on BB-xM


Version 0.17. Tagged as 'DragASprit-0_17'

Rely on kernel's error instead of "Error foo" for RMENSURE.
Functionally identical, retagged as DragASprit-0_16.

Detail:
  As per ROL's version of DragASprite, we now support translucent drags as well.
  As long as you have a suitable SpriteExtend version, DragASprite will try and use translucent drags wherever it used to use hatching before.
  The only exception to this is in 1bpp modes, where blending is essentially impossible and so it sticks with the old hatching code.
  As with ROL's version, the only way of disabling translucent drags (short of loading an older SpriteExtend) is to set bit 8 of the flags in R0 when calling DragASprite_Start.
  File changes:
  s/Drag - Drag sprite rendering now goes via new TranslucentPlot routine, to allow translucent/non-translucent rendering to be performed as appropriate
  s/Startup, s/Support - Updated with code to detect when translucency is and isn't supported. A few OS_SpriteOp reason code magic numbers replaced with symbols.
Admin:
  Tested on BB-xM


Version 0.16. Tagged as 'DragASprit-0_16'

  Updated to build using objasm instead of aasm.
  Sources changed to be objasm-compatible.
Admin:
  Requires Library 0.71 or later.
  Requires BuildSys 3.06 or later.
  Requires Env 0.65 or later.

Version 0.15. Tagged as 'DragASprit-0_15'

Version 0.14. Tagged as 'DragASprit-0_14'