MinGW is no longer officially supported.

Documentation update.

CMakeLists.txt

@@ -42,10 +42,6 @@ if (MSVC)
     set (CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELWITHDEBINFO} /GL")
     set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO "${CMAKE_EXE_LINKER_FLAGS_RELEASE} /OPT:REF /OPT:ICF /DEBUG")
     set (CMAKE_EXE_LINKER_FLAGS_RELEASE "${CMAKE_EXE_LINKER_FLAGS_RELEASE} /OPT:REF /OPT:ICF /LTCG")
-elseif (MINGW)
-    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-invalid-offsetof")
-    set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static-libstdc++ -static-libgcc")
-    set (EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/Bin)
 else ()
     set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32")
     set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-invalid-offsetof -m32")

Docs/GettingStarted.dox

@@ -2,11 +2,11 @@
 
 \page Building Building Urho3D
 
-Urho3D uses cmake (http://www.cmake.org) to build. The process has two steps:
+Urho3D uses CMake (http://www.cmake.org) to build. The process has two steps:
 
-1) Run cmake in the root directory with your preferred toolchain specified to generate the build files. You can use the batch files or shell scripts provided. Use cmake_vs2008.bat, cmake_vs2010.bat or cmake_mingw.bat on Windows, and cmake_gcc.sh on Linux and Mac OS X.
+1) Run CMake in the root directory with your preferred toolchain specified to generate the build files. You can use the batch files or shell scripts provided: cmake_vs2008.bat or cmake_vs2010.bat on Windows, and cmake_gcc.sh on Linux and Mac OS X.
 
-2) For Visual Studio, open Urho3D.sln and build the configuration(s) you like. For gcc, execute make (by default, cmake_mingw.bat or cmake_gcc.sh specify to make a Release build.)
+2) For Visual Studio, open Urho3D.sln and build the configuration(s) you like. For gcc, execute make (by default, cmake_gcc.sh specifies to make a Release build.)
 
 The build process will also compile models and shaders from the Source_Asset directory into Bin/Data/Models & Bin/Data/Shaders. After the build is complete, the programs can be run from the Bin directory.
 
@@ -124,13 +124,13 @@ The libraries are the following:
 - %Scene. Provides Node and Component classes, from which Urho3D scenes are built.
 - %Graphics. Provides application window handling and 3D rendering capabilities.
 - %Input. Provides mouse & keyboard input in both polled and event-based mode.
-- %Network. Provides low-level client-server networking functionality.
+- %Network. Provides client-server networking functionality.
 - %Audio. Provides the audio subsystem and playback of .wav & .ogg sounds in either 2D or 3D.
 - Physics. Provides physics simulation.
 - %Script. Provides scripting support using the AngelScript language.
 - %Engine. Instantiates the subsystems from the libraries above, and manages the main loop iteration.
 
-Urho3D.exe uses just the Engine & Script libraries to start up the subsystems and to load the script file specified on the command line; however due to the cmake build process all the libraries above get automatically linked (as Engine library depends on all of them.)
+Urho3D.exe uses just the Engine & Script libraries to start up the subsystems and to load the script file specified on the command line; however due to the CMake build process all the libraries above get automatically linked (as Engine library depends on all of them.)
 
 Although Urho3D.exe itself is geared towards running a scripted application, it is also possible to use the engine through C++ only. When the script subsystem initialization is completely skipped, the resulting executable will also be significantly smaller.
 
