Author Topic: Link List for multi-frame (image) sprites (Read 3954 times)

StormWingDelta · « **on:** December 30, 2011, 04:49:29 pm »

One of my classmates figured this out and I was wondering if a code or codes could be added to SFML to make making sprites with more than one frame (image) easier to do.

He used a link list to do this and it let him do a number of things with animated sprites I haven't seen done in a while.

It let him shift between the different frames he had for his sprite as long as they were the next frame, previous frame, first frame, or last frame.

It could be upgraded to freely shift between any frame if setup to do so.

Not sure how this would be setup but it seems like it could be useful down the road and I though I should mention it.

hayer · « **Reply #1 on:** January 12, 2012, 05:12:05 am »

This is old.. and if you want it, code it your self.. A linked list is easy to do.
And then you just need to add the data like, frame size, time per frame, and define where each animation is.

jone · « **Reply #2 on:** February 03, 2012, 07:00:38 pm »

Assuming you're coding in C++: the STL has a lot of useful data structures. For example, std::list implements a doubly linked list: http://www.cplusplus.com/reference/stl/list/

You could easily use this to do what you're describing.

Nexus · « **Reply #3 on:** February 03, 2012, 08:40:37 pm »

Quote from: "hayer"

A linked list is easy to do.

And easy to do wrongly. There's normally no reason to reinvent the wheel, just use the STL

By the way, there are many containers apart from std::list in the standard library, of which some are often more suitable. Basically, std::vector is the general-purpose sequential container, while others are used for specific needs.

HKei · « **Reply #4 on:** February 04, 2012, 03:08:19 pm »

I don't think it's THAT easy to mess up a linked list, unless you are a complete beginner.

Nexus · « **Reply #5 on:** February 04, 2012, 04:17:48 pm »

Yes, it is. Even experienced developers have a lot of problems, when it comes to the correct treatment of dynamic memory management, exception safety, iterator validity and similar topics. Implementing all those parts correctly and efficiently is a lot of unnecessary work, since existing implementations are already optimized and tested.

Why should one devlop his own list with the same functionality as std::list for productive usage?