Skip to content

Comments

Linked sprite support, custom MovingSprite light sprites#2753

Open
provigz wants to merge 32 commits intoSuperTux:masterfrom
provigz:custom-linked-sprites
Open

Linked sprite support, custom MovingSprite light sprites#2753
provigz wants to merge 32 commits intoSuperTux:masterfrom
provigz:custom-linked-sprites

Conversation

@provigz
Copy link
Member

@provigz provigz commented Jan 30, 2024

Custom light sprites can now be added to all objects, which inherit MovingSprite. Setting a custom color for the light sprite is also possible, as long as the object is not designed to use foreign color values (for example, from an option).

To add a light sprite with an RGB color of 0.5, 0.2, 0.25, in a .sprite file:

(linked-sprites
  (light "path/to/light/sprite" 0.5 0.2 0.25)
)

Keep in mind that specifying color values is optional. The entry can also end after specifying the file.

Additionally:

  • Objects which utilize more than 1 sprite are now able to get the files of their additional sprites from the main one's linked-sprites list (the same block where light sprites can also be added, as shown above). This allows for expanded sprite customization for objects.

To add linked sprites, in a .sprite file:

(linked-sprites
  (key "path/to/sprite")
  (key2 "another/sprite/file")
)

Linked sprites can be added under sprite actions, too. If a sprite with the same key is found in the general linked sprites block and the action-specific one, the sprite specified by the action will be prioritized, thus overriding the default linked sprite file.

Sprites, which the specific object does not support, will be ignored.

  • Sprite actions now support the flip-offset property, which determines how much the sprite should be vertically offset when flipped vertically.

Objects which utilize more than 1 sprite now get the files of their additional sprites from the main one's "linked-sprites" list.

This allows for expanded sprite customization for objects.
Custom lightsprites can now be added to all objects, which inherit `MovingSprite`.

Setting a custom color for the lightsprite is also possible, as long as the object is not designed to use foreign color values (for example, from an option).
@mrkubax10 mrkubax10 added type:feature category:code status:needs-review Work needs to be reviewed by other people labels Jan 30, 2024
@Rusty-Box
Copy link
Member

Do the light sprites work per action or is it one for all?

@provigz
Copy link
Member Author

provigz commented Jan 30, 2024

Do the light sprites work per action or is it one for all?

One for all, currently. I think per-action could be done, though.

@Rusty-Box
Copy link
Member

One for all, currently. I think per-action could be done, though.

That would be nice to have for sure

@provigz
Copy link
Member Author

provigz commented Jan 30, 2024

One for all, currently. I think per-action could be done, though.

I'm thinking it could be done by having the same block available in action, and if a sprite with the same key as in the global block is available, then prioritize the one of the action.

Linked sprites can now be added to sprite actions too. If a sprite with the same key is found in the general linked sprites block and the action-specific one, the sprite specified by the action will be prioritized, thus overriding the default linked sprite file.
@MatusGuy
Copy link
Contributor

What was this trying to fix?

@provigz
Copy link
Member Author

provigz commented Mar 13, 2024

What was this trying to fix?

Hardcoded sprites.

@Rusty-Box
Copy link
Member

@Vankata453 My brain explodes by trying to form this words so I'll do it like this. Can I:

  • Make a light .sprite file with 2+ actions
  • Link that .sprite file to the object's .sprite file
  • Assign individual actions of light sprite to each action of the object .sprite if needed

The way I originally was hoping we could achieve that was through a special tag within an action.
Here is an example Dive Mine.sprite file using the theoretical ([key name]-action "[action name]") tag:

 (action
  (name "left")
  (fps 12.0)
  (hitbox 14 19 32 32)
  (ticking-glow-action "idle")
  (images "left-0.png"
          "left-1.png"
          "left-2.png"
          "left-3.png"
		  "left-4.png"
		  "left-5.png"
		  "left-6.png"
		  "left-7.png"
		  "left-8.png"
		  "left-9.png"
		  "left-10.png"
		  "left-11.png"))

 (action
  (name "right")
  (fps 12.0)
  (hitbox 14 19 32 32)
  (ticking-glow-action "idle")
  (mirror-action "left"))
 
 (action
  (name "iced-left")
  (hitbox 5 8 32 32)
  (ticking-glow-action "idle")
  (images "left-0.png"))
 
 (action
  (name "iced-right")
  (hitbox 5 8 32 32)
  (ticking-glow-action "idle")
  (mirror-action "iced-left"))

 (action
  (name "ticking-left")
  (fps 15.0)
  (hitbox 14 19 32 32)
  (ticking-glow-action "ticking")
  (images "ticking-0.png"
          "ticking-1.png"
          "ticking-2.png"
          "ticking-3.png"
          "ticking-4.png"
		  "ticking-5.png"
		  "ticking-6.png"
		  "ticking-7.png"
		  "ticking-8.png"
		  "ticking-9.png"))

 
 (action
  (name "ticking-right")
  (fps 15.0)
  (hitbox 14 19 32 32)
  (ticking-glow-action "ticking")
  (mirror-action "ticking-left"))

  (linked-sprites
    (ticking-glow "images/creatures/dive_mine/ticking_glow/ticking_glow.sprite")
  )
)

