PDA

View Full Version : Help, advice to program an animation



NicolasF
February 2nd, 2009, 07:50 AM
Hi!

I want to write a graphic program that has a lot of animations, but the problem is that there are a lot of sprites for each animation about 20 to 30 sprites each with a total of 20 animations.

I've never program anything like this, so I feel a little lost here... I've searched for some example source code on this but I didn't find anything useful.

The sprites that I have for each animation are stored in BMP format.

Here are the questions:

What do you think it would be the best way to store this animations in memory? compressed or uncompressed?

Are they stored exactly the same in memory as they are in the file?

If I copy all this sprites in memory compressed will if affect performance when I run it in slower PCs like XTs?

I'll appreciate any help

Bye!!

mbbrutman
February 3rd, 2009, 04:00 AM
I'm not the resident graphics guru here, but the standard PC hardware doesn't have hardware sprites. So you are going to be XORing your bitmaps across the video memory the old fashioned way.

The sprites should be small enough where compression doesn't matter. The penalty for decompressing and XORing into video memory will be too great. Just assume the machine is 10x slower than you thought and program defensively. ;-0

pontus
February 3rd, 2009, 06:45 AM
Hi!

Here are the questions:

What do you think it would be the best way to store this animations in memory? compressed or uncompressed?

Are they stored exactly the same in memory as they are in the file?

If I copy all this sprites in memory compressed will if affect performance when I run it in slower PCs like XTs?

I'll appreciate any help

Bye!!


Keep them uncompressed, as mbbrutman said, it will probably not matter if your sprites are small. A simple RLE compression might not be that cpu intensive, but I don't have the experience to answer that.

They are probably not stored the same way in memory as in the file. You must match the format of the screenbuffer.

carlsson
February 3rd, 2009, 07:33 AM
Actually I'm not sure Nicolas means sprites as in small graphic objects that can be moved independently on top of other graphic content. I think he means frames, that he will write a program full of several independent animations, and each animation will be 20-30 frames.

I may be wrong, only Nicolas himself can tell exactly which interpretation is the correct.

NicolasF
February 3rd, 2009, 03:20 PM
Hi!

I want to animate small sprites, but the problem is that there are a lot of them.

Trixter
February 3rd, 2009, 05:42 PM
What do you think it would be the best way to store this animations in memory? compressed or uncompressed?

Are they stored exactly the same in memory as they are in the file?

If I copy all this sprites in memory compressed will if affect performance when I run it in slower PCs like XTs?


Like all programming exercises, what you do depends on what you're trying to achieve. Do you want to make full-frame animation (ie. like a cartoon or movie), or do you want to move 20 sprites around? Because the techniques are different for both.

A typical sprite library has several functions, but usually the two most required are compiled sprites (best speed, but cannot clip) and clipped sprites (for when you get to the edges of the viewable area).

As for what format to store them in in memory, that depends on what your target is. Is it any graphics card, or something specific like VGA? Is it any hardware, or specifically low-end devices?

Also, what language/compiler are you using?

Essentially, we need you to be more specific in order to help you.

NicolasF
February 5th, 2009, 03:25 AM
Hi! I wanted to make an animation of the prince in Prince of Persia 1 game.

Just to show all of his movements.

To start I want to make it work in a VGA card, then move onto CGA or hercules.

I'm using Borland C++ 3.1

What do u mean by compiled sprites?

nige the hippy
February 5th, 2009, 07:59 AM
you could look here for some clues....

http://www.oldskool.org/pc/8088_Corruption

full screen video for the 5150, (there are a few threads on here discussing this).

Then perhaps do a program to generate each of the frames, then play it back as a video.

barythrin
February 5th, 2009, 08:09 AM
I'm not sure on the architectures supported, but you might want to check out the Allegra library for C. You can use it with several compilers though I don't recall trying it with Borland 3.x or TurboC (which I liked). Either way it gives you quite a lot of easy commands for doing graphics or sound (it's a game/graphics library for developers) and opening bmp files, etc. From there it's mostly just waiting for a key to be pressed, and some loops to have it go through the files you want it to display.

It's kinda just a bunch of macros or scripts when doing simple game animation. Just like mortal combat or any other game, you loop the pictures you want while they're standing still (or just show that sprite/bitmap), then change the series if they hit a key. The background of the image can be made to be clear and then you just need to program some pixel collision detection to know if it's touching something and what should happen if that's the case (they can't move any further that direction, or they're hit, etc).

We used that on a 486 so again it may not translate well if you're going vintage with it, but I'm not sure. I'm also not sure what your experience is in programming so if you already know what you're doing then skip the library and just whip out some code ;-)

Trixter
February 5th, 2009, 09:50 AM
Allegra requires 32-bit C (aka djgpp) so that won't work for him.

You need a sprite/graphics library. The only one I know of that will work with BC 3.1 that supports multiple graphics modes is FastGraph. They still provide their shareware release of fastgraph for free. FastGraph/Light can be downloaded from http://www.fastgraph.com/demos.html and has several examples in C.

If you do a lot of searching of simtel archives you can probably find a few others, and for free, but most of them are dedicated to a single graphics mode (like the excellent xlib, which supports VGA only).