Fix typos. Thanks @ greenya

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5822 dfc29bdd-3216-0410-991c-e03cc46cb475

include/EDeviceTypes.h

@@ -31,7 +31,7 @@ namespace irr
 
 		//! A device which uses Simple DirectMedia Layer
 		/** The SDL device works under all platforms supported by SDL but first must be compiled
-		in by defining the IRR_USE_SDL_DEVICE macro in IrrCompileConfig.h */
+		in by defining the _IRR_COMPILE_WITH_SDL_DEVICE_ macro in IrrCompileConfig.h */
 		EIDT_SDL,
 
 		//! A device for raw framebuffer access

include/EDriverFeatures.h

@@ -16,7 +16,7 @@ namespace video
 		//! Is driver able to render to a surface?
 		EVDF_RENDER_TO_TARGET = 0,
 
-		//! Is hardeware transform and lighting supported?
+		//! Is hardware transform and lighting supported?
 		EVDF_HARDWARE_TL,
 
 		//! Are multiple textures per material possible?

include/EMaterialTypes.h

@@ -54,7 +54,7 @@ namespace video
 		//! Like EMT_LIGHTMAP_M2, but also supports dynamic lighting.
 		EMT_LIGHTMAP_LIGHTING_M2,
 
-		//! Like EMT_LIGHTMAP_4, but also supports dynamic lighting.
+		//! Like EMT_LIGHTMAP_M4, but also supports dynamic lighting.
 		EMT_LIGHTMAP_LIGHTING_M4,
 
 		//! Detail mapped material.

include/IMesh.h

@@ -56,7 +56,7 @@ namespace scene
 		//! generic skinned mesh
 		EAMT_SKINNED,
 
-		//! generig non-animated mesh
+		//! generic non-animated mesh
 		EAMT_STATIC
 	};
 

include/ISceneManager.h

@@ -71,12 +71,12 @@ namespace scene
 		/** This value will never be returned by
 		ISceneManager::getSceneNodeRenderPass(). The scene manager
 		will determine by itself if an object is transparent or solid
-		and register the object as SNRT_TRANSPARENT or SNRT_SOLD
+		and register the object as ESNRT_TRANSPARENT or ESNRP_SOLID
 		automatically if you call registerNodeForRendering with this
 		value (which is default). Note that it will register the node
 		only as ONE type. If your scene node has both solid and
 		transparent material types register it twice (one time as
-		SNRT_SOLID, the other time as SNRT_TRANSPARENT) and in the
+		ESNRP_SOLID, the other time as ESNRT_TRANSPARENT) and in the
 		render() method call getSceneNodeRenderPass() to find out the
 		current render pass and render only the corresponding parts of
 		the node. */
@@ -1085,7 +1085,7 @@ namespace scene
 		/** \param type: Type of scene node to find (ESNT_ANY will return all child nodes).
 		\param outNodes: results will be added to this array (outNodes is not cleared).
 		\param start: Scene node to start from. This node and all children of this scene
-		node are checked (recursively, so also children of children, etc). If null is specified, 
+		node are checked (recursively, so also children of children, etc). If null is specified,
 		the root scene node is taken as start-node. */
 		virtual void getSceneNodesFromType(ESCENE_NODE_TYPE type,
 				core::array<scene::ISceneNode*>& outNodes,

include/SMaterial.h

@@ -199,7 +199,7 @@ namespace video
 		//! All typical anti-alias and smooth modes
 		EAAM_FULL_BASIC=15,
 		//! Enhanced anti-aliasing for transparent materials
-		/** Usually used with EMT_TRANSPARENT_ALPHA_REF and multisampling. */
+		/** Usually used with EMT_TRANSPARENT_ALPHA_CHANNEL_REF and multisampling. */
 		EAAM_ALPHA_TO_COVERAGE=16
 	};
 
@@ -266,13 +266,13 @@ namespace video
 
 	//! By default this is identical to MATERIAL_MAX_TEXTURES
 	/** Users can modify this value if they are certain they don't need all
-		available textures per material in their application. For example if you 
+		available textures per material in their application. For example if you
 		never need more than 2 textures per material you can set this to 2.
 
-		We (mostly) avoid dynamic memory in SMaterial, so the extra memory 
-		will still be allocated. But by lowering MATERIAL_MAX_TEXTURES_USED the 
-		material comparisons and assignments can be faster. Also several other 
-		places in the engine can be faster when reducing this value to the limit 
+		We (mostly) avoid dynamic memory in SMaterial, so the extra memory
+		will still be allocated. But by lowering MATERIAL_MAX_TEXTURES_USED the
+		material comparisons and assignments can be faster. Also several other
+		places in the engine can be faster when reducing this value to the limit
 		you need.
 
 		NOTE: This should only be changed once and before any call to createDevice.
@@ -470,7 +470,7 @@ namespace video
 		Note: This probably never worked on Direct3D9 (was coded for D3D8 which had different value ranges)	*/
 		u8 PolygonOffsetFactor:3;
 
-		//! DEPRECATED. Will be removed after Irrlicht 1.9. 
+		//! DEPRECATED. Will be removed after Irrlicht 1.9.
 		/** Flag defining the direction the polygon offset is applied to.
 		Can be to front or to back, specified by values from E_POLYGON_OFFSET. 	*/
 		E_POLYGON_OFFSET PolygonOffsetDirection:1;
@@ -480,7 +480,7 @@ namespace video
 		On OpenGL you get units which are multiplied by the smallest value that is guaranteed to produce a resolvable offset.
 		On D3D9 you can pass a range between -1 and 1. But you should likely divide it by the range of the depthbuffer.
 		Like dividing by 65535.0 for a 16 bit depthbuffer. Thought it still might produce too large of a bias.
-		Some article (https://aras-p.info/blog/2008/06/12/depth-bias-and-the-power-of-deceiving-yourself/) 
+		Some article (https://aras-p.info/blog/2008/06/12/depth-bias-and-the-power-of-deceiving-yourself/)
 		recommends multiplying by 2.0*4.8e-7 (and strangely on both 16 bit and 24 bit).	*/
 		f32 PolygonOffsetDepthBias;