Sprite sheets give me a headache

[Bill]

Did someone say sprite sheets?
I recycled a stack from a previous discussion in Games
Ignore the "Untested" part on the top right as it applies to linear animation.

Non-Linear_SpriteAnimation.zip

(93.51 KiB) Downloaded 89 times

The button "NonLinearFrame" sizes will generate the frame sizes by measuring the width of graphics in group "SpriteAnimation"
Then the stack script handles the animation, by way of the "Animate", "Reverse" buttons or the "NLAScroll" scrollbar.

Code: Select all

on NonLinearSpriteSizeAnimation iNum
   lock screen
   --// frame sizes are width of sprite
   put item iNum of field "NonLinearFrameSizes" into frameSize
   put "Current Frame Size:" && frameSize into field "FrameSize"
   
   --// add or subtract current size of frame to/from HScroll
   if iNum > lastFrame  then add frameSize to frameScroll
   if iNum < lastFrame then subtract lastWidth from frameScroll
   if iNum = 1 then 
      put 0 into frameScroll
      put frameSize into lastWidth
   end if
   
   --// adjust hSCroll for the difference in frame sizes
   if frameSize > lastWidth then subtract (framesize-lastWidth) from FrameScroll
   if frameSize < lastWidth then add (lastWidth-frameSize) to FrameScroll
   put "Current Frame Scroll" && frameScroll into field "frameScroll"
   
   --// store current frame and size to compare next frame/size
   put iNum into lastFrame
   put frameSize into lastWidth
   
   --// adjust scroll and width of group to animate
   set the hscroll of group "spriteAnimation" to frameScroll
   set the width of group "spriteAnimation" to frameSize
   unlock screen
end NonLinearSpriteSizeAnimation

Getting accurate sprite frame sizes is really tricky without a means to magnify things. Idealy additional controls could be added to adjust the width of the graphics without relying on selecting the graphics, whose 1 pixel wide control frame on each side can obscure just enough information to throw off your measuring of a sprite.

Be sure your animation group has 0 margin or it'll throw off the animation. I was fussing with graphics sizes for half hour bfore I realized the group margin property was giving me 4 pixels of grief.

Note the alernative method of measuring sprites sizes at the bottom of the stack, This could be expanded on with more little trangles and tracking their locations all at once like we did above with the rectangle graphics. With the key/pin method you can avoid grouping the original image and having to 'edit group' constantly to adjust your graphics top optain sprite sizes and then exiting the group edit to test the animation. Just have a keyframe editing panel and an animation panel with the same image, one full size, the other resized for animation.

Oh once you have the numbers in field "NonLinearFrameSizes" you can just adjust them individually to get better results. The values in the field are only derived the moment time the checkbox is set true.

43,48,62,77,76,89

seems to give best results with this zombie, but there's still a pixel or two overlap between frames. Frustrating.
Probably a layout that shows each frame idividually in a line side by side with all frames as if they were individual images would be easier to edit than making an adjustment in one size, and then watching the animation to see what happened as a result. That would require multiple copies of the group to manipulate.

Have fun!

[richmond62]

Have fun!

Not of that sort, if I can help it: and as you obviously already have . . .

Writing as a self-confessed lazy slob I would far rather just go for the option
I wrote about earlier: slice up a sprite sheet and then deal with the individual images.

I am aware that any stack made like that will be fatter because the individual images altogether
will be larger than a single sprite sheet, and that PNG images are large . . .

My example above rolled in at 102 KB, the following one that uses GIF images rolls in at 39 KB; but
Graphicconverter did make the edges of the PNG images "all shaggy" when it converted them to GIFs:
-

-
HOWEVER, I am not going to lose any sleep over a stack that weighs 102 KB:
especially as my BBC Model B, which has 32 KB RAM has not a hope in hell of even supporting a GUI . . .