The way the tag would work is that it will check for action names within the linked sprite file (in this case dive_mine/ticking_glow/ticking_glow.sprite), i.e. "idle" and "ticking".

@provigz
Copy link
Member Author

provigz commented Mar 13, 2024

@Rusty-Box Action-specific linked-sprites are already supported, so what I believe only needs to be done to support this is to be able to link sprites with custom default actions.

I modified your example, so by default it globally (for all actions) links the ticking-glow sprite with the action idle (since most actions seem to use it). Since only the last two actions use the ticking action from the sprite, it's declared again in a new linked-sprites block inside of them, with the same name (thus it will override the global ticking-glow linked sprite, which has the idle action).

At the end, the modified example looks like this:

 (action
  (name "left")
  (fps 12.0)
  (hitbox 14 19 32 32)
  (images "left-0.png"
          "left-1.png"
          "left-2.png"
          "left-3.png"
		  "left-4.png"
		  "left-5.png"
		  "left-6.png"
		  "left-7.png"
		  "left-8.png"
		  "left-9.png"
		  "left-10.png"
		  "left-11.png"))

 (action
  (name "right")
  (fps 12.0)
  (hitbox 14 19 32 32)
  (mirror-action "left"))
 
 (action
  (name "iced-left")
  (hitbox 5 8 32 32)
  (images "left-0.png"))
 
 (action
  (name "iced-right")
  (hitbox 5 8 32 32)
  (mirror-action "iced-left"))

 (action
  (name "ticking-left")
  (fps 15.0)
  (hitbox 14 19 32 32)
  (linked-sprites
    (ticking-glow "images/creatures/dive_mine/ticking_glow/ticking_glow.sprite" "ticking")
  )
  (images "ticking-0.png"
          "ticking-1.png"
          "ticking-2.png"
          "ticking-3.png"
          "ticking-4.png"
		  "ticking-5.png"
		  "ticking-6.png"
		  "ticking-7.png"
		  "ticking-8.png"
		  "ticking-9.png"))

 
 (action
  (name "ticking-right")
  (fps 15.0)
  (hitbox 14 19 32 32)
  (linked-sprites
    (ticking-glow "images/creatures/dive_mine/ticking_glow/ticking_glow.sprite" "ticking")
  )
  (mirror-action "ticking-left"))

 (linked-sprites
   (ticking-glow "images/creatures/dive_mine/ticking_glow/ticking_glow.sprite" "idle")
 )

@Rusty-Box
Copy link
Member

@Rusty-Box Action-specific linked-sprites are already supported, so what I believe only needs to be done to support this is to be able to link sprites with custom default actions.

Wait but Dive Mine's glow never changes. Rather is disappears when it should begins playing the ticking action, as of now. Is there just no way to define that right now? I'm so confused

@provigz
Copy link
Member Author

provigz commented Mar 13, 2024

Wait but Dive Mine's glow never changes. Rather is disappears when it should begins playing the ticking action, as of now. Is there just no way to define that right now? I'm so confused

As I mentioned in the beginning, it still has to be done, I just offered a way it could work.

@Rusty-Box
Copy link
Member

Okay. Good to know. I thought I was going crazy here 😅
In that case I guess my only note would be that I feel like my proposal looks a bit better in terms of readbilty and having to type less but I ain't a coder so I don't wanna pretend I know better. Atleast I know now that I wasn't crazy, so that's nice :]

@provigz
Copy link
Member Author

provigz commented Mar 13, 2024

May be better in terms of readability, but would be more of a pain to implement. :D

(Oh, and this approach is also way more flexible, since you can also change the whole sprite, not just the action.)

@Rusty-Box
Copy link
Member

Is it just me or is it not working? I updated Dive Mine's sprite file to look like you showed in this example here but it doesn't seem to work. The light keeps disapearing when you approach Dive Mine instead of changing the action of the linked sprite. Am I doing something wrong here?

