ZFGC
Projects => Discussion => Topic started by: Zaeranos on September 04, 2010, 11:23:36 am
-
[spoiler=Small rant and reason for creating the topic but has nothing whatsoever to do with the topic.]
Something has been bothering me for a while. Most of the developers that are actively developing something here keep their source code to themselves, hushed up as if they are a commercial company. The only actual open source project active in this community is the Minish Cap Style engine of the Community Project. Sometimes someone posts a topic showing an engine he is creating in which the source is available. But unfortunately these topics are often short lived. Most of the time if any coding is shown, it shows only a small but it does not reveal any of the design and idea behind it. Thus leaving other people whose help is asked guessing whether the fault is in the code or the design. Especially when only 2 lines of code are shown.
Personally, I find this situation for a development community a little suffocating and not helpfull at all. No one learns anything this way. At least not in this community. Also keeping new members who want to learn to develop games away. That is why I decided to try to do something about it by starting discussion topics about how to do specific things. Topics where members can share their ideas, discuss other designs and to learn from each other. I start with this topic about animations using sprites.
[/spoiler]
A few weeks ago I had a discussion with Freki about using a constant image speed in GM would never lead to good animations (http://www.zfgc.com/forum/index.php?topic=36778.0). I disagree, because with some creativity in sprites you can still create a good animation even with a constant image speed. What I found unfortunate however, was that no alternative solution or implementation was provided. Therefore am I making this discussion about creating animations with sprites.
I am wondering how you guys would design(/program) drawing and animating of sprites. And it does not matter what language you would use. It is not exclusive to GM or C++. Although it would be nice if you could provide some pseudo-code with your explanations.
discuss, discuss, discuss.
-
Personally I have some C++/C# (I have some cookie cutter code which looks nearly the same in both) classes:
- ITexture, which is an abstract representation of a texture (allows OpenGL/DirectX/whatever to be used generically).
- ISprite, which is an interface with the functions "GetTexture()" and "GetArea()"
- IAnimation, which inherits from ISprite and has functions to iterate through the frames of an Animation.
- IAnimator, which is an interface with abstract "Update(deltaTime)" and "GetAnimation()" functions.
- CSprite, which is a basic implementation of ISprite with the extra "GetSubSprite(area)" function and can therefore act as a lone image or a sprite sheet.
- CAnimation, which is a basic implimentation of IAnimation and a stores a list of ISprites it iterates through. GetTexture() and GetArea() get the texture and area of the relevant sprite.
- CAnimator, which implements IAnimator and stores a pointer to an IAnimation, and the number of frames per second the animation runs at. Whenever Update(deltaTime) is called it will update to the correct frame based on that speed and the amount of time that has changed since the last call of Update().
This means I could do...say:
Somewhat Pseudo_code
CSprite* a = Content::LoadSprite("HelloWorld");
CAnimation* b = new CAnimation(a, {a->GetSubSprite(Area_of_H)...etc});
CAnimator* c = new CAnimator(c, 0.1f);
while(Run) { c->Update(deltaTime); DrawSprite(b); }
The point of doing things like this is it means the underlying systems couldn't care less what an image does, so long as they know "Hey, I can draw this!" =)
-
I was using the image_speed of GM for a long time, but I stoped to use it after I realize that it's more easy to program when you can have more control over the things. Here is a example of the pull animation in my engine:
/* PULL */
switch(frame mod 64)
{
case 0: image = 3 + face * 9; break;
case 16: image = 4 + face * 9; break;
case 24: image = 5 + face * 9; break;
case 32: image = 6 + face * 9; break;
case 48: image = 7 + face * 9; break;
case 56: image = 8 + face * 9; break;
};
frame += 1;
if(frame == 192)
{
frame = 0;
redface = 1;
};
(http://img709.imageshack.us/img709/5351/pullpal0.png)
The "frame mod 64" will make the animation loop 3 times before the red face appear.
-
I don't think there is anything wrong with using a constant image speed, if you need a more irregular animation then just add in some duplicate frames. If you're using another language then you design the system that suits your needs, eg. if all your sprites are static then you won't be needing anything to animated them.
-
I don't think there is anything wrong with how Gamemaker does it either, but it is not how I would do it. Freki is right on one point in that some animations would require one frame to be shown a bit longer than the other. However adding duplicate frames to smooth an animation is not something to be desired either. Although it is probably better to do that with gamemaker. However Freki's approach to hardcode the frame determination with a selection structure is not something I would do either. This result in that you need to write duplicate code for a lot of situations that you can put in a more general and modular algorithm.
This is what I would do for sprite animations if I had to build my engine from scratch. I would provide the algorithm with the following information:
- The sprites/frames to draw for the animation
- A list of durations for each frame. When my algorithm is cycle based than the durations are in the number of gamecycles, is my algorithm time based then the duration is the minimum number of milli(/nano)seconds.
- Indicator of the current frame.
The algorithm would look like this:
#Draw the current frame of the sprite.
#Increase the counter for the number of times the frame has been drawn / Determine the number of milli(/nano)seconds that have gone past since the frame was drawn for the first time.
#Check if the frame has been show for its maximum duration.
#Increase frame and reset the duration counter.
#Check if the animation is at its end.
#Do end of animation logic.
This algorithm would provide the ability to either show frames at a constant speed or at a variable. This would be the bas for my drawing algorithm. I probably have this part in an animation class or something.
In addition to this I would draw the objects in components, such as torso, limbs and head. Then setup the components as a hierarchical tree. With the root component being drawn at the entity's world position and all the child components are being drawn at an offset from its parent component. The offset can be a constant or at a variable distance depending on the frame and animation.
-
However Freki's approach to hardcode the frame determination with a selection structure is not something I would do either. This result in that you need to write duplicate code for a lot of situations that you can put in a more general and modular algorithm.
Not really, all you need to do it's use the code in a script, I'm using linkPull() for this:
if(global.T_CONTROL == 1)
{
switch(action)
{
case "PULL":
if(frame mod 64 < 32)
{
linkPull();
}
else if(keyboard_check(global.button[BTN_ACTION]))
{
// code that checks if it should continue to pull or just stand and hold the object
}
else
{
action = "STAND";
sprite = spr_linkStand;
frame = 0;
linkStand();
};
break;
case "ANY_ACTION":
if(keyboard_check(global.button[BTN_ACTION]))
{
action = "PULL";
sprite = spr_linkPull;
frame = 0;
linkPull();
};
break;
};
};
So basically I'm just change the action, the sprite that will be used, reset the frame count and execute the script.
This is what I would do for sprite animations if I had to build my engine from scratch. I would provide the algorithm with the following information:
* The sprites/frames to draw for the animation
* A list of durations for each frame. When my algorithm is cycle based than the durations are in the number of gamecycles, is my algorithm time based then the duration is the minimum number of milli(/nano)seconds.
* Indicator of the current frame.
Are you using the word frame to designate a sprite image? Because when I talk about frames I'm talking about the room speed, the frame variable it's already the time/duration. If I understood your algorithm it will probably work but it will use at least the same amount of statements and lines that my code does.
-
Animation and sprites?
I have an Animation class and a layer manager class. Animation class will cycle through frames, in any order specified by the animation file. Only stores numerical data. Images are cued as specified by the layer manager into a linked list, drawn in an order specified by the drawing manager, and then removed from the list. Obviously at this point it's rendering an image based on the animation classes values in an order that's based conditionally (layer).
Reasonably simple stuff.
-
Animation and sprites?
Yeah, I am never good at naming. I mean how you organize and calculate the slide show that makes you believe a character is moving. And not the change of its coordinates.
I have an Animation class and a layer manager class. Animation class will cycle through frames, in any order specified by the animation file. Only stores numerical data. Images are cued as specified by the layer manager into a linked list, drawn in an order specified by the drawing manager, and then removed from the list. Obviously at this point it's rendering an image based on the animation classes values in an order that's based conditionally (layer).
Hmm, lets see if I have a clear view on it. So you are saying that when drawing begins the order is something like this. First the instances of the Animation class provide the frame of the sprite that needs to be drawn to the layer manager, which adds them to a linked list. The layer manager organizes the sprites to layers in one (or more) linked list(s). The linked list(s) is then organized by the drawing manager where each layer's sprites are ordered in the manner they need to be drawn. Then the drawing begins and every sprite that is drawn gets removed from the Linked List until the list is empty once more. Am I correct in this.
Then how does your animation class determine which frame in the sprite has to be drawn and when to go to the next frame in the slide show? How do you deal with the timing? The same question goes to TheDarkJay as well.
Are you using the word frame to designate a sprite image?
Yes, I know I do not have much sense when it comes to naming things. I also know that scripts in GM are very usefull, because they can be used as functions, states or as an implementation to generic objects. However GM also has some base functionality that it will always compile and run code along with the code you made. I know that your own code might give you more control, but it does make GM's own code that is being replaced pointless. And running pointless code still uses CPU resources, which might be needed when there are lot of objects.
The choice in GM that has to be made is whether you want more control or do you trust GM to do a proficient job. In my personal opinion I find GM to do a good job in drawing and timing of sprites. But to each their own choice.
-
I personally just load all the images to an array and cycle through it based on an animation speed. Some pseudo code for you...
float animSpeed = .5
while animating
static float frames = 0
drawSprite(sprite[(int)frames])
frames += animSpeed
end while
-
Then how does your animation class determine which frame in the sprite has to be drawn and when to go to the next frame in the slide show? How do you deal with the timing? The same question goes to TheDarkJay as well.
My standard Animation is effectively a linked list of smart pointers to sprites. The basic animator simply loops the animation through this at a preset speed. This means if I want a frame to last twice as long, I could have two smart pointers to the same sprite, one after the other. Alternatively, for a more unique situation I could overload the animator interface with an animator that also contains a linked list of frame lengths.
More complex methods can be introduced as needs be. Another implementation of the animator class could maintain it's own list of timings to follow. If I ever needed something complex I'd add a "LoadAnimator" to my content manager and create an animation file format with all related information. The only thing my core engine cares about in the end is whatever is being fed into it at some point is descended from the correct interface =)
-
My standard Animation is effectively a linked list of smart pointers to sprites.
What's a smart pointer?
-
"In computer science, a smart pointer is an abstract data type that simulates a pointer while providing additional features, such as automatic garbage collection or bounds checking. These additional features are intended to reduce bugs caused by the misuse of pointers while retaining efficiency. Smart pointers typically keep track of the objects they point to for the purpose of memory management."
http://en.wikipedia.org/wiki/Smart_pointer