getSpriteAnimFrame() returns a zero-based index rather than the frame

pobtastic

This is okay I guess, it was just surprising!

Consider the following code;

sprite_sheet = loadImage( "Ansimuz/GothicCemeterySkeleton", false )
sprite = createSprite()
setSpriteImage( sprite, sprite_sheet )
setSpriteAnimation( sprite, 16, 21, 5 )
setSpriteLocation( sprite, gWidth() / 2, gHeight() / 2 )
setSpriteScale( sprite, { 4, 4 } )

loop
  clear()
  frame = getSpriteAnimFrame( sprite )
  printAt( 0, 0, int( frame ) )
  updateSprites()
  drawSprites()
  update()
repeat

The animation plays frames 16 to 21, but getSpriteAnimFrame() returns a range of 0-5. Obviously this is easily worked around it's just that the docs don't make this clear - it sounds like you'll get the current frame rather than the current index?

Willpowered

@pobtastic The use of a range from 0 to the sprite animation length is intended for getSpriteAnimFrame(), to help make it easier to use sprite animation without arbitrary values for the frames. The start frame is always 0, and the end frame is always getSpriteAnimFrameCount() - 1. You can also pass getSpriteAnimFrameCount() when using setSpriteAnimFrame to go to the last frame of the animation.

I'll make a note that it might be useful to have a method to retrieve the actual tile values of the start, end, and current frame. Until then, it can be worked around like this, with the sprite holding all the info:

sprite_sheet = loadImage( "Ansimuz/GothicCemeterySkeleton", false )
sprite = createSprite()
sprite.start_tile = 16
sprite.end_tile = 21
setSpriteImage( sprite, sprite_sheet )
setSpriteAnimation( sprite, sprite.start_tile, sprite.end_tile, 5 )
setSpriteLocation( sprite, gWidth() / 2, gHeight() / 2 )
setSpriteScale( sprite, { 4, 4 } )

loop
  clear()
  frame = sprite.start_tile + getSpriteAnimFrame( sprite )
  printAt( 0, 0, int( frame ) )
  updateSprites()
  drawSprites()
  update()
repeat

pobtastic

Hiya!

Yeah, I worked around it easily enough once I realised - I reckon it might be good to clarify it in the doc pages? It was just maybe a little unexpected given the name of the function?

Willpowered

I agree, I'll make a note right now for the documentation team. Thanks!