Author Topic: [Suggestion] Ability to BLIT objects by script.  (Read 3021 times)

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8671
    • View Profile
Re: [Suggestion] Ability to BLIT objects by script.
« Reply #15 on: April 01, 2023, 11:22:47 pm »
Looks nice.

Online Yankes

  • Commander
  • *****
  • Posts: 3220
    • View Profile
Re: [Suggestion] Ability to BLIT objects by script.
« Reply #16 on: April 02, 2023, 01:21:11 am »
Some of this would be possible using old scripts hooks (examples were bit too plain), probably true difference will be creating custom paper dolls for corpses that is composition of multiple parts, in old version it would be extrime painful to do some thing like that for 256 possible combinations.
Another thing would be move whole graphic by 1 pixel :D

@MaxMahem one thing to consider if you blit new surface, I think it could be beneficial if it have option of item recolor too (reuse current item scripts hooks)
As if you would allow some items graphic into multiple parts, it would be beneficial if each one were recolored in same way.

Offline MaxMahem

  • Captain
  • ***
  • Posts: 60
    • View Profile
Re: [Suggestion] Ability to BLIT objects by script.
« Reply #17 on: April 02, 2023, 02:31:16 am »
@MaxMahem one thing to consider if you blit new surface, I think it could be beneficial if it have option of item recolor too (reuse current item scripts hooks)
As if you would allow some items graphic into multiple parts, it would be beneficial if each one were recolored in same way.

This is a great idea, though given the current setup, I'm not entirely sure how I would implement it. Since for efficiency reasons the code now blits directly onto the target surface rather than a temporary surface. I had looked if there was a way to create a new "dummy" surface that shares (a sub-portion of) the target surface buffer to more easily/efficiently manage scripted operations, but I didn't find an easy method in my brief look.

It also occurs to me that it might be useful to call the recolor (and perhaps the blit?) scripts in the context of the ufopedia, which is not currently done. For example, lots of weapons have ammo that is essentially just a minor recolor of the original, so a recolor script could be used to allow for only having to provide one sprite.

Offline MaxMahem

  • Captain
  • ***
  • Posts: 60
    • View Profile
Re: [Suggestion] Ability to BLIT objects by script.
« Reply #18 on: April 12, 2023, 02:37:30 pm »
So I got distracted for a bit, but I'm on the homestrech now. I've developed things into a state where it is very easy to add custom drawing to any sprite is very simple (it's basically one/two lines. One to instance the `SpriteOverlay` class and one to call the `draw` method. Adding more scripting hooks is straightforward, but quite a few more lines in `ModScript`. But that's what it's there for no? The long and short of it is it now possible to add "Overlay" drawing scripts to arbitrary parts of the code with minimal disruption.

This leads me to my question to get some feedback on. Where would more hooks be desirable? Currently, I have implemented 4 hooks, as proof of concept.
  • handSpriteOverlay - called in the context of "hand-sized" slots, that are used in a few places, most obviously the hand slots on the inventory and battlescape, but a few other places as well. The scripts expose an object, `spriteInventoryContext` that can be used to distinguish the context and optionally turn off the rendering of default effects.
    Some examples of using that feature:

    Default health display is disabled and color coded on is added. Of trivial use for this but also...

    Overriding the default display also lets items that only have one type of charge, display only that charge.


    Overriding the default ammo display to color code the ammo by its damage type. Also the ammo count is shown in the inventory screen for both weapons and ammo clips.
  • inventorySpriteOverlay - called (almost) everywhere a bigobj inventory sprite is called, minus the ufopedia for now. The same `spriteInventoryContext` object exists to determine which context and to disable default effects (like the grenade primed indicator).
  • unitPaperdollOverlay - called in the context of the drawing of the paperdoll. This one is new.
    And I'm no artist, but there is a lot of capability here. Just a demo example:

    I'm on fire!

    30 wounds jeeze...

    This one is not animated, as I didn't put the hook in a location that gets called every frame. It could be though.
  • unitRankOverlay - drawn in the context of the unit rank. I did this one on a lark for a fun effect SupSuper suggested...


    This one *is* animated as the hook is put in a location that gets drawn every frame.
I did originally intend to add the capability to the rendering of battlescape sprites, and that's still on the table. However, as the code around here is somewhat more complex, I plan on punting on this till a later patch (hopefully, it should still be straightforward, but you know "it should be easy" is famous last words.)

Anyways, what I'd like to collect some feedback on is, two things:
  • What are opinions on multiple hooks, vs reusing the same hook. The first two hooks illustrate the potential problem. Scripts likely want to act differently depending upon the context in which they are drawn. For example, overlays in OXCE are drawn differently depending on the items location. Fatal wounds indicator on a corpse is only drawn when it is on the ground, and not when the item is in the hand or backpack (this is a default that could easily be changed at this point, but I didn't get real clear feedback on this point.)

    What I have done in this case is expose the aforementioned Context object that contains information on the context of where the script is being called, and provides a way to activate and deactivate default effects. This can be done for other scripts (and in fact is done). But having to examine these sorts of objects to decide if you want your scripting logic to execute at runtime is fairly cumbersome and should be avoided. But, OTOH, having a whole tone of script hooks probably isn't desirable either. So there is a balance to be found.

    The line I've tried to draw is "am I likely to ever want to run this set of logic in any other context?" For example, when drawing an overlay on an inventory sprite there are at least some cases where you want to draw the overlay in multiple and/or all the contexts an item is in. The grenade and high-explosive scripts are examples of them. OTOH, the "color ammo counter" overlay I did is useful in limited contexts (when the weapon is in hand). Thus I split the script into to hooks for these two cases.

    But I'm interested in other general feelings on the subject from others. It's not always clear to me when I should implement different hooks, vs when I should just provide a scripting context.
  • On the discord I got some somewhat confusing feedback about the desriability to render an overlay on each individual layer of a layered paperdoll. This is as easy to do as any other overlay at this point, but I didn't do it this way because I didn't see much point to such a capability. But I can add it if it is desirable. (The performance cost will not be great as the layers are only rendered once per inventory screen load).
  • What ptr's are desirable in these given context? To an extent this is kind of a pointless question as given the `BattleItem` or `Unit` ptr, most other desired ptrs can be obtained. But putting them in the script defaults makes things easier I think. Right now I've defaulted to the `BattleItem` and the `RuleItem` being present. But I'm open to other suggestions.
  • Beyond Battlescape unit/item sprites (which I am punting on for now). Is there any other battlescape sprites that would be desirable to get wired up in this initial patch? At this point, the process of doing it is easy and non-intrusive.

Offline MaxMahem

  • Captain
  • ***
  • Posts: 60
    • View Profile
Re: [Suggestion] Ability to BLIT objects by script.
« Reply #19 on: April 12, 2023, 03:53:51 pm »
Just one more thing I had to add...