Overlay use-cases

[abstauber]

All this overlay talk made me curious: what can overlays be good for nowadays?

• Sprite Replacement
  In the past I've used characters for this because they provide pixel perfect collision detection outside of AGS script. And that was way faster than search for transparent pixels.
• Particles
  Right now I'm using a custom struct and draw all particles on a big surface. Would it be better that each particle would be it's own overlay?
  
• Tiles
  Same story - would it be faster to say assign each tile on screen to it's own overlay instead of raw drawing everything to a room surface?
  

I still haven't fully understand the performance gain using overlays instead of drawing everything directly to a surface.

[Crimson Wizard]

As of AGS 3.6.0 Overlays are the only graphical object in game that:
- unlimited in numbers;
- may be freely created and deleted in script;
- has a sprite on it.

Other objects (gui, characters, etc) are only created at design-time; room objects are also limited in number.

This makes Overlay useful for creating temporary custom objects that do not have any additional behaviors, a simple "sprite" object on screen.
Since you know Overlay's position and size, you may also script trivial hit detection (simulate clicking on overlay), collision, and anything else. Hence it also may serve as a base to script a custom game entity from ground up.

Overlays currently have two downsides:
* it contains the sprite's copy, not reference (as with everything else); this is the biggest issue with overlays today imo, as this increases the memory requirement when having hungreds of them at the same time. (this problem may be solved in the future, with some changes to how overlay works)
* no pixel-perfect detection, but I think that's rather a limitaton of script that does not let test a picture at certain coordinates, or test two pictures for collision with just one command.

I still haven't fully understand the performance gain using overlays instead of drawing everything directly to a surface.

Any graphical object in AGS is processed by the graphics card when drawn, which means that when it does not change the sprite itself, but moves, scales * or changes graphic effect (transparency, tint) there's no additional processing on CPU, everything is handled by GPU, thus the game perfomance suffers least.
Also, these objects are z-sorted automatically, and rather fast too. With raw drawing you not only have to sort the drawn sprites yourself, but you have to redraw everything behind each moving sprite each time it changes position.

* - rotates too, and doing any other shape changes; but these are not supported in the current version yet.

In other words, if you have something that has a fixed sprite, or does not change too often, but often moves, scales (resizes), changes transparency, etc; requires distance sorting and may overlay other objects or background - then using a game object will be many times faster than raw drawing.

This does not exactly mean that you should use objects (or overlays in particular) everywhere. In case of doubt every option should be tested and compared for speed.
Raw drawing works fine when there's no image transformation and not alot of movement of elements around the surface. Also, in case of tiles, drawing 100 tiles on a larger surface may actually be faster than creating 100 overlays. (given how overlays work currently, that would also take less memory perhaps)

On the other hand, the difference in speed may be negligible in low-res games with small amount of objects. The higher sprite resolution is, and the more objects are there, the more difference is between using objects and raw drawing.

[abstauber]

Thanks (once again) for the detailed explanation. So everything that moves and scales, but does not animate would be a perfect candidate. Parallax effects should also work pretty well.

Regarding pixel perfect collision, there is(was) a nice module from ssh, which uses GetAtScreenXY methods a lot.
https://www.adventuregamestudio.co.uk/forums/index.php?topic=26307.20

(slightly updated version)
https://github.com/dkrey/ags_krokus/blob/3.5.1/ppcoll.ash
https://github.com/dkrey/ags_krokus/blob/3.5.1/ppcoll.asc

So if we could get Overlay.GetAtScreenXY, pixel perfect collisions would be very feasible.