Animate before removing a static collectable sprite

[dpagett]

Hi Everyone,

I want to animate a sprite as it is collected.  So I detect the collision, start the animation, do a little housekeeping and then remove the sprite however I don's see any frames of animation.

Here is the code i'm using in Sprite Type 2

If COLLISION 0               ;detect collision                                                                            
  ANIMATE                     ; animation should now start (12 frames)
  SUBTRACT 1 FROM B     ; controls number of sprites on the screen at once
  ADD 1 TO C                  ; increment players score
  LET LINE = 23               ; set cursor                                                               
  LET COLUMN = 13          ; set cursor
  DISPLAY C                    ; Display players score
  BEEP 40                       ; make a noise
  REMOVE                       ; remove the sprite
ENDIF

I'm guessing someone has encountered this before?  Any tips please?

Thanks

[andrewvanbeck]

I would suggest just using the frame number to signify that the animation has started, then check for when it's finished before removing it...

If frame 0
if collision 0
animate
endif
else
animate
if frame = 0
*** do the collection stuff
endif
endif

So when you hit the sprite, it animates for 1 frame, then keeps animating even if the player is no longer colliding with it, then when the animation loops around, like after an animate command, if the frame is then 0, then the animation has looped... so remove it then.

The problem is that you are only showing the first frame of animation before removing the sprite, you need to let it cycle the animation, so I like to check for frame 0 after an animate command before removing it. Using frame 0 is good for detecting a freshly spawned sprite, because it'll be 0 until it animates - as soon as you collect it you can animate it so it's no longer 0, but the event will know that the animation should be running for that sprite.

Hope this helps.

[andrewvanbeck]

Just a quick other thought though...

12 frames of animation is a bit generous I think - maybe it would be wise to keep the animations to a minimum while your working on your game, then add extra frames when all done, and you know how much memory you have left.

A frame will use 256 bytes, so those 12 frames use over 3k - when you only have about 28k total to play with, that's a big chunk. Each sprite needs to be pre-shifted 8 times, so sprites eat up tons of memory. You can however hack the shifted sprite images in an external tool, to give more frames of animation - like Manic Miners walk routine for example, that 'snaps' into 8 pixel blocks.

Objects use far less memory but require a considered approach. An object image will use only about 40 bytes, because it isn't pre-shifted. This means that it has to be placed in multiples of 8 positions, like 0, 8, 16, 24 etc - if you don't position an object at a multiple 8, then it simply won't show. It's worth considering using objects whenever possible, because consider that you get about 8 objects per single sprite frame - your collectable that uses 12 animation frames could be 96 objects instead. Maybe the sprite should be just an effect that uses less animation frames, then use objects for the actual collectable part - plus I think it'll cut down on the sprite usage too, because the effect sprite can be removed quickly, leaving just the object for the player to pick up. Objects are good when you want to have a lot of variety as well, like different foods, tools, or weapons - things that would be very restricted if done with sprites. Objects are not good for things that are collected regularly, like coins for example, because you only have 1 instance of each object, you can recycle them with a little code, but not on the same screen.

The reason why I'm so antsy about memory usage is that if your memory drops below 4 or 5k, you might have issues loading big events for editing. I'm in a position right now where I need to make a slight change to the player event, but it won't open due to low memory - so I will have to delete a load of sprite frames to free up the memory, make my change, then go add the sprite frames again. What I wouldn't give for a 128k version of AGD! - I wanted 20 screens, got 2500 bytes left... looks like it'll be 15 screens instead :/

[dpagett]

Thanks andrewvanbeck

I realised after I posted this that the number of frames I had devoted to the removal was excessive. I trimmed it down to a couple of frames to save memory and make things work better. I have experienced the same memory issues as you in the past which has prevented me from editing existing code blocks. I had a beautiful starry backdrop in a recent game which had to be scaled back to a couple of stars due to memory issues and corruptions.