@@ -322,7 +322,7 @@ target_link_libraries (${TARGET_NAME} Container Core Engine Graphics Input IO Ma
 finalize_exe ()
 \endcode
 
-Before recreating the build files with cmake, create an empty HelloWorld.cpp into the HelloWorld directory. Now you can re-run cmake. If using Visual Studio, the HelloWorld project should now appear in the Urho3D solution, and you can start writing the actual application into HelloWorld.cpp.
+Before recreating the build files with CMake, create an empty HelloWorld.cpp into the HelloWorld directory. Now you can re-run CMake. If using Visual Studio, the HelloWorld project should now appear in the Urho3D solution, and you can start writing the actual application into HelloWorld.cpp.
 
 To start with, we need the include files for all the engine classes we are going to use, plus Windows.h for the WinMain function:
 

Docs/Reference.dox

@@ -968,7 +968,7 @@ Left, top, right & bottom border widths and spacing between elements can also be
 
 \page Serialization Serialization
 
-Classes that derive from Serializable can perform automatic serialization to binary or XML format by defining \ref AttributeInfo "Attributes". Attributes are stored to the Context per class. %Scene load/save and network replication are both implemented by Node and Component deriving from Serializable.
+Classes that derive from Serializable can perform automatic serialization to binary or XML format by defining \ref AttributeInfo "attributes". Attributes are stored to the Context per class. %Scene load/save and network replication are both implemented by Node and Component deriving from Serializable.
 
 The supported attribute types are all those supported by Variant. Attributes can either define a direct memory offset into the object, or setter & getter functions. Zero-based enumerations are also supported, so that the enum values can be stored as text into XML files instead of just numbers. For editing, the attributes also have human-readable names.
 
@@ -1015,19 +1015,19 @@ There are some things to watch out for:
 
 - After connecting to a server, the client should not create, update or remove non-local nodes or components on its own. However, to create client-side special effects and such, the client can freely manipulate local nodes.
 
-- A Node's \ref Node::GetVars "user variables" VariantMap will be automatically replicated on a per-variable basis. This can be useful in transmitting data shared by several components, for example the player's score or health.
+- A node's \ref Node::GetVars "user variables" VariantMap will be automatically replicated on a per-variable basis. This can be useful in transmitting data shared by several components, for example the player's score or health.
 
 - To implement interpolation, exponential smoothing of the nodes' rendering transforms is enabled on the client. It can be controlled by two properties of the Scene, the smoothing constant and the snap threshold. Snap threshold is the distance between network updates which, if exceeded, causes the node to immediately snap to the end position, instead of moving smoothly. See \ref Scene::SetSmoothingConstant "SetSmoothingConstant()" and \ref Scene::SetSnapThreshold "SetSnapThreshold()".
 
-- Position and rotation are Node attributes, while linear and angular velocities are RigidBody attributes. To cut down on the needed network bandwidth the physics components can be created as local on the server: in this case the client will not see them at all, and will only interpolate motion based on the Node's transform changes. Replicating the actual physics components allows the client to extrapolate using its own physics simulation, and to also perform collision detection, though always non-authoritatively.
+- Position and rotation are Node attributes, while linear and angular velocities are RigidBody attributes. To cut down on the needed network bandwidth the physics components can be created as local on the server: in this case the client will not see them at all, and will only interpolate motion based on the node's transform changes. Replicating the actual physics components allows the client to extrapolate using its own physics simulation, and to also perform collision detection, though always non-authoritatively.
 
 - AnimatedModel does not replicate animation by itself. Rather, AnimationController will replicate its command state (such as "fade this animation in, play that animation at 1.5x speed.") To turn off animation replication, create the AnimationController as local. To ensure that also the first animation update will be received correctly, always create the AnimatedModel component first, then the AnimationController.
 
 - Networked attributes can either be in delta update or latest data mode. Delta updates are small incremental changes and must be applied in order, which may cause increased latency if there is a stall in network message delivery eg. due to packet loss. High volume data such as position, rotation and velocities are transmitted as latest data, which does not need ordering, instead this mode simply discards any old data received out of order. Note that node and component creation (when initial attributes need to be sent) and removal can also be considered as delta updates and are therefore applied in order.
 
-- The server code orders replication update messages so that parent nodes are created and updated before their children. Remote events are queued and only sent after the replication update to ensure that if they target a newly created node, it will already exist on the receiving end. However, it is also possible to specify unordered transmission for a remote event, in which case that guarantee does not hold.
+- The server update logic orders replication messages so that parent nodes are created and updated before their children. Remote events are queued and only sent after the replication update to ensure that if they target a newly created node, it will already exist on the receiving end. However, it is also possible to specify unordered transmission for a remote event, in which case that guarantee does not hold.
 
-- The \ref Node::SetOwner "owner property" of a node can be set in server code to specify the owning Connection (for example, the player that is controlling a specific game object.) This property is not replicated to the client. Messages or remote events can be used instead to tell the players what object they control.
+- Nodes have the concept of the \ref Node::SetOwner "owner connection" (for example the player that is controlling a specific game object), which can be set in server code. This property is not replicated to the client. Messages or remote events can be used instead to tell the players what object they control.
 
 - At least for now, there is no built-in client-side prediction.
 
@@ -1035,13 +1035,13 @@ There are some things to watch out for:
 
 %Scene replication includes a simple, distance-based interest management mechanism for reducing bandwidth use.
 
-For each Node the following values can be configured: \ref Node::SetPriority "Priority", \ref Node::SetPriorityDistanceFactor "Priority Distance Factor", and \ref Node::SetMinPriority "Minimum Priority".
+For each Node the following parameters can be set: \ref Node::SetPriority "priority", \ref Node::SetPriorityDistanceFactor "priority distance factor", and \ref Node::SetMinPriority "minimum priority".
 
-During each server update, a current priority value is calculated as Priority - Priority Distance Factor * Distance. Additionally, it can never go lower than the minimum priority. This value is then added to an update accumulator. Whenever the update accumulator reaches 100.0, the attribute changes to the node and its components are sent, and the accumulator is reset.
+During each server update, a current priority value is calculated as "priority - priority distance factor * distance." Additionally, it can never go lower than the minimum priority. This value is then added to an update accumulator. Whenever the update accumulator reaches 100.0, the attribute changes to the node and its components are sent, and the accumulator is reset.
 
-The default values are Priority 100.0, Priority Distance Factor 0.0, and Minimum Priority 0.0, which means that by default, an update is always sent. Additionally, there is a rule that if the node's owner connection is set, the owner always receives updates at full frequency.
+The default values are priority 100.0, priority distance factor 0.0, and minimum priority 0.0. This means that by default an update is always sent. Additionally, there is a rule that if the node's owner connection is set, the owner always receives updates at full frequency. Note that like the owner connection, the interest management parameters are not replicated to the client.
 
-Knowing the distance requires the client telling its current observer position (typically, either the camera's or the player character's world position.) This is accomplished by the client code calling \ref Connection::SetPosition "SetPosition()" on the server connection.
+Calculating the distance requires the client to tell its current observer position (typically, either the camera's or the player character's world position.) This is accomplished by the client code calling \ref Connection::SetPosition "SetPosition()" on the server connection.
 
 For now, creation and removal of nodes is always sent immediately, without consulting the interest management system. This is based on the assumption that nodes' motion updates consume the most bandwidth.
 

Engine/Core/MiniDump.cpp

@@ -32,9 +32,9 @@
 #include <io.h>
 #include <fcntl.h>
 #include <time.h>
-#include <Windows.h>
-#include <DbgHelp.h>
-#include <ShlObj.h>
+#include <windows.h>
+#include <dbghelp.h>
+#include <shlObj.h>
 
 static bool miniDumpWritten = false;
 

Engine/Core/Mutex.cpp

@@ -25,7 +25,7 @@
 #include "Mutex.h"
 
 #ifdef WIN32
-#include <Windows.h>
+#include <windows.h>
 #else
 #include <pthread.h>
 #endif

Engine/Core/ProcessUtils.cpp

@@ -30,7 +30,7 @@
 #include <fcntl.h>
 
 #ifdef WIN32
-#include <Windows.h>
+#include <windows.h>
 #include <io.h>
 #else
 #include <unistd.h>

Engine/Core/Thread.cpp

@@ -25,7 +25,7 @@
 #include "Thread.h"
 
 #ifdef WIN32
-#include <Windows.h>
+#include <windows.h>
 #else
 #include <pthread.h>
 #endif

Engine/Core/Timer.cpp

@@ -26,8 +26,8 @@
 #include "Timer.h"
 
 #ifdef WIN32
-#include <Windows.h>
-#include <MMSystem.h>
+#include <windows.h>
+#include <mmsystem.h>
 #else
 #include <sys/time.h>
 #include <unistd.h>

Engine/Graphics/Direct3D9/D3D9GraphicsImpl.h

@@ -25,7 +25,7 @@
 
 #include "Color.h"
 
-#include <Windows.h>
+#include <windows.h>
 #include <d3d9.h>
 
 /// Graphics implementation. Contains the main Direct3D9 objects

Engine/IO/FileSystem.cpp

@@ -32,15 +32,11 @@
 #include <cstring>
 
 #ifdef WIN32
-#include <Windows.h>
-#include <Shellapi.h>
+#include <windows.h>
+#include <shellapi.h>
 #include <direct.h>
 #include <process.h>
-// Enable SHGetSpecialFolderPath on MinGW
-#ifndef _MSC_VER
-#define WIN32_IE 0x0400
-#endif
-#include <Shlobj.h>
+#include <shlobj.h>
 #else
 #include <dirent.h>
 #include <errno.h>

Engine/Input/Input.cpp

@@ -32,7 +32,7 @@
 #include <cstring>
 
 #ifndef USE_OPENGL
-#include <Windows.h>
+#include <windows.h>
 #else
 #include <GraphicsImpl.h>
 #endif

Engine/Network/Connection.h

@@ -76,7 +76,7 @@ struct PackageDownload
     bool initiated_;
 };
 
