Main Menu

Play Anim

Started by kevin, May 06, 2006, 10:30:16 PM

Previous topic - Next topic

kevin






Play Anim V0.00 - Frame Picker & Simple Animation creation

  Here's the first screen of a new tool. As you can see it's hacked together from the frame work of the shape editor.  Play Anim's purpose is to help you pick frames and create animation sequences.  That's about it.  Currently all you can do it load the animation image i and pick a frame.  but it's a start.

kevin

Have updated this some more (no worth a screenie).   It now has support for importing multiple sprites sheets.  The idea, is that you'll import the sprite sheet(s)  and snap out the individual frames.   These frames can be optimized to the minimum size (least number of pixels) of the object.   Then once you have grabbed your frames.  You'll build animation lists.

kevin

#2
Play Anim  V0.01


 Here's the current state of the animation editor. ATM, all you can do is load a sheet, grab the frames from it. To grab you select an area with the mouse and hit "A" to add the frame. To optimize a selection you hit "O".  

 Optimize finds the smallest bounding box of the current selection (the frame). The purpose of this should be obvious. Drawing Less pixels is faster, as drawing clear pixels costs. While on the subject, it's sometimes better to split images into two (or more) frames.  To reduce not only the surface area (number of pixels), but the amount of memory the image uses. One example that comes to mind could be a T shaped Tree image perhaps.

Anyway, here's a token piccy

thaaks

That's nice. After implementing "Optimize" which tries to find the minimum rect how about "Generalize" which would try to find the same sized rect with the images centered in the rects (like detecting that all images would fit into a 32x32 rect each)?
If you do animations it would make sense to have all images of the same size. So you don't have to deal with different x, y offsets for positioning.
But sometimes you have an image where the single frames are not all properly alligned or have huge gaps between them and you just want to have those 32x32 frames "in the best possible way" placed around the images.

And then it might also be necessary to shift a bounding rect left or right or up or down a bit to get the "best fit" for single images.

And now I should better keep my mouth shut before the unopened wish list gets closed by you  :P

kevin

#4
Play Anim V0.02

 Still tweaking the sprite sheet/frame picking tools.  Added a Grid mode which lets you position a grid over the sheet, which can then be cut out as frames.  Once their frames you can delete any extras you may not need, or optimize frame for the least amount of pixels.  

 
Anyway a couple more shots.

BlinkOk

looks cool. it would be cool if when you optimized it you put the x/y adjustment in the fitst two pixels of the image

kevin

Play Anim V0.04

 Here's the current state of PlayAnim tool.  As you see, this edition now supports associated collision shapes (those exported from PlayShape).  So if you load a sprite sheet  that has a shape file, the shape will be automatically imported.

Then when your selecting frames from the sheet, any verts that fall inside your frames selection area, will be cut into a new shape for this frame.  Thus simplifying the process enormously.  Too easy :)

kevin

Hmm, it's all a question of structure

   Been working on the export/import today, just trying to get it to a useful point. So it can be used to make frame definition sets at least.  But there's a few design concepts that need some kicking around again.

  With animation, there are really two concepts (at least) they need to be bound together here.  The first is the 'frames' and the second is Animation lists themselves.  I.e. Anims = sequences of frames.  

   So what I'm aiming at here is something like this.  A) You import your sprite sheet(s) B) pick out the frames (with associated shape data) C) then export that a frame definition file.   From here, you'll be able to load these files into PB with the Frame library.   These frames will imported/loaded and left in the passed array.  

  loading will look a bit like this.  

  LoadFrames Filename$,Frames()

  From here you use the imported data in your animation system..  So it's a kind of half way house.

  Ok, so that's all blatantly obvious.   But there's a few issues that need to ironed out.  One of which is where image handles are handled.

  Since the frames can be grabbed aligned, optimized or freehand.  This will mean that you'll not only need the frame, but it's X/Y handles also.  So rather than simply setting the sprite image, your animation engine would set the image + handles. Ensuring the alignment stays constant.   The drama is, I was going to store handles in the animations, not the frame definitions.  I guess, i'll have to store them in both.  

 The bigger drama is first storing the animation data, and then making an interface that's easy for the user to control.    

 Ideas.. ?

thaaks

One question is: How much does the user need to know?