@Rusty-Box
Copy link
Member

Also the candle light doesn't seem to be rendered as a lightmap since you get a black box when you place it

Copy link
Member

@weluvgoatz weluvgoatz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works perfectly now!

Copy link
Contributor

@MatusGuy MatusGuy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still not sure about the efficiency on this. I think we should build some sort of system to store light textures as surfaces instead of sprite files. Most of these "light sprite files" have only one light with one action anyway. But we can leave this suggestion for another PR, because this one is already heavily demanded, even by me.

Almost there!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow really? What did you change here?

{
SoundManager::current()->preload("sounds/switch.ogg");
m_lightsprite = Surface::from_file("/images/objects/lightmap_light/bonusblock_light.png");
m_lightsprite = m_sprite->create_linked_sprite("on-light");
Copy link
Contributor

@MatusGuy MatusGuy Dec 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This m_lightsprite name still hasn't been changed. In my opinion, if you are required to load & allocate another sprite, just to control when to draw it, then this system is heavily flawed. At least I think that's what's going on... The PowerUp class seems to handle this fine.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What this is doing is only creating the "on-light" sprite when it's needed, which is only if the bonus block contains light.

@provigz provigz added this to the 0.7.0 milestone Jan 25, 2025
@Hypernoot Hypernoot marked this pull request as draft May 26, 2025 16:23
@Hypernoot
Copy link
Member

What are the remaining tasks?

Copy link
Member

@Hypernoot Hypernoot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested all flammable badguys, light sources, glowing powerups and weak block.
all work

@provigz provigz marked this pull request as ready for review September 30, 2025 19:14
@tobbi
Copy link
Member

tobbi commented Nov 17, 2025

Can you mark all get_linked_sprites methods as const?

@Hypernoot
Copy link
Member

Unfortunately, this cannot work, as a const function cannot return non-const references. Even if you change the definition of LinkedSprites to std::unordered_map<std::string, const SpritePtr&>, it won't work because the function MovingSprite::on_sprite_update() cannot work with const SpritePtr&.

@Hypernoot Hypernoot mentioned this pull request Nov 29, 2025
@Hypernoot Hypernoot closed this in 805d08b Nov 29, 2025
swagtoy added a commit that referenced this pull request Dec 13, 2025
There are numerous crashes and bugs that have been occuring due to this
commit. I think it just needs a little more time to bake in the oven. I'm sure
we could get the feature in the door by the time 0.7 releases, but it's simply
too risky to push out right before release since it involve too many critical
backend changes. For now, we revert :(

It's planned to put this back in after 0.7 releases though.

This reverts commit 805d08b.
@provigz
Copy link
Member Author

provigz commented Dec 13, 2025

Since #3418 was reverted, I'm reopening this PR. It only has to have master merged in to fix conflicts.

@Hypernoot
Copy link
Member

Bugs known so far:

@tobbi
Copy link
Member

tobbi commented Dec 13, 2025

@provigz You didn't reopen. I'm going to.

@tobbi tobbi reopened this Dec 13, 2025
Copy link
Member

@Hypernoot Hypernoot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix the bugz hyper O___O

swagtoy added a commit that referenced this pull request Dec 14, 2025
There are numerous crashes and bugs that have been occuring due to this
commit. I think it just needs a little more time to bake in the oven. I'm sure
we could get the feature in the door by the time 0.7 releases, but it's simply
too risky to push out right before release since it involve too many critical
backend changes. For now, we revert :(

It's planned to put this back in after 0.7 releases though.

This reverts commit 805d08b.
swagtoy added a commit that referenced this pull request Dec 14, 2025
There are numerous crashes and bugs that have been occuring due to this
commit. I think it just needs a little more time to bake in the oven. I'm sure
we could get the feature in the door by the time 0.7 releases, but it's simply
too risky to push out right before release since it involve too many critical
backend changes. For now, we revert :(

It's planned to put this back in after 0.7 releases though.

This reverts commit 805d08b.
@provigz provigz modified the milestones: 0.7.0, 0.7.1 Dec 14, 2025
swagtoy added a commit that referenced this pull request Dec 16, 2025
There are numerous crashes and bugs that have been occuring due to this
commit. I think it just needs a little more time to bake in the oven. I'm sure
we could get the feature in the door by the time 0.7 releases, but it's simply
too risky to push out right before release since it involve too many critical
backend changes. For now, we revert :(

It's planned to put this back in after 0.7 releases though.

This reverts commit 805d08b.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants