Animated sprites
by Tomas Dahle · in Torque Game Builder · 04/21/2005 (1:35 am) · 49 replies
I may have missed out on something and if I do I apologize, but it seems to me that it is impossible to define rather important features of animations such as a single frame's duration and internal offset? (By internal offset I mean that with certain animations where the frame images are of various size frame #1 might have to be shifted a few pixels to the left compared to frame #2 to make for example a walking animation look intelligent)
I can easily fake a single frame's duration by just making many duplicate frames and make it so that the total duration gives each frame i.e 0.1 second duration, but that seems silly. And I have no idea how I can solve a frames internal offset without extending all images to be as big as the biggest image, which in some cases might be an extreme waste of memory.
Any thoughts or obvious solutions? :)
I can easily fake a single frame's duration by just making many duplicate frames and make it so that the total duration gives each frame i.e 0.1 second duration, but that seems silly. And I have no idea how I can solve a frames internal offset without extending all images to be as big as the biggest image, which in some cases might be an extreme waste of memory.
Any thoughts or obvious solutions? :)
About the author
#42
A good animation system is extremely important, if not one of the most important features lacking in T2D. The animation controller has been setup to that we can put in our super-dooper new system. Our initial reluctance was because of the editor support needed to truely make something like this shine. At the moment, there are a couple of things that are the highest priorities, animation is one of them.
This won't be a revamp, it'll be extending the features of the animation controller. This central animation system will simultaneously extend animations system-wide so you'll get the same animation support for tiles as well; as you do now. This will, of course, apply to all future T2D objects that use the animation-controller.
I do respect peoples opinions and I try my hardest not to be defensive because I should let T2D speak for itself. The problem is that there just isn't enough hours in a day to get everything done. Some people speak here as if there's a fulltime crew working on T2D when there isn't. It's so easy to just say do feature X because you should have but the reality of life and part-time development is something else. Not an excuse, a reason. Parallel development of features is the reality and some things get finished before others whilst others don't make it into the pot. That's a snapshot and the following month it's finished. Not the big deal that it's made out to be here.
I would ask for your patience whilst we simultaneously try to implement the features in our plan as well as fix existing issues.
- Melv.
04/22/2005 (5:52 am)
I'd just like to clarify our position because with all the damn quotes and countering going on, it gets lost in the noise.A good animation system is extremely important, if not one of the most important features lacking in T2D. The animation controller has been setup to that we can put in our super-dooper new system. Our initial reluctance was because of the editor support needed to truely make something like this shine. At the moment, there are a couple of things that are the highest priorities, animation is one of them.
This won't be a revamp, it'll be extending the features of the animation controller. This central animation system will simultaneously extend animations system-wide so you'll get the same animation support for tiles as well; as you do now. This will, of course, apply to all future T2D objects that use the animation-controller.
I do respect peoples opinions and I try my hardest not to be defensive because I should let T2D speak for itself. The problem is that there just isn't enough hours in a day to get everything done. Some people speak here as if there's a fulltime crew working on T2D when there isn't. It's so easy to just say do feature X because you should have but the reality of life and part-time development is something else. Not an excuse, a reason. Parallel development of features is the reality and some things get finished before others whilst others don't make it into the pot. That's a snapshot and the following month it's finished. Not the big deal that it's made out to be here.
I would ask for your patience whilst we simultaneously try to implement the features in our plan as well as fix existing issues.
- Melv.
#43
fxStaticSprite2d has a %obj.setFrame() method to allow you to pick what frame from an imagemap to display for that static sprite. You then use a schedule call to schedule the next animation step.
Is this a "foolproof" method? No it isn't since I wrote it in 1 hour at 12am-1am, but the problems it does have could be fixed pretty quickly.
04/22/2005 (8:34 am)
Quote:
An interesting way to go about it. Though I'm not entirely clear about how it actually updates the individual frames of the animation. Since it uses a static sprite, rather than an animated one, I'm curious as to how the script gets updated during each frame-delta.
fxStaticSprite2d has a %obj.setFrame() method to allow you to pick what frame from an imagemap to display for that static sprite. You then use a schedule call to schedule the next animation step.
Is this a "foolproof" method? No it isn't since I wrote it in 1 hour at 12am-1am, but the problems it does have could be fixed pretty quickly.
#44
Ah. I missed the schedule calls.
I know that Josh and Melv agree on the importance of a hardcore animation system; I knew that before this thread started. However, your analogy doesn't indicate that you seem to. I don't want anyone walking away from this thread with the idea that having a better sprite animation system is superfluous to game making in the same way that nitro injections and so forth are superfluous to having a functioning car.
Yes, but what else is new ;)
It doesn't need to be an exact recitation of the limitations of the engine. Much like the T2D feature list, it can be a short list of one liners stating generalities, like "Animation system is, at this point, somewhat incomplete, but this will be improved in the future." At the very least, when someone sees it, they will no longer be surprised by the lack of a more complete animation system. The idea is to prepare them for specific problems, not generalities like, "Well, some stuff may not be what you expect it to be;" this is ultimately unhelpful in evaluating the engine or knowing what you are buying.
Once again, it goes back to fundamental design and expectations. You expect anything that calls itself a 2D engine to provide certain things, moreso when that 2D engine provides other, more superfluous, things. When you see a 2D game engine that has a hardcore particle system, the logical assumption is, "Well, if they were willing to go so far as to build a Tier 4 feature into the engine, they must have Tier's 1-3 pretty well covered, though perhaps not complete." So, when you walk in and see that a significant Tier 1 feature is incomplete, you can't help but be disappointed.
I know you've explained how the misprioritization came about (and I even repeated it here), but that doesn't change the fact that it is there and that people are able to draw the wrong conclusions from it. The feeling of not getting one's money's worth comes not from what is there, but from not being told what isn't there. And, if you have experience designing systems and have thought about the problem of 2D engine and/or game design, you already have preconceptions and prejudices of what ought to be in a 2D engine and what ought not be there. These are the people who need to understand from day one what T2D provides, what it does not yet provide, and what it will not provide. Only one of these 3 is spelled out on the purchasing page.
I, for one, would certainly have come to T2D from a completely different perspective if I had had a more accurate picture of what T2D was before I bought it. I would almost certainly have still purchased it, but I would not feel nearly as confused by some of the design and implementation choices in the engine if I had been told about them up front. All I'm asking is to know what a product is before buying it. You only get one chance to make a first impression ;)
No; I'm aware that you (Melv) understand the situation. This comment was meant for Stephen, not you.
04/22/2005 (10:36 am)
Quote:fxStaticSprite2d has a %obj.setFrame() method to allow you to pick what frame from an imagemap to display for that static sprite. You then use a schedule call to schedule the next animation step.
Ah. I missed the schedule calls.
Quote:No one at all said this. If you felt my analogy wasn't appropriate, fine. It WAS AN ANALOGY. Josh said specifically that they fully agree, and are working on it.
I know that Josh and Melv agree on the importance of a hardcore animation system; I knew that before this thread started. However, your analogy doesn't indicate that you seem to. I don't want anyone walking away from this thread with the idea that having a better sprite animation system is superfluous to game making in the same way that nitro injections and so forth are superfluous to having a functioning car.
Quote:You seem to think that we should've delayed the EA release for 1 month to get this particular feature in and maybe we should have but I'm sure that other people around here would disagree.
Yes, but what else is new ;)
Quote:Let's just consider how we could begin to explain all the things that are not provided.
It doesn't need to be an exact recitation of the limitations of the engine. Much like the T2D feature list, it can be a short list of one liners stating generalities, like "Animation system is, at this point, somewhat incomplete, but this will be improved in the future." At the very least, when someone sees it, they will no longer be surprised by the lack of a more complete animation system. The idea is to prepare them for specific problems, not generalities like, "Well, some stuff may not be what you expect it to be;" this is ultimately unhelpful in evaluating the engine or knowing what you are buying.
Quote:Is warning enough that you should expect problems.
Once again, it goes back to fundamental design and expectations. You expect anything that calls itself a 2D engine to provide certain things, moreso when that 2D engine provides other, more superfluous, things. When you see a 2D game engine that has a hardcore particle system, the logical assumption is, "Well, if they were willing to go so far as to build a Tier 4 feature into the engine, they must have Tier's 1-3 pretty well covered, though perhaps not complete." So, when you walk in and see that a significant Tier 1 feature is incomplete, you can't help but be disappointed.
I know you've explained how the misprioritization came about (and I even repeated it here), but that doesn't change the fact that it is there and that people are able to draw the wrong conclusions from it. The feeling of not getting one's money's worth comes not from what is there, but from not being told what isn't there. And, if you have experience designing systems and have thought about the problem of 2D engine and/or game design, you already have preconceptions and prejudices of what ought to be in a 2D engine and what ought not be there. These are the people who need to understand from day one what T2D provides, what it does not yet provide, and what it will not provide. Only one of these 3 is spelled out on the purchasing page.
I, for one, would certainly have come to T2D from a completely different perspective if I had had a more accurate picture of what T2D was before I bought it. I would almost certainly have still purchased it, but I would not feel nearly as confused by some of the design and implementation choices in the engine if I had been told about them up front. All I'm asking is to know what a product is before buying it. You only get one chance to make a first impression ;)
Quote:Are you trying to convince us how important a sophisticated animation-system is?
No; I'm aware that you (Melv) understand the situation. This comment was meant for Stephen, not you.
#45
So, there's a lot of marketing updates we could do, and we will when we have time. Such changes would no doubt help us increase sales. We haven't made these changes yet because, well, it takes time. Even though Melv and I don't have to do all the marketing stuff or anything, it still takes time from us. Keeping up with the workload we've set ourselves for T2D is hard enough in itself, and then we take additional time beyond that to try to keep up with the forums here. Making marketing changes slide, I guess.
Most likely, we'll update all that stuff in the 1.1 update.
Anyway, just giving everyone an inside look at that, I guess. :)
Harold, thanks very much for the code there. As you demonstrate, getting a decent stop-gap solution to the problems here isn't difficult at all. It's also funny that you did about 1/100th as much typing to just get a stop-gap solution going for this issue as everyone else spent talking about it. Work > talk. ;)
Everyone, I think we can consider this issue fairly well closed for now. We are very well aware of the animation system's current state and how it should be extended. I hope it's good to hear that we're going to be addressing it soon. I think that our solution for the animation system will surpass people's expectations for the most part. In the mean time, this issue will not stop you from making a game-- not by any means. It is extremely easy to customize the system as it stands now-- even without touching C++ code-- to create the kinds of functionality discussed in this thread. Harold provides a stop-gap solution here, and his work could easily be extended even further. There are lots of other ways to work around this issue, temporarily until we update the official animation system, and if there are any more posts here, it'd be great if they were solution-oriented.
04/22/2005 (11:01 am)
Well, it might not be a bad idea to include a list of things we're working on on the T2D community page. We've considered that a number of times before actually, but ultimately haven't made the time to make the changes. There are a bunch of marketing updates we could make. Besides listing stuff we're working on (which is a positive thing, marketing-wise, demonstrating that the developer's are committed to the product and working on it every day), there's a lot of good stories we can tell about community-contributions and all the excellent tutorials, code snipits and help being offered here and in the resources. Also, having feedback from lots of users now, we have a better idea of which pieces of the engine excite and interest people the most, and that is always useful marketing info.So, there's a lot of marketing updates we could do, and we will when we have time. Such changes would no doubt help us increase sales. We haven't made these changes yet because, well, it takes time. Even though Melv and I don't have to do all the marketing stuff or anything, it still takes time from us. Keeping up with the workload we've set ourselves for T2D is hard enough in itself, and then we take additional time beyond that to try to keep up with the forums here. Making marketing changes slide, I guess.
Most likely, we'll update all that stuff in the 1.1 update.
Anyway, just giving everyone an inside look at that, I guess. :)
Harold, thanks very much for the code there. As you demonstrate, getting a decent stop-gap solution to the problems here isn't difficult at all. It's also funny that you did about 1/100th as much typing to just get a stop-gap solution going for this issue as everyone else spent talking about it. Work > talk. ;)
Everyone, I think we can consider this issue fairly well closed for now. We are very well aware of the animation system's current state and how it should be extended. I hope it's good to hear that we're going to be addressing it soon. I think that our solution for the animation system will surpass people's expectations for the most part. In the mean time, this issue will not stop you from making a game-- not by any means. It is extremely easy to customize the system as it stands now-- even without touching C++ code-- to create the kinds of functionality discussed in this thread. Harold provides a stop-gap solution here, and his work could easily be extended even further. There are lots of other ways to work around this issue, temporarily until we update the official animation system, and if there are any more posts here, it'd be great if they were solution-oriented.
#46
There are a couple of other features as well as a decent animation-system that caused us 'pain' not to have in but we needed to get the thing out, it was burning our hands. It was also the case that I was just exhausted at the time and I wanted to have a week or two break away from it. As it turned-out, I spent all my time answering posts on the forums for the first few weeks instead but it was a break from coding so I still felt rested. ;)
All I can say now is sorry that this feature is not in yet and I don't disagree that it is a fundamental thing to have but well, it's all been said.
I appreciate the understanding and the light-hearted post. :)
Thanks.
- Melv.
04/22/2005 (11:02 am)
I am sincerely sorry for any confusion caused by the out-of-sync features but since GG took hold of things and T2D became more than just a distraction, we've been trying to rectify that situation.There are a couple of other features as well as a decent animation-system that caused us 'pain' not to have in but we needed to get the thing out, it was burning our hands. It was also the case that I was just exhausted at the time and I wanted to have a week or two break away from it. As it turned-out, I spent all my time answering posts on the forums for the first few weeks instead but it was a break from coding so I still felt rested. ;)
All I can say now is sorry that this feature is not in yet and I don't disagree that it is a fundamental thing to have but well, it's all been said.
I appreciate the understanding and the light-hearted post. :)
Thanks.
- Melv.
#47
This looks like a very old thread but I just wanted to ask if these animation system improvements are still planned? My claymation iTGB game (see image on the left) uses large animated sprites with varying frame sizes by necessity so using the current animation system a fair bit of texture space is wasted :-(
A way of setting an x/y coordinate offset for each individual animation frame would be really useful to me. I investigated using setSourceRect in script on individual sprites to build my own system but calling that once per frame seems to kill the frame rate when running on the Mac (never mind the iPhone).
I haven't run into the issue with wanting to set individual frame lengths but coming from the mainstream games industry that seems like a reasonable request to me.
If the engine had these improvements in the next version it would rock.
Thanks!
Seb
06/08/2010 (8:41 am)
HelloThis looks like a very old thread but I just wanted to ask if these animation system improvements are still planned? My claymation iTGB game (see image on the left) uses large animated sprites with varying frame sizes by necessity so using the current animation system a fair bit of texture space is wasted :-(
A way of setting an x/y coordinate offset for each individual animation frame would be really useful to me. I investigated using setSourceRect in script on individual sprites to build my own system but calling that once per frame seems to kill the frame rate when running on the Mac (never mind the iPhone).
I haven't run into the issue with wanting to set individual frame lengths but coming from the mainstream games industry that seems like a reasonable request to me.
If the engine had these improvements in the next version it would rock.
Thanks!
Seb
#48
These features definitely would be useful, there have been a resource(s) that can help with some of this, one I believe was put out by a user that helps reduce the waste of extra space in your sprite sheets in general which could mitigate that.
As for future versions, nothing to officially promise now, just that some animation improvements or changes to make the system more robust have been talked about for a while now and I wouldn't be surprised if it gets some attention in the future.
06/11/2010 (8:45 am)
Wow you did find an old thread, last post before yours being over 5 years ago lol, brings back memories :) These features definitely would be useful, there have been a resource(s) that can help with some of this, one I believe was put out by a user that helps reduce the waste of extra space in your sprite sheets in general which could mitigate that.
As for future versions, nothing to officially promise now, just that some animation improvements or changes to make the system more robust have been talked about for a while now and I wouldn't be surprised if it gets some attention in the future.
#49
06/12/2010 (12:50 pm)
If you're referring to the UnChaos texture packing then yes it's useful and I'm using that, but sadly it doesn't completely solve this problem. A more powerful animation builder that supported different sized frames and variable offsets for each frame would really improve the engine IMHO. While features like physics and particle systems are cool they aren't much use on the iPhone because of the frame rate limitations. 
Torque 3D Owner Stephen Zepp
No one at all said this. If you felt my analogy wasn't appropriate, fine. It WAS AN ANALOGY. Josh said specifically that they fully agree, and are working on it.