Document syntax according to RFC2119: http://tools.ietf.org/html/rfc2119



Library Name: tri -> Tomaz, Raphael, IWN

NAMING CONVENTIONS:


Placeholders in the naming convention (legend):
lib			> name of the library, all lowercase
Section		> name of the current Section/Object code block, first letter uppercase
Name		> name of the function/variable/struct/define, first letter uppercase
name		> " but all lowercase
NAME		> " but all uppercase
Identifier  > subname of a variable (e.g. redChannel - red = name, Channel = Identifier)
              can be used repeatedly after a name (e.g. redColorChannel)


These naming conventions are MUSTS:
filenames		:  libSection.ext
functions		:  libSectionName()
variables		:  libName
structs			:  libName
struct elements	:  nameIdentifier
parameters		:  nameIdentifier
defines			:  LIBNAME



Header double inclusion defines MUST be named like __FILENAME_H__.
Headers SHOULD be commented with doxygen compatible comments.
Doxygen comments for struct elements MUST be placed on the same line, e.g:
/**
 * Color struct
 */
struct triColor {
	float	red;	/**< The red color channel */
	float	green;	/**< The green color channel */
	float	blue;	/**< The blue color channel */
};



Indenting MUST be done with one tab per indentation level. Convert 4 spaces to tab.
Opening/closing brackets MUST be placed on seperate lines. They MUST NOT be indented from the
keyword they belong to.

Examples:

for/while/if (condition)
{
	code
}
else
{
	code
}


type function( args )
{
	code
}


ONLY EXCEPTION FROM RULE FOR ENDING BRACKETS ON SEPERATE LINE:
[typedef] struct name
{
	code
} variable(s);




Function parameters SHOULD be indented with one whitespace, e.g.:
type function( arg1, arg2, arg3, etc. );



Functions SHOULD return function results when possible, instead of changing parameters given by reference (pointer - we're in C).
Functions that are supposed to return success values, are freed from that rule (unless the error code can be encoded with the return value).

Examples:

// Calculate cross product of vsrc and vtmp and store it in vdst, return pointer to vdst
triVec3f* triVec3Cross( triVec3f* vdst, const triVec3f* vsrc, const triVec3f* vtmp );

triFloat  triVec3Dot( const triVec3f* vsrc, const triVec3f* vdst );

// Create numLevel mipmaps and attach them to tex, return true/false for success
triBool   triBuildMipMaps( triTexture* tex, triSInt numLevels );

BUT

// Load texture from fileName and return pointer to texture -> 0 on failure
triTexture* triLoadTexture( const char* fileName, triSInt loadAlpha );





COMMON TYPES:
These types SHOULD be used wherever possible. Redefinitions of these types MAY NOT be done unless decided
by the group. Use the language specific integral types (char, short, int, long, etc.) instead if you need
to differentiate to these common types.


typedef triChar /*signed*/ char;
typedef triUChar unsigned char;
typedef triSInt	signed int;	// sizeof(int) is platform specific, so we might want to have that for optimal code parts
typedef triUInt	unsigned int;

typedef triS32	signed long;
typedef triU32	unsigned long;
typedef triS16	signed short;
typedef triU16	unsigned short;
typedef triS8	signed char;
typedef triU8	unsigned char;
typedef triBool unsigned char;
typedef triFloat float;
#ifndef __PSP__
typedef triDouble double;
#else
typedef triDouble float;
#endif


typedef struct triVec3
{
	triFloat	x, y, z;
} triVec3, triVec3f; // Untyped vectors are always supposed to be float types


// Sizes should be the same, hence S32 instead of platform specific SInt
typedef struct triVec3i
{
	triS32		x, y, z;
} triVec3i;



typedef struct triVec4
{
	triFloat	x, y, z, w;
} triVec4, triVec4f;


// Sizes should be the same, hence S32 instead of platform specific SInt
typedef struct triVec4i
{
	triS32		x, y, z, w;
} triVec4i;