- How can I best store an character animation?
One animated gif for walking, one for running, one for jumping…
I’m not sure there’s a way to load frames from an animated GIF (or any
other multiframed- or layered- image file)
There isn’t anything in SDL to do this, nor am I aware of any libraries that
can handle this. Of course, anything is possible. It just means you would
have to write the code to load an animated GIF file and create an array of
surfaces for them all. Sounds like more than you could probably tackle at
this point in time, though.
So you probably want to go another route. Basically you could use individual
images, or one big image. You should consider which one is going to be
easier to work with for the artist (or yourself if you are going to do the
art). Then also look at how blitting is done, what the overhead is between
one big image and many little images, etc. Essentially you probably want to
design your system of doing things around the tools you have to work with SDL
and the artist.
Of course, you could build the animated GIF and then use tools like
multigif and netpbm to convert it to split files or one big file.
Right, but check with the artist. Find out what would work best for him. If
doing an animated gif would be a pain for him, and decoding them in your code
would be a pain, then there’s not much point in going that route, is there?
But if each of you are under the assumption it’s easier for the other guy so
you deal with it, then you are using an inefficient system.
or should I use one large image and blit out the rects for each frame to
This is resonable.
display?
or should I ........
I’m naughty and create separate image files from each frame of animation.
It’s mainly up to you. It can be done either way, easy to use either way
really, just as fast either way really. So if you prefer one method, you
should use that method.
If I should use one large image, what is the most efficient way:
1. Make an SDL_Rect-array and blit from the large image to the screen
2. Make one SDL_Surface for each frame and then blit each frame to
screen?
#2 sounds like it’s defeating the purpose of using one large image. If you
have a bunch of little images, why not blit those directly, instead of to the
larger image and then that directly?
Good question. Those more familiar with the internals of SDL (and
video cards) would know which is more efficient (if one even is)
I haven’t really looked into it, but having looked at some of the code, it
looks like well written code, so I’m sure there wouldn’t be a difference
really. It would mainly come down to where your surfaces are located:
hardware or software. Hardware surfaces will be faster than software ones.
- A friend once told me that modern pc’s have a special memory in the
graphic hardware that automaticly pasted sprite graphics to the screen.
This means that if I want to move a sprite - I only need to change the
coordinates to it (don’t need to care about refreshing background etc.).
It made it extra easy for spritecollision-dection too. Is this correct?
No. There’s a lot of different video cards out there, though, so some cards
might support this. It isn’t anything standardized, though, like SVGA. So
if you are writing for a general audience, best to avoid using anything like
that.
- Any advice on how to make a nice & powerful level editor? Basic
concepts I should know about? Source code to read?
Ya. Figure out what you need first (try and consider all possibilities and
break them down into cases), then design your editor to meet those needs, and
then start implementing it. Pretty much the way any editor should be done
really. You could use other methods, like a text editor. If that seems like
it would be even harder than making an editor (does to me unless maps are
pretty simple), then you might be better off making an editor.
One thing about editors I’ve learned, though, is keeping editor code and game
code in sync can be challanging. Some people think it better to keep the 2
as seperate programs, while others think it better to combine them into one
program. All kinds of interesting issues with them. 
The best way to
discover these for yourself of course, is to jump in and write one yourself.
So it’ll be educational at the very least.
So I wouldn’t worry so much about reading source code or anything. You might
want to look at other people’s editors for their games, though, and see what
you like and dislike about them. You’re almost sure to get new ideas you
never though of before, which can be useful.On Friday 16 March 2001 11:10, you wrote:
), but I am