/////////////////////////////////////////////////////////////////////////////
============================================================================
	******  ****  ****   ****  | 
	  **   *    * *   * *    * | allegtest a.k.a. Virtu engine
	  **   *    * *   * *    * | 
	  **   *    * *   * *    * | Contributor and Authors found at end
	  **    ****  ****   ****  | 
============================================================================
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

	Add a Sprite factory Class... keeping track of the current amount of sprites...

		Since each sprite should not be loaded from memory more than once, and
		ever there after just referenced by a pointer type... thereby necessitating
		the introduction of a factory class to keep track of loading the sprites
		and sequential animation loops.

		The best use for the Sprite Factory Class would be, to couple it with
		the animChar class such that a ptr argument will not break the program.
		Depending on how animChar, and User, classes are implemented, the previous
		class may not be able to work correctly.

		The sprite factory class shall keep track of ALL sprites... with an easy
		calling convention for a sprite, either by string "FROG", by number, or
		by reference. Once the class has loaded all graphics it shall pass
		a head link to the initial animation, it will also pass one past the
		end of the list. Alternatively, the call could also return the length from
		*.begin() to *.end(), but that may not be necessary unless the list
		is a set of arbitrary loops. Then it will be necessary to return the
		first 3 lengths of the loops... i.e. x1, x2, x3, as in the animChar class
		however, this needs to be thought out further so as to not introduce any
		overhead.

			An idea to this problem could be to break each animation in to either
			one large linked list:

			<< ANIM000, ANIM001, ANIM002, ANIM003 ... ANIM??? >>

				RETURN TO CALLER AN INTEGER ARRAY : 
				{

					// This is from animChar.h
					struct animarray {
					//	int begining;
					//	int ending;
						int firstlooplength;
						int secondlooplength;
						int thirdlooplength;
					};
				}

			Or as a linked bucket:

			<< ANIM000, ANIM003, ANIM006, ANIM009 >>
			 < ANIM001, ANIM004, ANIM007, ANIM010 >
			 < ANIM002. ANIM005. ANIM008. ANIM011.>
			   ANIM???  ANIM???  ANIM???  ANIM???

			Now, both these ideas will allow for storage of animations. The former would
			allow for unlimited loop lengths, albeit a necessary integer must be sent to
			the caller. The former also works and removes the necessity to send any
			information as to where the end of the loop is. However, considering someone
			wants to expand the engine to animations with more than four directional
			animation graphics (i.e. UP, DOWN, LEFT, RIGHT) they will need to add
			a quick STL call to count the length of the bucket, then the depth:

			          BREADTH
			--------------------------. D
			1, 2, 3, 4 // 5, 6, 7, 8  | E
			1a 2a 3a 4a   5a 6a 7a 8a | P
			1b 2b 3b 4b   5b 6b 7b 8b | T
			.  .  .  .    .  .  .  .  | H
			.  .  .  .    .  .  .  .  v
			.  .  .  .    .  .  .  .

				Again, this could be added to the main functioning of Virtu to allow for
			arbitrary directional sprites, and their loops. This shall definitely add
			easier graphic upgrades...
			
		* * Do note that Virtu can currently accept only BITMAPS, CMP, or other * *
			*	SPRITES via the DATAFILE functionality of Allegro Graphic Library.
			*	However, because it will be further possible to extend Allegro once
			*	my Animation program is completed. It will therefore extend Allegro
			*	perhaps to a allow a format that will remove the necessity for keeping
			*	track of directions for each animation, or it may further NECESSITATE
			*	the use of these constructs.
			*	
			*	I am thinking of adding the ability to pull in FLI files and convert
			*	them into animations handleable by Virtu.
			\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\


/////////////////////////////////////////////////////////////////////////////
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/////////////////////////////////////////////////////////////////////////////
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Virtu, TODO, and documentation project : By Eric Nakagawa