Fixed deserialization issue when deserializing/serializing between release and debug mode

Fixed DX9 shader issue
WIP working on enabling OpenGL debug context

BansheeEditor/Include/BsProjectLibraryEntriesRTTI.h

@@ -169,7 +169,7 @@ namespace BansheeEngine
 		{ 
 			UINT64 dataSize = sizeof(UINT32) + rttiGetElemSize(data.type) + rttiGetElemSize(data.path) + rttiGetElemSize(data.elementName);
 
-			dataSize += rttiGetElemSize((UINT32)data.mChildren.size());
+			dataSize += sizeof(UINT32);
 
 			for(auto& child : data.mChildren)
 			{

BansheeEditorExec/BsEditorExec.cpp

@@ -12,7 +12,7 @@ int CALLBACK WinMain(
 	_In_  int nCmdShow
 	)
 {
-	EditorApplication::startUp(cm_new<EditorApplication>(RenderSystemPlugin::DX11));
+	EditorApplication::startUp(cm_new<EditorApplication>(RenderSystemPlugin::OpenGL));
 	EditorApplication::instance().runMainLoop();
 	EditorApplication::shutDown();
 

BoostPort.txt

@@ -9,12 +9,9 @@
 cm_shared_ptr should use && for parameter forwarding?
 cm_core_ptr too
 
-
-Figure out how to properly deal with events and recursion. e.g. when slot is disconnected during an event callback
-
-There was a crash in release mode - Maybe this was due to the event error, mabye not. Test.
-
-Test DX9 and OpenGL
+When creating an OpenGL context I need to create the basic one, then initialize it (currently done in GLRenderSystem::initializeContext which I'll 
+need to move), and then destroy window/DC/context and recreate them using the attrib version. Check out win32_window.c in glwf from SB source 
+code for example parameters when creating one.
 
 
 Create a proper git repo of dependencies folder

CamelotD3D9Renderer/Source/CmD3D9HLSLProgram.cpp

@@ -203,7 +203,7 @@ namespace BansheeEngine {
 				"",// dummy source, since we'll be using microcode
 				"",
 				mType, 
-				GPP_NONE);
+				mProfile);
 			static_cast<D3D9GpuProgram*>(mAssemblerProgram.get())->setExternalMicrocode(mpMicroCode);
 
 			D3D9HLSLParamParser paramParser(constTable);

CamelotGLRenderer/Source/CmGLRenderSystem.cpp

@@ -1350,13 +1350,12 @@ namespace BansheeEngine
 			}            
 		}
 
-		// TODO - Replace with OpenGL 4.3 built-in functionality (GL_DEBUG_OUTPUT_SYNCHRONOUS)
 #if CM_DEBUG_MODE
-		//if (mGLSupport->checkExtension("GL_ARB_debug_output"))
-		//{
-		//	glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS_ARB);
-		//	glDebugMessageCallbackARB(&openGlErrorCallback, 0);
-		//}
+		if (mGLSupport->checkExtension("GL_debug_output"))
+		{
+			glDebugMessageCallback(&openGlErrorCallback, 0);
+			glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS);
+		}
 #endif
 	}
 	//---------------------------------------------------------------------

CamelotUtility/Source/CmBinarySerializer.cpp

@@ -509,7 +509,7 @@ namespace BansheeEngine
 
 			if(curGenericField != nullptr)
 			{
-				if(curGenericField->getTypeSize() != fieldSize)
+				if(!hasDynamicSize && curGenericField->getTypeSize() != fieldSize)
 				{
 					CM_EXCEPT(InternalErrorException, 
 						"Data type mismatch. Type size stored in file and actual type size don't match. (" 

CamelotUtility/Source/CmLog.cpp

@@ -1,6 +1,8 @@
 #include "CmLog.h"
 #include "CmException.h"
 
+void dbg_VSLog(const BansheeEngine::String& message);
+
 namespace BansheeEngine
 {
 	LogEntry::LogEntry(const String& msg, const String& level)
@@ -26,6 +28,8 @@ namespace BansheeEngine
 		LogEntry* newEntry = cm_new<LogEntry, PoolAlloc>(message, level);
 		mEntries.push_back(newEntry);
 
+		dbg_VSLog(message);
+
 		doOnEntryAdded(*newEntry);
 	}
 
@@ -49,4 +53,14 @@ namespace BansheeEngine
 	{
 		onEntryAdded(entry);
 	}
+}
+
+// TODO: Debug only - Remove later
+
+#include <windows.h>
+
+void dbg_VSLog(const BansheeEngine::String& message)
+{
+	OutputDebugString(message.c_str());
+	OutputDebugString("\n");
 }

TODODoc.txt

@@ -13,7 +13,7 @@
   - Texture limitations: Only 1D, 2D, 3D and Cube textures (and their samplers) are supported. Support for multisampled textures
      is included where necessary to implement render targets. Support for texture arrays and is not included.
  - Multiple inheritance is not supported on any class that is serialized with the help of RTTI. If you use it you can expect
-   very weird issues.
+   weird issues because of casting issues throughout the RTTI and serializer code.
  - If you're creating a hierarchy of classes with RTTI support, ALL classes in the hierarchy must have RTTI implementations. You cannot just leave
    some out, even if they contain no data. This would create incomplete RTTI class hierarchy which can cause various issues.
  - If you are manually constructing a class and it has an "initialize()" method, then you need to call it before using the class. Most object creation is wrapped
@@ -30,9 +30,8 @@
 	  In such class it is assumed all methods are internal and generally aren't meant for normal day to day use.
 	- "Core method" notation in method documentation. This means the method is only meant to be called from the core thread. Calling it from another thread
 	  will cause an exception at best, or cause unpredictable behaviour at worst.
+  - If using Visual Studio make sure you enable throwing of C++ exceptions. They are automatically disabled for me in VS2012 and VS2013 which results in nasty
+    issues as the exception gets reported as "First chance exception" and the code attempts to be run again. Banshee does not perform cleanup upon exception throw as exceptions
+	are used for fatal errors. This means you will end up with memory corruption or some other issue, while you could have gotten a clean exception explaining the problem.
 
 
-
-Classes to document:
- - ThreadPool
- - TaskScheduler