TODO

BEFORE 1.0 * get it to build on all platforms, again ;) ( linux i386, linux amd64, win32, win64, xenon, ps3 )) * linux x86 has alignment 4 on double, dl do not support it. FIX!

* write readme and tutorials.

LATER
c-library:
	* EDLType should not need to be exposed by the lib in the way it is now!
	* more platforms
	* multi-dimensional arrays.
	* add functionallity to stream txt_pack and unpack
	* dimensions to array and inline_array.
	* support signed bitfields
	* unicode-strings!
	* SIMD-byteswap of arrays?
	* could one use a concept close to a xor-linked-list to not need traversal of entire struct when patching pointers? would this work with convert
	  functions? 
	* Better type:ids, right now type-ids are calculated as name-hash but they sholud be calculated by member types and name to be 
	  able to determine that they do not match.
  
	  example:
		  MyStructVer1 { uint32 m_Int32; }
		  MyStructVer1 { uint32 m_Int32; uint32 m_Int32_2; }
	  
	  or typeid:s could be generated as 16-24 bits typelib:id, 8-16 bits enumeration of type in typelib. Would give faster type-lookups.
	  ( find typelib, direct indexing )
	  On could also add information in typeid as one byte if the type has sub-arrays for optimized packing!
  
	  // these are not the same type any more, or are they?
	* Question: is it viable to get it to compile with -pedantic for gcc?
	* text-packing/binary-writer-code is messy. I do not like =/

dl_tlc:
	* pure c-headers generated as option? ( remove c++ extras ) --cpp or -c to dl_tlc
	* figure out if typelibrary-class in python should store bitfield as bitfield-group?
	* add decompile-option for typelib-description files bin -> json
	* .tld file format change!
		members are a list right now to be able to controll order of parameters.

		this should be replaced with a map and the potential index-parameter if controll of order is needed.

		old:
			"MorePods" : { 
				"members" : [ 
					{ "name" : "Pods1", "type" : "Pods"  },  
					{ "name" : "Pods2", "type" : "Pods" } 
				]
			}

		new:
			"MorePods" : { 
				"members" : { 
					"Pods1" : { "type" : "Pods" },  
					"Pods2" : { "type" : "Pods" } 
				}
			}

		if only type is set a shorthand form can be used:
			"MorePods" : { 
				"members" : { 
					"Pods1" : "Pods",
					"Pods2" : "Pods"
				}
			}

		if order of parameters in generated structs is required, for example a vector3 where one might want x,y,z in that order
		one can use the index parameter. Dl will sort members first on index, then on alignment, then on type, lastly on name. 
		Default-index if not set is uint32-max or configurable?
		( this might be a bad example since they are sorted by name, but it gets the idea across )
		Index might also be used to group members together by setting index to the same for different members.

			"vec3" : { 
				"members" : { 
					"x" : { "type" : "fp32", "index" : 0 },
					"y" : { "type" : "fp32", "index" : 1 },
					"z" : { "type" : "fp32", "index" : 2 }
				}
			}


bindings:
	* get pointers to work in python-bindings again.
	* break out C#-bindings and python-bindings to their own library?

tests:
	* harder unittests for subarrays.
	* unittests for C#-bindings.
	* create some benchmarks that measure pack/unpack speed. 
	* unittest that are cross platform 
	    - pack on 32 bit -> unpack on 64 bit should be possible localy
	    - pack on little endian -> unpack on big endian is harder. Do via network?

EVEN LATER
* bindings for other languages?