Implementation of scriptable sprite overlays.

[MaxMahem]

Okay while I could keep fiddling with this forever, I think it's ready for review.

Notes on my approach:

• This introduces two new classes, InventoryItemSprite and SpriteOverlay.
• InventoryItemSprite is similar to ItemSprite and UnitSprite. It takes on all responsibility for drawing InventoryItems/bigobs. It is non-owning and should not leave the local scope. This was necessary to cleanly provide a centralized way to enable or disable the rendering of various (now) optional behaviors. It also eliminates a small amount of code duplication. This also represents the biggest structural changes to the code since the logic that powered these effects is removed and moved into this class.
• InventoryItemSprite depends on a small struct, InventorySpriteContext to inform the scripting engine of the current context in which the inventory sprite is being rendered and allows for the scripts to instruct the class to render or not-render the various options.
• InventorySpriteContext also contains a set of static values representing the current OXCE behavior (Wound overlays are only drawn on units on the ground. Ammo counts do not show up in the inventory screen). I believe there is a good argument for changing some of these defaults, but I have left it as is for now. I considered exposing it to the rule files but decided it was too much work/too intrusive, and the behavior can be adjusted by scripting anyways.
• InventoryItemSprite itself has no exposure to scripting, which is all handled by SpriteOverlay and InventorySpriteContext
• Most scripting behavior is handled by free functions that have been friended, and tucked away in their own namespace. This lets them access private data where necessary but does not blot up the API with calls that are not relevant outside the scripting language.
• SpriteOverlay is the primary interface for the scripting engine and holds most of the state information needed to perform the scripting (primarily the sprite bounds and the target surface).
• Calling the scripting is straightforward, instance a new SpriteOverlay in the local scope (it should not leave the local scope and is non-owning of any resource) and then call the draw method on it. draw is a template function and providing the appropriate templates lets the appropriate scripts be called with the appropriate arguments.
• There are 4 new scripting hooks added by this patch at this time:
• • inventorySpriteOverlay which is called in the context of rendering an inventory sprite (anywhere it might be rendered, except the UFOpedia at this time). It exposes BattleItem data.
• • handOverlay which is called in the context of rendering a hand-slot, which is commonly bigger than the sprite. Handslot sized render boxes are also used for the hover ammo box and items selected by the cursor, so it is also called in these contexts, though it has no effect by default. It exposes BattleItem data.
• • unitPaperdollOverlay which is called when the paperdoll is rendered. It exposes Unit data.
• • unitRankOverlay which is called when the unit rank is displayed on the battlescape.

I think that about covers it. I had other things in the past, but on further consideration, I backed off from them so this is pretty much only exactly what it says on the tin. There are a few additional scripting methods thrown in that I found necessary to generate the demo effects, which probably means they are generally useful regardless.

Anyways, I had fun making this, and am personally finding a lot of these enhancements useful.

[MaxMahem]

After some discussions with SupSuper I may have come up with an even better way of doing this, so I've converted this to a draft as I explore that.

[MeridianOXC]

update of src/OpenXcom.2010.vcxproj.filters is missing for display in Visual Studio

update of src/CMakeLists.txt is missing for compilation on Linux, Mac and Android

[MaxMahem]

Sorry for the spam, didn't mean to close this. Had to update the filter file manual, could not for the life of me get visual studio to do it.

[Yankes]

In week or two I will go back to this PR and analyze it in detail and possibly alter it a bit and merge manually.