PlayAnim allows me to
a) load images of any kind. Then I can
B) automatically or manually define rects which work as the image sizes I want to have in my animations.
I can additionally
c) use the rects or create shapes (or circles?) for collision detection.
Finally I can
d) define sequences of images that I call an animation (WALK, RUN, JUMP, CROUCH, IDLE, DIE).
If I can
e) define the X and Y offsets of each imagerect for the given animations I would need nothing else but the defined names of the sequences like "WALK", "RUN", "JUMP", "CROUCH", "IDLE" or "DIE" to get going.
Maybe I'd want to be able to
f) set a few flags (like drawing mode, alpha blending, rotation or scale).

Everything else is hidden in the animation package and the animation definition file and your tool "Play Anim".

A simple function like AnimHandle = LoadAnimations Filename$, Codes() would be fine.
I could then do stuff like StartAnim AnimHandle, "WALK". Using strings for the defined names of sequences might be the easiest solution.

Other functions like PauseAnim AnimHandle, "WALK" or ResumeAnim and StopAnim would complete the set.

So my approach would be to hide as much as possible.

Just a spontaneous idea, maybe it helps a bit or gives you an idea.

Cheers,
Tommy

kevin

Well, that's pretty much what I had in mind.  What's missing however is how the data is associated.   So is the animation tied to the sprite.   What drives (steps) the animation and who holds the counter data.  What if the user wants synchronized / none synchronized animations ?.

thaaks

QuoteWell, that's pretty much what I had in mind.  What's missing however is how the data is associated.   So is the animation tied to the sprite.
I would say put it all in one file. Have some type/structure to define an animation. An animation knows about the frames and the collision things and the sprite flags the user wants. As soon as an animation is requested/started the animation creates the necessary sprites.
The user does not need to know about sprites and does not need to deal with them. He deals with animation instances and creates or kills them.
QuoteWhat drives (steps) the animation and who holds the counter data.  What if the user wants synchronized / none synchronized animations ?.
The counter data is stored inside the animation.
In the main loop the user calls UpdateAllAnimations() which is a given function of the framework and which updates all animations that are active.
The user should be able to specify transition times or frames for all frames of an animation (same value for all transitions or separate ones for transition 1->2, 2->3, and so on).
This would enable synchronized animation based on time or frames.
Additionally you would need a function to set a specific animation frame SetAnimFrame animhandle, 2
or ask for the frame range
first, last = GetAnimFrames animhandle.
This is for unsynchronized animation based on function calls to SetAnimFrame.
As soon as the user calls SetAnimFrame the automatic frame transitions would be switched off (but maybe could be switched on again by another function).
Finally you need a way to place the animation somewhere on screen like SetAnimXYZ animhandle, x, y, z.

Just a quick shot to trigger your brain  :P

Ian Price

Who are you actually designing this for Kevin?

If it's a beginner they'll want it as simple and straight-forward as possible, without the need to wade through loads of code or instructions on how to use it. Make it too simple and advanced users may be turned off as it might not allow the flexibility that they require.

It's difficult to please everybody.

I personally like to load the graphics into memory using my own functions, then assign arrays to hold the animation frames and use a controller for the animation speed within the sprite's functions. Predefining the animation(s) and speed(s) may mean having to keep leavig the editor to run the animation tool to adjust values, until you are happy.

Hmmmmmmmmmmmm................

It's a toughy.
I came. I saw. I played some Nintendo.

thaaks

Yes, Ian, you got a point there.
I agree with you that experienced people do it on their own with the possibilities PlayBasic already offers.
So animation would be for newbies accessing it in a simple way (no details).
Experienced users would use the additional functionality where you can finetune almost everything.

It just needs a good design  :D

kevin

I'm not focusing upon any particular group, other than convenience.  Nor am I looking to roll a complete abstraction layer around sprites here.  

  Currently loading a set(s) of frame def's from a users perspective is as difficult as this.  

  #include "frames"

  LoadFrames Filename$, FrameArray()

  This will grab frames from whatever sheets you've assigned (not just from 1 sheet) including any associated shape data for each individual frame.  So frames can be stored on the same sheet, different sheets, or in abstract locations.  It doesn't matter.  The end result is a list frames that are ready for use.

  Frame definitions are not animations however.  So the idea here, is you'll be able to Export both, but use either if you want.      

  I still haven't decided on just how the animation controls will look.  It'd be easier on the user if the animation handled updating internally.  But that's not very useful if you want individual animations per character (as then they all run in sync!). So you'd  have to spawn a new copy of the animation for use.  I'm really not keen on that approach either.  As the punter will no doubt forget to close the animation.  

 Other issues like key frame and link animations come to mind.  While i'm not a fan of regular frame ticker approach to animation, but that's prolly what it'll be.. :(