-/// Connection in a networked scene
+/// Connection to a remote network host
 class Connection : public Object
 {
     OBJECT(Connection);
@@ -228,7 +228,7 @@ private:
     Timer statsTimer_;
     /// Update frame number
     unsigned frameNumber_;
-    /// Client flag
+    /// Client connection flag
     bool isClient_;
     /// Connection pending flag
     bool connectPending_;

Engine/Network/Controls.cpp

@@ -24,6 +24,8 @@
 #include "Precompiled.h"
 #include "Controls.h"
 
+#include "DebugNew.h"
+
 Controls::Controls()
 {
     Reset();

Engine/Network/Network.h

@@ -33,7 +33,7 @@
 class MemoryBuffer;
 class Scene;
 
-/// Network subsystem. Manages joining to or hosting networked scenes.
+/// Network subsystem. Manages client-server communications using the UDP protocol
 class Network : public Object, public kNet::IMessageHandler, public kNet::INetworkServerListener
 {
     OBJECT(Network);
@@ -67,7 +67,7 @@ public:
     void BroadcastMessage(int msgID, bool reliable, bool inOrder, const unsigned char* data, unsigned numBytes, unsigned priority = 0, unsigned contentID = 0);
     /// Broadcast a remote event to all client connections
     void BroadcastRemoteEvent(StringHash eventType, bool inOrder, const VariantMap& eventData = VariantMap());
-    /// Broadcast a remote event to all client connections in the specific scene
+    /// Broadcast a remote event to all client connections in a specific scene
     void BroadcastRemoteEvent(Scene* scene, StringHash eventType, bool inOrder, const VariantMap& eventData = VariantMap());
     /// Broadcast a remote node event to all client connections in the scene with this node
     void BroadcastRemoteEvent(Node* receiver, StringHash eventType, bool inOrder, const VariantMap& eventData = VariantMap());

Engine/Scene/Component.h

@@ -26,7 +26,7 @@
 #include "Matrix3x4.h"
 #include "Node.h"
 
-/// Base class for components. Components can be added to scene nodes
+/// Base class for components. Components can be created to scene nodes
 class Component : public Serializable
 {
     OBJECT(Component);

Readme.txt

@@ -73,16 +73,16 @@ Get Doxygen from http://www.doxygen.org
 Building
 --------
 
-Urho3D uses cmake (http://www.cmake.org) to build. The process has two steps:
+Urho3D uses CMake (http://www.cmake.org) to build. The process has two steps:
 
-1) Run cmake in the root directory with your preferred toolchain specified to
-generate the build files. You can use the batch files or shell scripts provided.
-Use cmake_vs2008.bat, cmake_vs2010.bat or cmake_mingw.bat on Windows, and
-cmake_gcc.sh on Linux and Mac OS X.
+1) Run CMake in the root directory with your preferred toolchain specified to
+generate the build files. You can use the batch files or shell scripts provided:
+cmake_vs2008.bat or cmake_vs2010.bat on Windows, and cmake_gcc.sh on Linux and 
+Mac OS X.
 
 2) For Visual Studio, open Urho3D.sln and build the configuration(s) you like.
-For gcc, execute make (by default, cmake_mingw.bat or cmake_gcc.sh specify to 
-make a Release build.)
+For gcc, execute make (by default, cmake_gcc.sh specifies to make a Release 
+build.)
 
 The build process will also compile models and shaders from the Source_Asset
 directory into Bin/Data/Models & Bin/Data/Shaders. On Windows & Direct3D9,

ThirdParty/kNet/src/win32/W32Clock.cpp

@@ -23,7 +23,7 @@
 #include "kNet/NetworkLogging.h"
 
 #define NOMINMAX
-#include <windows.h>
+#include <Windows.h>
 
 namespace kNet
 {

Tools/ShaderCompiler/ShaderCompiler.cpp

@@ -34,7 +34,7 @@
 #include <cstdio>
 #include <cstring>
 
-#include <Windows.h>
+#include <windows.h>
 #include <d3d9.h>
 #include <d3dx9shader.h>
 

Urho3D/Urho3D.cpp

@@ -33,7 +33,7 @@
 #include <stdexcept>
 
 #ifdef WIN32
-#include <Windows.h>
+#include <windows.h>
 #endif
 
 #include "DebugNew.h"

cmake_mingw.bat

@@ -1 +0,0 @@
-cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release