- Forum
- General C++ Programming
- 2d animation
2d animation
Any ideas on how this could be coded?
For example, a knight riding at another knight then stabbing him. I was thinking "taking apart" the graphics. i.e. I would put individual body parts in separate images (arms, legs, head, sword, etc) and then drawing them to the screen at different positions and rotating them as necessary. Does this sound plausible, or is there a better way?
Any ideas would be great.
p.s:
I am going out of town on vacation tomorrow morning, so I may not respond.
For example, a knight riding at another knight then stabbing him. I was thinking "taking apart" the graphics. i.e. I would put individual body parts in separate images (arms, legs, head, sword, etc) and then drawing them to the screen at different positions and rotating them as necessary. Does this sound plausible, or is there a better way?
Any ideas would be great.
p.s:
I am going out of town on vacation tomorrow morning, so I may not respond.
I already have a graphics API, however, OpenGL looks awesome. I don't have time to learn another right now unfortunately. Any feasible ideas to animate some simple 2d graphics without having TONs of images that change a little bit in every pic?
If your graphics API can't rotate images, I recommend you abandon it, as it's probably extremely out of date.
Image rotation has been hardware accellerated for years. An API that doesn't support it is likely very out of date and will force you to do rotation in software... which will be slow and complicated.
Image rotation has been hardware accellerated for years. An API that doesn't support it is likely very out of date and will force you to do rotation in software... which will be slow and complicated.
Unless you are doing 3D graphics, you are wasting your time with image rotations and body parts and the like.
In 2D animation, professionals draw their characters on paper (or using a tablet) and finish it in the computer, using a lot of poses and a lot of testing to make sure the movement is smooth. If you are limited on space, the finished graphics will be split up into smaller graphics and their coordinates and drawing order are programmed into the character drawing routines. Finally, when Ken does his uppercut punch the correct pieces are drawn in the correct places for each frame of movement until done.
SFML will do fine for this.
Hope this helps.
In 2D animation, professionals draw their characters on paper (or using a tablet) and finish it in the computer, using a lot of poses and a lot of testing to make sure the movement is smooth. If you are limited on space, the finished graphics will be split up into smaller graphics and their coordinates and drawing order are programmed into the character drawing routines. Finally, when Ken does his uppercut punch the correct pieces are drawn in the correct places for each frame of movement until done.
SFML will do fine for this.
Hope this helps.
Therefore in general for gaming companies, they employ dedicated positions for animation artists to "draw" and make "stunning" graphics with the help of some pretty high-tech expensive software. Then create another position to do the programming to "integrate" those animation artists output into the final software.
I don't know if this is industry bias but in my country, the "developer" dabbling in animation get all the media attention. For outsiders they may think that person cover the whole spectrum when in most cases, I would presume that person is more of an animation artist than the programmer doing the programming.
Gaming companies should differentiate the position title clearer. Animation artist, game programmer etc should tell outsiders the actual job scope. But I do admit, the generic title game programmer may entail the animation job scope too.
I don't know if this is industry bias but in my country, the "developer" dabbling in animation get all the media attention. For outsiders they may think that person cover the whole spectrum when in most cases, I would presume that person is more of an animation artist than the programmer doing the programming.
Gaming companies should differentiate the position title clearer. Animation artist, game programmer etc should tell outsiders the actual job scope. But I do admit, the generic title game programmer may entail the animation job scope too.
@disch: My API has rotation capabilities.
@duoas: This sounds like it would incorporate TONs of graphics. I was hoping to keep the final size of the project as small as possible.
@duoas: This sounds like it would incorporate TONs of graphics. I was hoping to keep the final size of the project as small as possible.
I have two comments; One, Duoas is a very experienced coder-- so on that note, his ways are a lot more "correct," however, his methods aren't the simplest. Second, many graphics APIs' have the capability for rotation, but whether you are importing your own sprites or not, is a completely different topic. But no worries, openGL supports both sprites', and shape rotation; OpenGL is also great for 3d programming, and it's quite easy on beginners (most of the time). So if you can figure it out yourself, or find sourcecode online, you can probably make Ken's arm give a hearty uppercut to his opponent, Seth.
For OpenGL you can also use GLUT to make it even simpler :)
For 3d I suggest OGRE (also for OpenGL)
For 3d I suggest OGRE (also for OpenGL)
Most 2d game sprites aren't that complex. Only the really beautiful Street Fighter stuff gets very messy -- and the sprite code is managed (that is, programmed) by, essentially, classes that handle just that. Just as you have a "level editor" for creating and storing levels, you have a "character editor" that allows you to design and save character information in terms of sprites, their positions, and display timing.
Think of Mario jumping over a mushroom. Pretty simple, no? One sprite for the mushroom. Two sprites for Mario (one not-jumping-pose and one jumping-pose). When you get as far as something pretty like Commander Keen, that's up to somewhere around three or four sprites for a walk cycle. Etc. You don't need a whole lot to be fairly smooth.
If space is a premium, you can also break sprites up so that you can reuse pieces between poses.
I do have to take some issue with this. The reason things are done the way they are done is because they are the simplest, most efficient way to get an effect.
So, to be correct, it depends on what you are doing. For your animation, some rotations and the like might work just fine. If you think that at some point in the future you might do something a little more complex with it, then it is worth your time to put the machinery in place to make dealing with all the data easy later.
Good luck!
Think of Mario jumping over a mushroom. Pretty simple, no? One sprite for the mushroom. Two sprites for Mario (one not-jumping-pose and one jumping-pose). When you get as far as something pretty like Commander Keen, that's up to somewhere around three or four sprites for a walk cycle. Etc. You don't need a whole lot to be fairly smooth.
If space is a premium, you can also break sprites up so that you can reuse pieces between poses.
| however, his methods aren't the simplest |
So, to be correct, it depends on what you are doing. For your animation, some rotations and the like might work just fine. If you think that at some point in the future you might do something a little more complex with it, then it is worth your time to put the machinery in place to make dealing with all the data easy later.
Good luck!
Thanks!
I was playing around with a little "animation" tool I made. It allows me to position an rotate a characters arms, legs, body and head (all as separate sprites) and then take a "screen shot" which essentially stores their x/y locations as well as their rotation into a vector. Then, at the end, the contents of the vector are stored into a file. I also made a little "animation player" that draws the sprites at the stored positions and rotations, creating a little looping clip. I plan on using it to make little "cut scenes" in my game.
I was playing around with a little "animation" tool I made. It allows me to position an rotate a characters arms, legs, body and head (all as separate sprites) and then take a "screen shot" which essentially stores their x/y locations as well as their rotation into a vector. Then, at the end, the contents of the vector are stored into a file. I also made a little "animation player" that draws the sprites at the stored positions and rotations, creating a little looping clip. I plan on using it to make little "cut scenes" in my game.
Topic archived. No new replies allowed.