Yes, I think the best way to do that is to define our own animation data.GGuy wrote:It probably would be better to come up with our own animation system in a traditional sense with multiple images per sheets that it scrolls through.
I thought about this function before as tepples suggested something similar earlier in this topic.
The minimal implementation is to define the animation as a sequence of replacement sprites and how many frames each sprite lasts. We also need to define how many idle frames the animation can have before the emulator considers the animation as not in use and resets it.
There are some problems which I can think of:
1. All occurrences of the same animation on the screen will display the same sprite. This can be a problem if there are multiple enemies on the screen and their actions do not sync with each other.
2. The animation always run at the same speed even when the game uses slow motion.
3. The animation always run forward, so if the game repeats sprites backward (eg. ABCCBA) to display a swinging motion then the added frames in the animation will not link up correctly(A1A2-B1B2-C1C2-C1C2-B1B2-A1A2 instead of A1A2-B1B2-C1C2-C2C1-B2B1-A2A1).
4. When the same sprite is use at more than one situation, the the same animation will be shown regardless of the situation.
I think this is an important function which addresses one of the 5 main limitations of NES graphics (number of colours we can use, range of colours we can choose from, the screen resolution, number of animation frames we can fit inside a bank and number of sprites we can have on screen) and I may add this to the emulator in the future. But to do this I think I need to redesign the GUI as it is getting cluttered.