Possible sprite bugs

[Method_Mobile]

Fam,

I believe I have located a couple bugs in the sprite library.

Issue_1: Sprites scaled via object.width revert to their original scale when calling object:play().

Issue_2: Object.frame returns incorrect value after calling object:setFrame(). However, visually the frame has been updated correctly. This can be circumvented by calling object:setSequence() each time before setting a frame via object:setFrame()

Attached is a testCase.

twstCase.zip (25.2 KB)

Thanks

[Siu]

Hey!

I took a look at your test case, thanks for providing one!

What I’m seeing is the following:

For Issue_1, the width and height property values are set during sprite object creation but do not determine its actual size; these values come from sheetData, and the values on this data is what determine its size (the width and height properties are probably just reflecting these values, same scenario as a polygon object). Thus, calling newS:play() will redraw the object according to sheetData. Optionally, sheetContent[Width,Height] is provided in the sheetData for us to resize (scale) the sprite accodrindly.

Whether width and height properties should work the same as a rectangle object is something that I would leave at the dev’s hands, otherwise, using scale property or function call would be the proper way to “resize” the sprite without recreating the sprite object with a different set of sheetData values.

For Issue_2, you’re setting the frame and in the same code block you’re calling newS:play() which will essentially continue to play the rest of the frames and end on the last frame of the sequence (in this case frame 8). Also, doing it in the following order (just in case) will no work:

newS:play()
newS:setFrame(2)

In the code above, play is called and immediately setFrame(2) before the play sequence has ended, and thus the sprite object will end its animation displaying the last frame of the sequence. To set the sprite at a specific frame after playing a sequence you will probably want to use a sprite listener and set the frame when the “ended” phase of the sprite event has triggered:

-- add the event listener to the sprite object
local function spriteListener( event )
   if event.phase == "ended" then
      newS:setFrame(2)
   end
end

-- Add sprite listener
newS:addEventListener( "sprite", spriteListener )

More on sprite events here.

[Method_Mobile]

Siu,

Thanks so much for taking the time give such an in depth response. You’ve cleared up issue_1 for me. Personally, I would expect width and height to behave similar to xScale and yScale when dealing with sprites. No biggie though, I’ve just written my algorithm to handle scaling sprite objects different than rects.

However, I am still having trouble with Issue_2. I’ve updated the test case to better explain the inconsistency that I am experiencing. While it remains in the same code block, I wrapped it in an if else statement so only one condition will execute at a time, giving plenty of time for the sprite sequence to complete. Notice setting the sprites frame works visually, but object.frame returns the incorrect frame number. While this inconsistency is easy for me to work around by calling setSequence prior to setFrame. I felt it should be brought up. I’ve tested this scenario on multiple Solar2D builds. I even tried it on a old Corona build from 2020, and behavior is the same. So this has been prevalent for a long time. Honestly, I can’t believe I have never noticed it in the 10 years that I have been using Corona.

updatedTestCase.zip (25.1 KB)

Thanks again,
MMS

[Siu]

Ah yes, I see what you mean. This definitely looks like a bug.

I checked current issues in GitHub, there’s one in relation to setFrame but it seems to address a different problem.

If you can, GitHub probably is the best place to report the bug and provide your findings.

[Method_Mobile]

Siu,

Thanks for confirming. I really appreciate your time and help. I’ll see about reporting it tonight when I get home.

Thanks again,
MMS