Massive namespace rename BansheeEngine -> bs

Documentation/Manuals/Native/User/scenesAndComponents.md

@@ -31,9 +31,9 @@ Scene objects are always referenced using the **HSceneObject** handle, while com
 You may treat the handles as pointers, using "->" to access their members, comparing them for equality or with *nullptr* to check their validity. 
 
 # Scene object creation and destruction {#b}
-We have already shown how to use @ref BansheeEngine::SceneObject::create "SceneObject::create" to create a new scene object. 
+We have already shown how to use @ref bs::SceneObject::create "SceneObject::create" to create a new scene object. 
 
-If you wish to destroy a scene object call @ref BansheeEngine::SceneObject::destroy "SceneObject::destroy". Note that destroying a scene object will destroy all of the components attached to it, as well as any child scene objects.
+If you wish to destroy a scene object call @ref bs::SceneObject::destroy "SceneObject::destroy". Note that destroying a scene object will destroy all of the components attached to it, as well as any child scene objects.
 
 ~~~~~~~~~~~~~{.cpp}
 // Create a scene object
@@ -44,7 +44,7 @@ so->destroy();
 ~~~~~~~~~~~~~
 
 # Transforming scene objects {#c}
-You can change scene object position, orientation and scale using @ref BansheeEngine::SceneObject::setPosition "SceneObject::setPosition", @ref BansheeEngine::SceneObject::setRotation "SceneObject::setRotation" and @ref BansheeEngine::SceneObject::setScale "SceneObject::setScale".
+You can change scene object position, orientation and scale using @ref bs::SceneObject::setPosition "SceneObject::setPosition", @ref bs::SceneObject::setRotation "SceneObject::setRotation" and @ref bs::SceneObject::setScale "SceneObject::setScale".
 
 Components attached to scene objects will reflect the scene object transform. For example, moving a scene object with a **Renderable** component will make the 3D meshes referenced by **Renderable** display in a different location in the scene.
 
@@ -61,12 +61,12 @@ so->setRotation(Quaternion(Degree(0), Degree(90), Degree(0)));
 so->setScale(Vector3(2.0f, 2.0f, 2.0f));
 ~~~~~~~~~~~~~
 
-> Extra: There also other useful methods when it comes to dealing with scene object positions and orientations, like @ref BansheeEngine::SceneObject::move "SceneObject::move", @ref BansheeEngine::SceneObject::lookAt "SceneObject::lookAt" or @ref BansheeEngine::SceneObject::getForward "SceneObject::getForward". See the @ref BansheeEngine::SceneObject "SceneObject" API reference for a full overview.
+> Extra: There also other useful methods when it comes to dealing with scene object positions and orientations, like @ref bs::SceneObject::move "SceneObject::move", @ref bs::SceneObject::lookAt "SceneObject::lookAt" or @ref bs::SceneObject::getForward "SceneObject::getForward". See the @ref bs::SceneObject "SceneObject" API reference for a full overview.
 
 # Scene object hierarchy {#d}
 As mentioned, scene objects can be arranged in a hierarchy. Hierarchies allow you to transform multiple scene objects at once, since any transforms applied to a parent will also be applied to a child.
 
-All newly created scene objects are parented to the scene root by default. Use @ref BansheeEngine::SceneObject::setParent "SceneObject::setParent" to change their parents.
+All newly created scene objects are parented to the scene root by default. Use @ref bs::SceneObject::setParent "SceneObject::setParent" to change their parents.
 
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject parent = SceneObject::create("Parent");
@@ -94,14 +94,14 @@ childB->setParent(parent);
 parent->setPosition(Vector3(30, 0, 0));
 ~~~~~~~~~~~~~
 
-> Extra: You may query for parent and children of a scene object using methods like @ref BansheeEngine::SceneObject::getParent "SceneObject::getParent", @ref BansheeEngine::SceneObject::getNumChildren "SceneObject::getNumChildren", @ref BansheeEngine::SceneObject::getChild "SceneObject::getChild" or @ref BansheeEngine::SceneObject::findChild "SceneObject::findChild". See the @ref BansheeEngine::SceneObject "SceneObject" API reference for a full overview.
+> Extra: You may query for parent and children of a scene object using methods like @ref bs::SceneObject::getParent "SceneObject::getParent", @ref bs::SceneObject::getNumChildren "SceneObject::getNumChildren", @ref bs::SceneObject::getChild "SceneObject::getChild" or @ref bs::SceneObject::findChild "SceneObject::findChild". See the @ref bs::SceneObject "SceneObject" API reference for a full overview.
 
 # Components {#e}
-You may add components to a scene object using the @ref BansheeEngine::SceneObject::addComponent<T, Args...> "SceneObject::addComponent<T>" method. 
+You may add components to a scene object using the @ref bs::SceneObject::addComponent<T, Args...> "SceneObject::addComponent<T>" method. 
 
-You may retrieve existing components by calling @ref BansheeEngine::SceneObject::getComponent<T> "SceneObject::getComponent<T>".
+You may retrieve existing components by calling @ref bs::SceneObject::getComponent<T> "SceneObject::getComponent<T>".
 
-Components can be removed by calling the @ref BansheeEngine::Component::destroy "Component::destroy" method on the component.
+Components can be removed by calling the @ref bs::Component::destroy "Component::destroy" method on the component.
 
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject so = SceneObject::create("My object");

Documentation/Manuals/Native/User/startingUp.md

@@ -1,7 +1,7 @@
 Startup and main loop					{#startup}
 ===============
 
-Banshee is started through the @ref BansheeEngine::Application "Application" interface. 
+Banshee is started through the @ref bs::Application "Application" interface. 
 
 ~~~~~~~~~~~~~{.cpp}
 // Start an application in windowed mode using 1280x720 resolution
@@ -17,15 +17,15 @@ Application::shutDown();
 ~~~~~~~~~~~~~
 
 # Start up
-@ref BansheeEngine::Application::startUp "Application::startUp" expects you to provide the resolution for the primary application window, its title and a couple of optional parameters.
+@ref bs::Application::startUp "Application::startUp" expects you to provide the resolution for the primary application window, its title and a couple of optional parameters.
 
-> Advanced: You can perform a more customized startup by filling out the @ref BansheeEngine::START_UP_DESC "START_UP_DESC" structure and passing it to **Application::startUp**.
+> Advanced: You can perform a more customized startup by filling out the @ref bs::START_UP_DESC "START_UP_DESC" structure and passing it to **Application::startUp**.
 
 # Main loop
-Following start-up we run the main game loop by calling @ref BansheeEngine::Application::runMainLoop "Application::runMainLoop". This is where your game runs, where every frame is updated and rendered.
+Following start-up we run the main game loop by calling @ref bs::Application::runMainLoop "Application::runMainLoop". This is where your game runs, where every frame is updated and rendered.
 
 # Shut down
-Finally, when the user decides to close the application and the main loop exits, we wish to clean up the application by calling @ref BansheeEngine::Application::shutDown "Application::shutDown".
+Finally, when the user decides to close the application and the main loop exits, we wish to clean up the application by calling @ref bs::Application::shutDown "Application::shutDown".
 
 # Scene setup
 You are expected to perform initial scene setup in-between the **Application::startUp** and **Application::runMainLoop**, as we will demonstrate later.

Documentation/Manuals/Native/architecture.md

@@ -28,15 +28,15 @@ Lower layers were designed to be more general purpose than higher layers. They p
 
 Going from the lowest to highest the layers are:
 ## BansheeUtility ##					
-This is the lowest layer of the engine. It is a collection of very decoupled and separate systems that are likely to be used throughout all of the higher layers. Essentially a collection of tools that are in no way tied into a larger whole. Most of the functionality isn't even game engine specific, like providing [file-system access](@ref BansheeEngine::FileSystem), [file path parsing](@ref BansheeEngine::Path), [events](@ref BansheeEngine::Event), [math library](@ref BansheeEngine::Math), [RTTI system](@ref BansheeEngine::RTTITypeBase), [threading primitives and managers](@ref BansheeEngine::ThreadPool), among various others.
+This is the lowest layer of the engine. It is a collection of very decoupled and separate systems that are likely to be used throughout all of the higher layers. Essentially a collection of tools that are in no way tied into a larger whole. Most of the functionality isn't even game engine specific, like providing [file-system access](@ref bs::FileSystem), [file path parsing](@ref bs::Path), [events](@ref bs::Event), [math library](@ref bs::Math), [RTTI system](@ref bs::RTTITypeBase), [threading primitives and managers](@ref bs::ThreadPool), among various others.
 
 See the [utilities](@ref utilities) manual for an overview of all the most important systems in this layer. 
 
 ## BansheeCore ##		
-This layer builds upon the utility layer by providing abstract interfaces for most of the engine systems. The interfaces themselves are implemented in the form of plugins, and are not part of the layer itself (for the most part). This layer glues all the engine's systems together and provides a foundation that the engine is built on. The layer tries to be generic and include only functionality that is common, while leaving more specialized functionality for higher layers. Some systems provided by this layer are @ref BansheeEngine::RenderAPI "render API wrapper", @ref BansheeEngine::Resources "resource management", @ref BansheeEngine::Importer "asset import", @ref BansheeEngine::Input "input", @ref BansheeEngine::Physics "physics" and more.
+This layer builds upon the utility layer by providing abstract interfaces for most of the engine systems. The interfaces themselves are implemented in the form of plugins, and are not part of the layer itself (for the most part). This layer glues all the engine's systems together and provides a foundation that the engine is built on. The layer tries to be generic and include only functionality that is common, while leaving more specialized functionality for higher layers. Some systems provided by this layer are @ref bs::RenderAPI "render API wrapper", @ref bs::Resources "resource management", @ref bs::Importer "asset import", @ref bs::Input "input", @ref bs::Physics "physics" and more.
 
 ## %BansheeEngine ##				
-This layer builds upon the abstraction provided by the core layer and provides actual implementations of the core layer interfaces. Since most of the interfaces are implemented as plugins this layer doesn't contain too much of its own code, but is rather in charge of linking everything together. Aside from linking plugins together it also contains some specialized code, like the @ref BansheeEngine::GUIManager "GUI" and @ref BansheeEngine::ScriptManager "script" managers, as well as various other functionality that was not considered generic enough to be included in the core layer.
+This layer builds upon the abstraction provided by the core layer and provides actual implementations of the core layer interfaces. Since most of the interfaces are implemented as plugins this layer doesn't contain too much of its own code, but is rather in charge of linking everything together. Aside from linking plugins together it also contains some specialized code, like the @ref bs::GUIManager "GUI" and @ref bs::ScriptManager "script" managers, as well as various other functionality that was not considered generic enough to be included in the core layer.
 
 ## BansheeEditor ##					
 And finally the top layer is the editor. It builts upon everything else so far and provides various editor specific features like the project library, build system, editor window management, scene view tools and similar. Large portions of the editor are implemented in the scripting code, and this layer provides more of a set of helper tools used by the scripting system. If you are going to work with this layer you will also be working closely with the scripting interop code and the scripting code (see below).
@@ -45,37 +45,37 @@ And finally the top layer is the editor. It builts upon everything else so far a
 Banshee provides a wide variety of plugins out of the box. The plugins are loaded dynamically and allow you to change engine functionality completely transparently to other systems (e.g. you can choose to load an OpenGL renderer instead of a DirectX one). Some plugins are completely optional and you can choose to ignore them (e.g. importer plugins can usually be ignored for game builds). Most importantly the plugins segregate the code, ensuring the design of the engine is decoupled and clean. Each plugin is based on an abstract interface implemented in one of the layers (for the most part, BansheeCore and %BansheeEngine layers).
 
 ## Render API ##								{#arch_rapi}		
-Render API plugins allow you to use a different backend for performing hardware accelerated rendering. @ref BansheeEngine::RenderAPI "RenderAPI" handles low level rendering, including features like vertex/index buffers, creating rasterizer/depth/blend states, shader programs, render targets, textures, draw calls and similar. See the [render API](@ref renderAPI) manual to learn more about it.
+Render API plugins allow you to use a different backend for performing hardware accelerated rendering. @ref bs::RenderAPI "RenderAPI" handles low level rendering, including features like vertex/index buffers, creating rasterizer/depth/blend states, shader programs, render targets, textures, draw calls and similar. See the [render API](@ref renderAPI) manual to learn more about it.
 
-The following plugins all have their own implementations of the @ref BansheeEngine::RenderAPI "RenderAPI" interface, as well as any related types (e.g. @ref BansheeEngine::VertexBuffer "VertexBuffer", @ref BansheeEngine::IndexBuffer "IndexBuffer"):
- - **BansheeD3D11RenderAPI** - Provides implementation of the @ref BansheeEngine::RenderAPI "RenderAPI" interface for DirectX 11. 
- - **BansheeD3D9RenderAPI**	- Provides implementation of the @ref BansheeEngine::RenderAPI "RenderAPI" interface for DirectX 9. 
- - **BansheeGLRenderAPI** - Provides implementation of the @ref BansheeEngine::RenderAPI "RenderAPI" interface for OpenGL 4.3.
+The following plugins all have their own implementations of the @ref bs::RenderAPI "RenderAPI" interface, as well as any related types (e.g. @ref bs::VertexBuffer "VertexBuffer", @ref bs::IndexBuffer "IndexBuffer"):
+ - **BansheeD3D11RenderAPI** - Provides implementation of the @ref bs::RenderAPI "RenderAPI" interface for DirectX 11. 
+ - **BansheeD3D9RenderAPI**	- Provides implementation of the @ref bs::RenderAPI "RenderAPI" interface for DirectX 9. 
+ - **BansheeGLRenderAPI** - Provides implementation of the @ref bs::RenderAPI "RenderAPI" interface for OpenGL 4.3.
 
 ## Importers ##									{#arch_importers}		
 Importers allow you to convert various types of files into formats easily readable by the engine. Normally importers are only used during development (e.g. in the editor), and the game itself will only use previously imported assets (although ultimately that's up to the user).
 
-All importers implement a relatively simple interface represented by the @ref BansheeEngine::SpecificImporter "SpecificImporter" class. The engine can start with zero importers, or with as many as you need. See the [importer](@ref customImporters) manual to learn more about importers and how to create your own. Some important importers are provided out of the box:
- - **BansheeFreeImgImporter** - Handles import of most popular image formats, like .png, .psd, .jpg, .bmp and similar. It uses the FreeImage library for reading the image files and converting them into engine's @ref BansheeEngine::Texture "Texture" format.
- - **BansheeFBXImporter** - Handles import of FBX mesh files. Uses Autodesk FBX SDK for reading the files and converting them into engine's @ref BansheeEngine::Mesh "Mesh" format.
- - **BansheeFontImporter** - Handles import of TTF and OTF font files. Uses FreeType for reading the font files and converting them into engine's @ref BansheeEngine::Font "Font" format.
- - **BansheeSL** - Provides an implementation of the Banshee's shader language that allows you to easily define an entire pipeline state in a single file. Imports .bsl files into engine's @ref BansheeEngine::Shader "Shader" format.
+All importers implement a relatively simple interface represented by the @ref bs::SpecificImporter "SpecificImporter" class. The engine can start with zero importers, or with as many as you need. See the [importer](@ref customImporters) manual to learn more about importers and how to create your own. Some important importers are provided out of the box:
+ - **BansheeFreeImgImporter** - Handles import of most popular image formats, like .png, .psd, .jpg, .bmp and similar. It uses the FreeImage library for reading the image files and converting them into engine's @ref bs::Texture "Texture" format.
+ - **BansheeFBXImporter** - Handles import of FBX mesh files. Uses Autodesk FBX SDK for reading the files and converting them into engine's @ref bs::Mesh "Mesh" format.
+ - **BansheeFontImporter** - Handles import of TTF and OTF font files. Uses FreeType for reading the font files and converting them into engine's @ref bs::Font "Font" format.
+ - **BansheeSL** - Provides an implementation of the Banshee's shader language that allows you to easily define an entire pipeline state in a single file. Imports .bsl files into engine's @ref bs::Shader "Shader" format.
 
 ## Others ##									{#arch_others}
 
 ### BansheeOISInput ###							{#arch_ois}
-Handles raw mouse/keyboard/gamepad input for multiple platforms. All input plugins implement the @ref BansheeEngine::RawInputHandler "RawInputHandler" interface. Uses the OIS library specifically modified for Banshee (source code available with Banshee's dependencies). 
+Handles raw mouse/keyboard/gamepad input for multiple platforms. All input plugins implement the @ref bs::RawInputHandler "RawInputHandler" interface. Uses the OIS library specifically modified for Banshee (source code available with Banshee's dependencies). 
 
-Be aware that there is also an @ref BansheeEngine::OSInputHandler "OSInputHandler" that is used for non-game specific purposes (e.g. tracking cursor, text input), but that is part of the engine core instead of a plugin.
+Be aware that there is also an @ref bs::OSInputHandler "OSInputHandler" that is used for non-game specific purposes (e.g. tracking cursor, text input), but that is part of the engine core instead of a plugin.
 
 ### BansheePhysX ###				
-Handles physics: rigidbodies, colliders, triggers, joints, character controller and similar. Implements the @ref BansheeEngine::Physics "Physics" interface and any related classes (e.g. @ref BansheeEngine::Rigidbody "Rigidbody", @ref BansheeEngine::Collider "Collider"). Uses NVIDIA PhysX as the backend.
+Handles physics: rigidbodies, colliders, triggers, joints, character controller and similar. Implements the @ref bs::Physics "Physics" interface and any related classes (e.g. @ref bs::Rigidbody "Rigidbody", @ref bs::Collider "Collider"). Uses NVIDIA PhysX as the backend.
 
 ### BansheeMono ###					
 Provides access to the C# scripting language using the Mono runtime. This allows the C++ code to call into C# code, and vice versa, as well as providing various meta-data about the managed code, and other functionality. All the script interop libraries (listed below) depend on this plugin. See the [scripting](@ref scripting) manual to learn more about this layer.
 
 ### RenderBeast ###					
-Banshee's default renderer. Implements the @ref BansheeEngine::Renderer "Renderer" interface. This plugin might seem similar to the render API plugins mentioned above but it is a higher level system. While render API plugins provide low level access to rendering functionality the renderer handles rendering of all scene objects in a specific manner without requiring the developer to issue draw calls manually. A specific set of options can be configured, both globally and per object that control how an object is rendered, as well as specifying completely custom materials. e.g. the renderer will handle physically based rendering, HDR, shadows, global illumination and similar features.
+Banshee's default renderer. Implements the @ref bs::Renderer "Renderer" interface. This plugin might seem similar to the render API plugins mentioned above but it is a higher level system. While render API plugins provide low level access to rendering functionality the renderer handles rendering of all scene objects in a specific manner without requiring the developer to issue draw calls manually. A specific set of options can be configured, both globally and per object that control how an object is rendered, as well as specifying completely custom materials. e.g. the renderer will handle physically based rendering, HDR, shadows, global illumination and similar features.
 
 See the [renderer](@ref renderer) manual to learn more about how the renderer works and how to implement your own.
 

Documentation/Manuals/Native/bslfx.md

@@ -85,7 +85,7 @@ On the top-most level the program consists out of three blocks:
  - Technique - Contains one or multiple passes that contain the pipeline state for rendering. This is the meat of the program.
 
 # Parameters {#bslfx_a}
-All parameters specified in this block will be exposed to the @ref BansheeEngine::Shader "Shader" object. These parameters will be accessible from the @ref BansheeEngine::Material "Material" object. You are still allowed to define uniforms/constants within shader code, without defining them in the parameter list, but they will not be visible to high level code. This can be useful if you are working on a lower level, like directly with the renderer.
+All parameters specified in this block will be exposed to the @ref bs::Shader "Shader" object. These parameters will be accessible from the @ref bs::Material "Material" object. You are still allowed to define uniforms/constants within shader code, without defining them in the parameter list, but they will not be visible to high level code. This can be useful if you are working on a lower level, like directly with the renderer.
 
 Types supported in this block are:
  - int - signed integer
@@ -155,7 +155,7 @@ Sampler2D gMySampler = { ... };
 Actual values in the sampler state will be explained later.
 
 Final element that parameters can have are modifiers. Modifiers are in the format of ": Modifier(Value)". Supported modifiers are:
- - auto - Accepts a string that contains a semantic name. For example: `mat4x4 gMatWorldViewProj : auto("WVP");`. If the semantic "WVP" is recognized by the active renderer this value will be automatically assigned by the renderer. Automatic values cannot be manually set through the @ref BansheeEngine::Material "Material" interface. The default renderer doesn't support any parameter semantics, it instead works using block semantics (see below).
+ - auto - Accepts a string that contains a semantic name. For example: `mat4x4 gMatWorldViewProj : auto("WVP");`. If the semantic "WVP" is recognized by the active renderer this value will be automatically assigned by the renderer. Automatic values cannot be manually set through the @ref bs::Material "Material" interface. The default renderer doesn't support any parameter semantics, it instead works using block semantics (see below).
  - alias - Accepts a string that contains an alternative name for the element. This can only be used for samplers, and is used for interfacing with render APIs that do not have separate objects for textures and samplers (e.g. OpenGL). You can use this to give your sampler the same name as the texture so such API will recognize it. For example:
 ~~~~~~~~~~~~~~
 Texture2D gMyTexture;
@@ -165,7 +165,7 @@ Sampler2D gMySampler : alias("gMyTexture"); // Ensures that render APIs that don
 # Blocks {#bslfx_b}
 Blocks are containers for parameters. In HLSL/GLSL they're usually called constant/uniform buffers. Actual layout of the blocks is therefore defined in their source language, and using the Block command we just make them available to the high level interface. The name of the block must be the same as the corresponding constant/uniform buffer.
 
-Parameters don't have to belong to a block but if they do you can share parameter blocks with multiple instances of @ref BansheeEngine::Material "Material", which is more efficient. Normally this is not something you need to worry about unless working low level with the renderer.
+Parameters don't have to belong to a block but if they do you can share parameter blocks with multiple instances of @ref bs::Material "Material", which is more efficient. Normally this is not something you need to worry about unless working low level with the renderer.
 
 Blocks all begin with the Block keyword, followed by a name. The name must match the name of the constant/uniform block in actual shader code:
 ~~~~~~~~~~~~~~
@@ -448,4 +448,4 @@ Where AddressModeBlock has the following properties:
 It can also be specified in short form, where parameters are in order as above. For example:
  - AddressMode = { WRAP, WRAP, WRAP };
  
-See @ref BansheeEngine::SamplerState "SamplerState" documentation about the meaning of these properties. 
+See @ref bs::SamplerState "SamplerState" documentation about the meaning of these properties. 

Documentation/Manuals/Native/coreThread.md

@@ -22,55 +22,55 @@ Here are some examples of when the simulation thread needs to interact with the
 As you can see the communication is one directional. Simulation thread calls into the core thread when it needs to notify it of a certain event. In rare cases the core thread needs to notify the simulation thread (e.g. when the user moves/resizes the window the simulation thread needs to be aware of the new position/size), but this is handled on a per-case basis using normal thread synchronization primitives, and we won't touch on it further.
 
 # Command queue {#coreThread_a}
-All the operations listed above happen with the help of a @ref BansheeEngine::CommandQueue<SyncPolicy> "CommandQueue". When simulation thread needs to notify the core thread about something it queues a command in the queue using @ref BansheeEngine::CommandQueue<SyncPolicy>::queue "CommandQueue::queue", which accepts a function to be executed. The core thread continually reads from the command queue and executes commands in the order of they are submitted.
+All the operations listed above happen with the help of a @ref bs::CommandQueue<SyncPolicy> "CommandQueue". When simulation thread needs to notify the core thread about something it queues a command in the queue using @ref bs::CommandQueue<SyncPolicy>::queue "CommandQueue::queue", which accepts a function to be executed. The core thread continually reads from the command queue and executes commands in the order of they are submitted.
 
-The main command queue can be accessed using @ref BansheeEngine::CoreThread::queueCommand "CoreThread::queueCommand", which is just a wrapper for the @ref BansheeEngine::CommandQueue<SyncPolicy>::queue "CommandQueue::queue" method mentioned above.
+The main command queue can be accessed using @ref bs::CoreThread::queueCommand "CoreThread::queueCommand", which is just a wrapper for the @ref bs::CommandQueue<SyncPolicy>::queue "CommandQueue::queue" method mentioned above.
 
 ## Returning values {#coreThread_a_a}
-Sometimes a queued command needs to return a value to the simulation thread (for example, when reading pixels from a texture). This can be performed by calling @ref BansheeEngine::CoreThread::queueReturnCommand "CoreThread::queueReturnCommand", which internally calls @ref BansheeEngine::CommandQueue<SyncPolicy>::queueReturn "CommandQueue::queueReturn". 
+Sometimes a queued command needs to return a value to the simulation thread (for example, when reading pixels from a texture). This can be performed by calling @ref bs::CoreThread::queueReturnCommand "CoreThread::queueReturnCommand", which internally calls @ref bs::CommandQueue<SyncPolicy>::queueReturn "CommandQueue::queueReturn". 
 
-Since the command was queued and we don't know when will the core thread execute, we have no guarantees when its return value will be available. Therefore this method will return an @ref BansheeEngine::AsyncOp "AsyncOp" object. This object can be used for checking if the return value is available by calling @ref BansheeEngine::AsyncOp::hasCompleted "AsyncOp::hasCompleted". If the return value is available you can retrieve it via @ref BansheeEngine::AsyncOp::getReturnValue<T> "AsyncOp::getReturnValue<T>".
+Since the command was queued and we don't know when will the core thread execute, we have no guarantees when its return value will be available. Therefore this method will return an @ref bs::AsyncOp "AsyncOp" object. This object can be used for checking if the return value is available by calling @ref bs::AsyncOp::hasCompleted "AsyncOp::hasCompleted". If the return value is available you can retrieve it via @ref bs::AsyncOp::getReturnValue<T> "AsyncOp::getReturnValue<T>".
 
 ## Blocking {#coreThread_a_b}
-In certain cases you need to see the results of an operation right away. In such cases you can tell the simulation thread to wait until a certain command is done executing on the core thread. You can do this by setting the `blockUntilComplete` parameter of @ref BansheeEngine::CoreThread::queueCommand "CoreThread::queueCommand" and @ref BansheeEngine::CoreThread::queueReturnCommand "CoreThread::queueReturnCommand" to true.
+In certain cases you need to see the results of an operation right away. In such cases you can tell the simulation thread to wait until a certain command is done executing on the core thread. You can do this by setting the `blockUntilComplete` parameter of @ref bs::CoreThread::queueCommand "CoreThread::queueCommand" and @ref bs::CoreThread::queueReturnCommand "CoreThread::queueReturnCommand" to true.
 
-You can also block by calling @ref BansheeEngine::AsyncOp::blockUntilComplete "AsyncOp::blockUntilComplete". This is similar to blocking directly on the @ref BansheeEngine::CoreThread::queueReturnCommand "CoreThread::queueReturnCommand" call, but can be more useful if you're not sure immediately if you need to wait for the result or not.
+You can also block by calling @ref bs::AsyncOp::blockUntilComplete "AsyncOp::blockUntilComplete". This is similar to blocking directly on the @ref bs::CoreThread::queueReturnCommand "CoreThread::queueReturnCommand" call, but can be more useful if you're not sure immediately if you need to wait for the result or not.
 
 You should be very careful about blocking as it wastes CPU cycles since one thread is just sitting there doing nothing until the core thread reaches the command (which could be as long as a few dozen milliseconds).
 
 ## Core accessors {#coreThread_a_c}
-Core accessors can be considered as light-weight command queues. They perform the same operations as @ref BansheeEngine::CoreThread::queueCommand "CoreThread::queueCommand" and @ref BansheeEngine::CoreThread::queueReturnCommand "CoreThread::queueReturnCommand". However core accessors can only be accessed from a single thread, while the methods just listed can be accessed from any thread. Accessors also don't submit their commands to the core thread immediately, instead they are submitted all together using a separate method.
+Core accessors can be considered as light-weight command queues. They perform the same operations as @ref bs::CoreThread::queueCommand "CoreThread::queueCommand" and @ref bs::CoreThread::queueReturnCommand "CoreThread::queueReturnCommand". However core accessors can only be accessed from a single thread, while the methods just listed can be accessed from any thread. Accessors also don't submit their commands to the core thread immediately, instead they are submitted all together using a separate method.
 
 Because of these two reasons core accessors are much faster than the primary command queue, and you should always prefer to use them instead of directly queuing commands on the primary queue.
 
-Accessor for the current thread can be retrieved with @ref BansheeEngine::CoreThread::getAccessor "CoreThread::getAccessor". You queue the commands in the accessor by calling @ref BansheeEngine::CoreThreadAccessorBase::queueCommand "CoreThreadAccessor::queueCommand" and @ref BansheeEngine::CoreThreadAccessorBase::queueReturnCommand "CoreThreadAccessor::queueReturnCommand". Once you are done queuing commands you can submit them to the core thread by calling @ref BansheeEngine::CoreThread::submitAccessors "CoreThread::submitAccessors".
+Accessor for the current thread can be retrieved with @ref bs::CoreThread::getAccessor "CoreThread::getAccessor". You queue the commands in the accessor by calling @ref bs::CoreThreadAccessorBase::queueCommand "CoreThreadAccessor::queueCommand" and @ref bs::CoreThreadAccessorBase::queueReturnCommand "CoreThreadAccessor::queueReturnCommand". Once you are done queuing commands you can submit them to the core thread by calling @ref bs::CoreThread::submitAccessors "CoreThread::submitAccessors".
 
-Internally @ref BansheeEngine::CoreThread::submitAccessors "CoreThread::submitAccessors" uses the primary queue to submit a command that reads all the commands from the accessor and executes them in order. So esentially they are just built on top of the primary command queue, and in fact most of the threading functionality is.
+Internally @ref bs::CoreThread::submitAccessors "CoreThread::submitAccessors" uses the primary queue to submit a command that reads all the commands from the accessor and executes them in order. So esentially they are just built on top of the primary command queue, and in fact most of the threading functionality is.
 
 ### Core accessor APIs {#coreThread_a_c_a}
-Although you can queue your own commands to the core accessor, many systems provide methods that automatically queue commands on the core accessor. For example take a look at @ref BansheeEngine::RenderAPI "RenderAPI" which allows you to interact directly with the render API from the simulation thread (something that is normally reserved for the core thread). Most of the methods accept a @ref BansheeEngine::CoreThreadAccessor<CommandQueueSyncPolicy> "CoreThreadAccessor", and internally just queue commands on it. This allows you to perform low level rendering operations from the simulation thread.
+Although you can queue your own commands to the core accessor, many systems provide methods that automatically queue commands on the core accessor. For example take a look at @ref bs::RenderAPI "RenderAPI" which allows you to interact directly with the render API from the simulation thread (something that is normally reserved for the core thread). Most of the methods accept a @ref bs::CoreThreadAccessor<CommandQueueSyncPolicy> "CoreThreadAccessor", and internally just queue commands on it. This allows you to perform low level rendering operations from the simulation thread.
 
-@ref BansheeEngine::Mesh "Mesh", @ref BansheeEngine::Texture "Texture" and @ref BansheeEngine::RenderTarget "RenderTarget" also provide several methods for performing core thread operations from the simulation thread via the core accessors.
+@ref bs::Mesh "Mesh", @ref bs::Texture "Texture" and @ref bs::RenderTarget "RenderTarget" also provide several methods for performing core thread operations from the simulation thread via the core accessors.
 
 It's important to remember these methods are just a convenience, and internally they use the same command queuing methods we described in the previous section.
 
 # Core objects {#coreThread_b}
 Core objects are objects that need to exist on both simulation and core threads. Although you could technically handle such cases manually by using the command queue, it is useful to provide an interface that allows the user to work normally with an object without needing to know about the threading internals, and this is where core objects come in.
 
-For example, a @ref BansheeEngine::Mesh "Mesh" is a core object because we want to allow the user to intuitively work with it on the simulation thread (without having to know about command queue or the core thread), but we also want to use it on the core thread (it needs to create index/vertex buffers on the GPU, and have a DirectX/OpenGL representation).
+For example, a @ref bs::Mesh "Mesh" is a core object because we want to allow the user to intuitively work with it on the simulation thread (without having to know about command queue or the core thread), but we also want to use it on the core thread (it needs to create index/vertex buffers on the GPU, and have a DirectX/OpenGL representation).
 
 Every core object is split into two interfaces:
- - @ref BansheeEngine::CoreObject "CoreObject" - Implementations of this interface represents the simulation thread counterpart of the object.
- - @ref BansheeEngine::CoreObjectCore "CoreObjectCore" - Implementations of this interface represents the core thread counterpart of the object.
+ - @ref bs::CoreObject "CoreObject" - Implementations of this interface represents the simulation thread counterpart of the object.
+ - @ref bs::CoreObjectCore "CoreObjectCore" - Implementations of this interface represents the core thread counterpart of the object.
  
-When a @ref BansheeEngine::CoreObject "CoreObject" is created it internally queues the creation of its @ref BansheeEngine::CoreObjectCore "CoreObjectCore" counterpart on the main command queue. Similar thing happens when it is destroyed, a destroy operation is queued and sent to the core thread.
+When a @ref bs::CoreObject "CoreObject" is created it internally queues the creation of its @ref bs::CoreObjectCore "CoreObjectCore" counterpart on the main command queue. Similar thing happens when it is destroyed, a destroy operation is queued and sent to the core thread.
 
-Aside from initialization/destruction, core objects also support synchronization of data between the two threads (e.g. a @ref BansheeEngine::Light "Light" is a core object, and when the user changes light radius, it is automatically synchronized to its core thread counterpart @ref BansheeEngine::LightCore "LightCore").
+Aside from initialization/destruction, core objects also support synchronization of data between the two threads (e.g. a @ref bs::Light "Light" is a core object, and when the user changes light radius, it is automatically synchronized to its core thread counterpart @ref bs::LightCore "LightCore").
 
 ## Creating your own core objects {#coreThread_b_a}
-To create a custom core object, you need to implement the @ref BansheeEngine::CoreObject "CoreObject" class, which by default requires no methods to be implemented. 
+To create a custom core object, you need to implement the @ref bs::CoreObject "CoreObject" class, which by default requires no methods to be implemented. 
 
-When creating your core object its important to note they are only allowed to be referenced using specialized shared pointers, and require specific initialization steps. The shared pointer needs to be created using the @ref BansheeEngine::bs_core_ptr_new<T> "bs_core_ptr_new<T>" method, followed by calls to @ref BansheeEngine::CoreObject::_setThisPtr "CoreObject::_setThisPtr" and @ref BansheeEngine::CoreObject::initialize "CoreObject::initialize". Due to this complex initialization procedure it is highly suggested that you create a static `create` method for your core object, which does every step automatically. For example:
+When creating your core object its important to note they are only allowed to be referenced using specialized shared pointers, and require specific initialization steps. The shared pointer needs to be created using the @ref bs::bs_core_ptr_new<T> "bs_core_ptr_new<T>" method, followed by calls to @ref bs::CoreObject::_setThisPtr "CoreObject::_setThisPtr" and @ref bs::CoreObject::initialize "CoreObject::initialize". Due to this complex initialization procedure it is highly suggested that you create a static `create` method for your core object, which does every step automatically. For example:
 ~~~~~~~~~~~~~{.cpp}
 SPtr<MyCoreObject> MyCoreObject::create()
 {
@@ -82,23 +82,23 @@ SPtr<MyCoreObject> MyCoreObject::create()
 }
 ~~~~~~~~~~~~~
 
-You will also want to override @ref BansheeEngine::CoreObject::createCore "CoreObject::createCore", which creates the core thread counterpart of your object. It should return a normal shared pointer to your implementation of @ref BansheeEngine::CoreObjectCore "CoreObjectCore".
+You will also want to override @ref bs::CoreObject::createCore "CoreObject::createCore", which creates the core thread counterpart of your object. It should return a normal shared pointer to your implementation of @ref bs::CoreObjectCore "CoreObjectCore".
 
-Once a core object is created you can use it as a normal object, while you can retrieve its core thread counterpart by calling @ref BansheeEngine::CoreObject::getCore "CoreObject::getCore", which you can use on the core thread. Object creation/destruction will happen automatically on the valid thread, and you also get the ability to synchronize information between the two (see below).
+Once a core object is created you can use it as a normal object, while you can retrieve its core thread counterpart by calling @ref bs::CoreObject::getCore "CoreObject::getCore", which you can use on the core thread. Object creation/destruction will happen automatically on the valid thread, and you also get the ability to synchronize information between the two (see below).
 
 ### CoreObjectCore {#coreThread_b_a_a}
-To create the core thread counterpart of a @ref BansheeEngine::CoreObject "CoreObject" you must implement the @ref BansheeEngine::CoreObjectCore "CoreObjectCore" class. 
+To create the core thread counterpart of a @ref bs::CoreObject "CoreObject" you must implement the @ref bs::CoreObjectCore "CoreObjectCore" class. 
 
-This object provides an @ref BansheeEngine::CoreObject::initialize "CoreObject::initialize" method. You should perform any initialization in this method instead of the constructor, as it is guaranteed to be run on the core thread.
+This object provides an @ref bs::CoreObject::initialize "CoreObject::initialize" method. You should perform any initialization in this method instead of the constructor, as it is guaranteed to be run on the core thread.
 
-The destructor is always assumed to be executed on the core thread. For this reason you must ensure never to store references to CoreObjectCore on the simulation thread, because if they go out of scope there it will trigger an error. Similar rule applies to @ref BansheeEngine::CoreObject "CoreObjects" as they shouldn't be stored on the core thread.
+The destructor is always assumed to be executed on the core thread. For this reason you must ensure never to store references to CoreObjectCore on the simulation thread, because if they go out of scope there it will trigger an error. Similar rule applies to @ref bs::CoreObject "CoreObjects" as they shouldn't be stored on the core thread.
 
 ### Synchronization {#coreThread_b_a_b}
-Earlier we mentioned that aside from handling construction/destruction the core objects also provide a way to synchronize between the two threads. The synchronization is always one way, from @ref BansheeEngine::CoreObject "CoreObject" to @ref BansheeEngine::CoreObjectCore "CoreObjectCore". 
+Earlier we mentioned that aside from handling construction/destruction the core objects also provide a way to synchronize between the two threads. The synchronization is always one way, from @ref bs::CoreObject "CoreObject" to @ref bs::CoreObjectCore "CoreObjectCore". 
 
-Synchronization should happen whenever some property on the @ref BansheeEngine::CoreObject "CoreObject" changes, that you would wish to make available on the core thread. To synchronize implement the @ref BansheeEngine::CoreObject::syncToCore(FrameAlloc*) "CoreObject::syncToCore" method, which generates the data for synchronization, and @ref BansheeEngine::CoreObjectCore::syncToCore "CoreObjectCore::syncToCore" which accepts it.
+Synchronization should happen whenever some property on the @ref bs::CoreObject "CoreObject" changes, that you would wish to make available on the core thread. To synchronize implement the @ref bs::CoreObject::syncToCore(FrameAlloc*) "CoreObject::syncToCore" method, which generates the data for synchronization, and @ref bs::CoreObjectCore::syncToCore "CoreObjectCore::syncToCore" which accepts it.
 
-The synchronized data is transfered between the objects in the form of raw bytes, within the @ref BansheeEngine::CoreSyncData "CoreSyncData" structure. You can use @ref BansheeEngine::rttiGetElemSize "rttiGetElemSize" and @ref BansheeEngine::rttiWriteElem "rttiWriteElem" to encode fields into raw memory, and @ref BansheeEngine::rttiReadElem "rttiReadElem" to decode them. See the manual about [rtti](@ref rtti) for more information about serialization. @ref BansheeEngine::CoreObject::syncToCore(FrameAlloc*) "CoreObject::syncToCore" is provided an instance of @ref BansheeEngine::FrameAlloc "FrameAlloc" which should be used for allocating the serialization buffer. This is an allocator that is fast and doesn't require explicit memory deallocation making it perfect for synchronization. A simple synchronization example would look like so:
+The synchronized data is transfered between the objects in the form of raw bytes, within the @ref bs::CoreSyncData "CoreSyncData" structure. You can use @ref bs::rttiGetElemSize "rttiGetElemSize" and @ref bs::rttiWriteElem "rttiWriteElem" to encode fields into raw memory, and @ref bs::rttiReadElem "rttiReadElem" to decode them. See the manual about [rtti](@ref rtti) for more information about serialization. @ref bs::CoreObject::syncToCore(FrameAlloc*) "CoreObject::syncToCore" is provided an instance of @ref bs::FrameAlloc "FrameAlloc" which should be used for allocating the serialization buffer. This is an allocator that is fast and doesn't require explicit memory deallocation making it perfect for synchronization. A simple synchronization example would look like so:
 ~~~~~~~~~~~~~{.cpp}
 // CoreObject (creates the synchronization data)
 CoreSyncData MyCoreObject::syncToCore(FrameAlloc* allocator) 
@@ -128,27 +128,27 @@ void MyCoreObjectCore::syncToCore(const CoreSyncData& data)
 }
 ~~~~~~~~~~~~~
 
-Whenever you need to trigger synchronization you must call @ref BansheeEngine::CoreObject::markCoreDirty "CoreObject::markCoreDirty" which notifies the system that synchronization is required. This will in turn trigger a call to @ref BansheeEngine::CoreObject::syncToCore(FrameAlloc*) "CoreObject::syncToCore" method you implemented earlier. Synchronization happens automatically for all dirty core objects once per frame. Optionally you may call @ref BansheeEngine::CoreObject::syncToCore(CoreAccessor&) "CoreObject::syncToCore" to manually queue the synchronization.
+Whenever you need to trigger synchronization you must call @ref bs::CoreObject::markCoreDirty "CoreObject::markCoreDirty" which notifies the system that synchronization is required. This will in turn trigger a call to @ref bs::CoreObject::syncToCore(FrameAlloc*) "CoreObject::syncToCore" method you implemented earlier. Synchronization happens automatically for all dirty core objects once per frame. Optionally you may call @ref bs::CoreObject::syncToCore(CoreAccessor&) "CoreObject::syncToCore" to manually queue the synchronization.
 
-See implementation of @ref BansheeEngine::Light "Light" and @ref BansheeEngine::LightCore "LightCore" in "BsLight.cpp" for a simple example of synchronization.
+See implementation of @ref bs::Light "Light" and @ref bs::LightCore "LightCore" in "BsLight.cpp" for a simple example of synchronization.
 
 ### Dependencies {#coreThread_b_a_c}
-Core objects might be dependant on other core objects. For example a @ref BansheeEngine::Material "Material" is dependant on a @ref BansheeEngine::Shader "Shader". Whenever the shader's object is marked as dirty the material might need to perform synchronization as well. In general whenever a dependancy core object is marked as dirty, its dependant will be synchronized as well.
+Core objects might be dependant on other core objects. For example a @ref bs::Material "Material" is dependant on a @ref bs::Shader "Shader". Whenever the shader's object is marked as dirty the material might need to perform synchronization as well. In general whenever a dependancy core object is marked as dirty, its dependant will be synchronized as well.
 
-To add dependencies implement the @ref BansheeEngine::CoreObject::getCoreDependencies "CoreObject::getCoreDependencies" method, which returns all currently valid dependencies. Whenever the dependencies change call @ref BansheeEngine::CoreObject::markDependenciesDirty "CoreObject::markDependenciesDirty" so the system can refresh its dependency list.
+To add dependencies implement the @ref bs::CoreObject::getCoreDependencies "CoreObject::getCoreDependencies" method, which returns all currently valid dependencies. Whenever the dependencies change call @ref bs::CoreObject::markDependenciesDirty "CoreObject::markDependenciesDirty" so the system can refresh its dependency list.
 
 ## Deserialization {#coreThread_b_b}
-When creating RTTI for a @ref BansheeEngine::CoreObject "CoreObject", as described in the [RTTI](@ref rtti) manual, you must take care not to fully initialize the object until deserialization of the object's fields is done.
+When creating RTTI for a @ref bs::CoreObject "CoreObject", as described in the [RTTI](@ref rtti) manual, you must take care not to fully initialize the object until deserialization of the object's fields is done.
 
-Essentially this means that @ref BansheeEngine::RTTITypeBase::newRTTIObject "RTTIType::newRTTIObject" must return a pointer to the core object on which @ref BansheeEngine::CoreObject::initialize "CoreObject::initialize" hasn't been called yet. You must then call @ref BansheeEngine::CoreObject::initialize "CoreObject::initialize" manually in @ref BansheeEngine::RTTITypeBase::onDeserializationEnded "RTTIType::onDeserializationEnded".
+Essentially this means that @ref bs::RTTITypeBase::newRTTIObject "RTTIType::newRTTIObject" must return a pointer to the core object on which @ref bs::CoreObject::initialize "CoreObject::initialize" hasn't been called yet. You must then call @ref bs::CoreObject::initialize "CoreObject::initialize" manually in @ref bs::RTTITypeBase::onDeserializationEnded "RTTIType::onDeserializationEnded".
 
-This ensures that @ref BansheeEngine::CoreObject::initialize "CoreObject::initialize" has all the relevant information when it is ran.
+This ensures that @ref bs::CoreObject::initialize "CoreObject::initialize" has all the relevant information when it is ran.
 
 ## Other features {#coreThread_b_c}
 Core objects also have some other potentially useful features:
- - @ref BansheeEngine::CoreObject::getInternalID "CoreObject::getInternalID" will return a globally unique ID for the core object
- - @ref BansheeEngine::CoreObject::destroy "CoreObject::destroy" will destroy the core object and its core thread counterpart. You do not need to call this manually as it will be automatically called when the object goes out of scope (is no longer referenced). The core thread counterpart (@ref BansheeEngine::CoreObjectCore "CoreObjectCore") will not be destroyed if something on the core thread is still holding a reference to it.
- - Override @ref BansheeEngine::CoreObject::initialize "CoreObject::initialize" or @ref BansheeEngine::CoreObject::destroy "CoreObject::destroy" methods instead of using the constructor/destructor. This ensures that your initialization code runs after things like serialization, and also allows you to call virtual methods.
- - You can construct a core object without a core thread counterpart. Simply don't override @ref BansheeEngine::CoreObject::createCore "CoreObject::createCore".
- - You can construct a core object with a @ref BansheeEngine::CoreObjectCore "CoreObjectCore" that isn't initialized on the core thread by setting the @ref BansheeEngine::CoreObject "CoreObject" constructor parameter `requiresCoreInit` to false.
- - Core objects always hold a shared pointer to themselves. Use @ref BansheeEngine::CoreObject::getThisPtr "CoreObject::getThisPtr" to access it.
+ - @ref bs::CoreObject::getInternalID "CoreObject::getInternalID" will return a globally unique ID for the core object
+ - @ref bs::CoreObject::destroy "CoreObject::destroy" will destroy the core object and its core thread counterpart. You do not need to call this manually as it will be automatically called when the object goes out of scope (is no longer referenced). The core thread counterpart (@ref bs::CoreObjectCore "CoreObjectCore") will not be destroyed if something on the core thread is still holding a reference to it.
+ - Override @ref bs::CoreObject::initialize "CoreObject::initialize" or @ref bs::CoreObject::destroy "CoreObject::destroy" methods instead of using the constructor/destructor. This ensures that your initialization code runs after things like serialization, and also allows you to call virtual methods.
+ - You can construct a core object without a core thread counterpart. Simply don't override @ref bs::CoreObject::createCore "CoreObject::createCore".
+ - You can construct a core object with a @ref bs::CoreObjectCore "CoreObjectCore" that isn't initialized on the core thread by setting the @ref bs::CoreObject "CoreObject" constructor parameter `requiresCoreInit` to false.
+ - Core objects always hold a shared pointer to themselves. Use @ref bs::CoreObject::getThisPtr "CoreObject::getThisPtr" to access it.

Documentation/Manuals/Native/gameObjects.md

@@ -2,18 +2,18 @@ Game objects								{#gameObjects}
 ===============
 [TOC]
 
-@ref BansheeEngine::GameObject "Game objects" represent the core of your game and where most of the gameplay code will be located. There are two types of game objects:
- - @ref BansheeEngine::SceneObject "SceneObject" - Contains zero or multiple @ref BansheeEngine::Component "components". Has a position/rotation/scale in space, and can be parented to other scene objects.
- - @ref BansheeEngine::Component "Components" - Provides a set of functionality used for customizing a @ref BansheeEngine::SceneObject "SceneObject". You can build your own components, and if fact this is where majority of your gameplay code will belong. A variety of built-in components are also provided.
+@ref bs::GameObject "Game objects" represent the core of your game and where most of the gameplay code will be located. There are two types of game objects:
+ - @ref bs::SceneObject "SceneObject" - Contains zero or multiple @ref bs::Component "components". Has a position/rotation/scale in space, and can be parented to other scene objects.
+ - @ref bs::Component "Components" - Provides a set of functionality used for customizing a @ref bs::SceneObject "SceneObject". You can build your own components, and if fact this is where majority of your gameplay code will belong. A variety of built-in components are also provided.
  
 # Scene objects {#gameObjects_a}
-To create a @ref BansheeEngine::SceneObject "SceneObject" call @ref BansheeEngine::SceneObject::create "SceneObject::create" with a name of the object. The name doesn't have to be unique but is useful for identifying the object.
+To create a @ref bs::SceneObject "SceneObject" call @ref bs::SceneObject::create "SceneObject::create" with a name of the object. The name doesn't have to be unique but is useful for identifying the object.
 
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject mySO = SceneObject::create("MySceneObject");
 ~~~~~~~~~~~~~
 
-All @ref BansheeEngine::SceneObject "SceneObjects" are organized in a hierarchy. Initially when a new @ref BansheeEngine::SceneObject "SceneObject" is created it is parented to the scene root. However you can parent it to another scene object like so:
+All @ref bs::SceneObject "SceneObjects" are organized in a hierarchy. Initially when a new @ref bs::SceneObject "SceneObject" is created it is parented to the scene root. However you can parent it to another scene object like so:
 
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject myParentSO = SceneObject::create("MyParentSceneObject");
@@ -21,9 +21,9 @@ HSceneObject mySO = SceneObject::create("MySceneObject");
 mySO->setParent(myParentSO);
 ~~~~~~~~~~~~~
 
-You can iterate over all children of a @ref BansheeEngine::SceneObject "SceneObject" by calling @ref BansheeEngine::SceneObject::getChild "SceneObjects::getChild"/@ref BansheeEngine::SceneObject::getNumChildren "SceneObjects::getNumChildren". You can also search for a specific child by name with @ref BansheeEngine::SceneObject::findChild "SceneObjects::findChild".
+You can iterate over all children of a @ref bs::SceneObject "SceneObject" by calling @ref bs::SceneObject::getChild "SceneObjects::getChild"/@ref bs::SceneObject::getNumChildren "SceneObjects::getNumChildren". You can also search for a specific child by name with @ref bs::SceneObject::findChild "SceneObjects::findChild".
 
-@ref BansheeEngine::SceneObject "SceneObjects" can also be moved, rotated and scaled in the coordinate system. Use methods like @ref BansheeEngine::SceneObject::setPosition "SceneObject::setPosition", @ref BansheeEngine::SceneObject::setRotation "SceneObject::setRotation", @ref BansheeEngine::SceneObject::setScale "SceneObject::setScale" to set these values relative to the parent object. You can also use @ref BansheeEngine::SceneObject::setWorldPosition "SceneObject::setWorldPosition", @ref BansheeEngine::SceneObject::setWorldRotation "SceneObject::setWorldRotation", @ref BansheeEngine::SceneObject::setWorldScale "SceneObject::setWorldScale" to set them relative to the world space. A variety of helper methods like @ref BansheeEngine::SceneObject::lookAt "SceneObject::lookAt" also exists. For example:
+@ref bs::SceneObject "SceneObjects" can also be moved, rotated and scaled in the coordinate system. Use methods like @ref bs::SceneObject::setPosition "SceneObject::setPosition", @ref bs::SceneObject::setRotation "SceneObject::setRotation", @ref bs::SceneObject::setScale "SceneObject::setScale" to set these values relative to the parent object. You can also use @ref bs::SceneObject::setWorldPosition "SceneObject::setWorldPosition", @ref bs::SceneObject::setWorldRotation "SceneObject::setWorldRotation", @ref bs::SceneObject::setWorldScale "SceneObject::setWorldScale" to set them relative to the world space. A variety of helper methods like @ref bs::SceneObject::lookAt "SceneObject::lookAt" also exists. For example:
 
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject mySO = SceneObject::create("MySceneObject");
@@ -36,51 +36,51 @@ mySO->setPosition(position);
 mySO->setLookAt(lookAt);
 ~~~~~~~~~~~~~
 
-Once you are done with a scene object, call @ref BansheeEngine::SceneObject::destroy "SceneObject::destroy". This will remove the scene object and all of its children out of the scene.
+Once you are done with a scene object, call @ref bs::SceneObject::destroy "SceneObject::destroy". This will remove the scene object and all of its children out of the scene.
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject mySO = SceneObject::create("MySceneObject");
 mySO->destroy()
 ~~~~~~~~~~~~~
 
-Scene objects aren't very useful on their own however. Each scene object can have multiple @ref BansheeEngine::Component "Components" attached.
+Scene objects aren't very useful on their own however. Each scene object can have multiple @ref bs::Component "Components" attached.
 
 # Components {#gameObjects_b}
-Components provide logic that customizes a scene object. To attach a @ref BansheeEngine::Component "Component" to a scene object use @ref BansheeEngine::SceneObject::addComponent<T, Args...> "SceneObject::addComponent<T>". For example if we wanted to add the built-in @ref BansheeEngine::CCamera "CCamera" component:
+Components provide logic that customizes a scene object. To attach a @ref bs::Component "Component" to a scene object use @ref bs::SceneObject::addComponent<T, Args...> "SceneObject::addComponent<T>". For example if we wanted to add the built-in @ref bs::CCamera "CCamera" component:
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject mySO = SceneObject::create("MySceneObject");
 HCamera camera = mySO->addComponent<CCamera>();
 ~~~~~~~~~~~~~
 
-Once a component is registered with a scene object its code will be executed as long as the scene object is active and not destroyed. Use @ref BansheeEngine::SceneObject::setActive "SceneObject::setActive" to activate and deactivate a scene object. Deactive object will also deactivate all children and their components.
+Once a component is registered with a scene object its code will be executed as long as the scene object is active and not destroyed. Use @ref bs::SceneObject::setActive "SceneObject::setActive" to activate and deactivate a scene object. Deactive object will also deactivate all children and their components.
 
-To search for a component on a scene object use @ref BansheeEngine::SceneObject::getComponent<T> "SceneObject::getComponent<T>" like so:
+To search for a component on a scene object use @ref bs::SceneObject::getComponent<T> "SceneObject::getComponent<T>" like so:
 ~~~~~~~~~~~~~{.cpp}
 HCamera camera = mySO->getComponent<CCamera>(); // Returns CCamera component if it exists on the scene object
 ~~~~~~~~~~~~~
 
-If you wish to remove a component, call @ref BansheeEngine::Component::destroy "Component::destroy".
+If you wish to remove a component, call @ref bs::Component::destroy "Component::destroy".
 ~~~~~~~~~~~~~{.cpp}
 HCamera camera = mySO->getComponent<CCamera>();
 camera->destroy();
 ~~~~~~~~~~~~~
 
 ## Custom components {#gameObjects_b_a}
-Using existing components is useful, but main purpose of components is for the user to implement their own gameplay code. To create your own component simply implement the @ref BansheeEngine::Component "Component" interface.
-
-The @ref BansheeEngine::Component "Component" interface provides several methods which you can override with your own code:
- - @ref BansheeEngine::Component::onInitialized "Component::onInitialized" - Called once when the component is first instantiated. You should use this instead of the constructor for initialization.
- - @ref BansheeEngine::Component::update "Component::update" - Called every frame while the game is running and the component is enabled.
- - @ref BansheeEngine::Component::onEnabled "Component::onEnabled" - Called whenever a component is enabled, or instantiated as enabled in which case it is called after @ref BansheeEngine::Component::onInitialized "Component::onInitialized".
- - @ref BansheeEngine::Component::onDisabled "Component::onDisabled" - Called whenever a component is disabled. This includes destruction where it is called before @ref BansheeEngine::Component::onDestroyed "Component::onDestroyed". 
- - @ref BansheeEngine::Component::onDestroyed "Component::onDestroyed" - Called before the component is destroyed. Destruction is usually delayed until the end of the current frame unless specified otherwise in a call to @ref BansheeEngine::Component::destroy "Component::destroy". 
- - @ref BansheeEngine::Component::onTransformChanged "Component::onTransformChanged" - Called when the transform of the owning scene object changes. You must subscribe to this event by calling @ref BansheeEngine::Component::setNotifyFlags "Component::setNotifyFlags".
+Using existing components is useful, but main purpose of components is for the user to implement their own gameplay code. To create your own component simply implement the @ref bs::Component "Component" interface.
+
+The @ref bs::Component "Component" interface provides several methods which you can override with your own code:
+ - @ref bs::Component::onInitialized "Component::onInitialized" - Called once when the component is first instantiated. You should use this instead of the constructor for initialization.
+ - @ref bs::Component::update "Component::update" - Called every frame while the game is running and the component is enabled.
+ - @ref bs::Component::onEnabled "Component::onEnabled" - Called whenever a component is enabled, or instantiated as enabled in which case it is called after @ref bs::Component::onInitialized "Component::onInitialized".
+ - @ref bs::Component::onDisabled "Component::onDisabled" - Called whenever a component is disabled. This includes destruction where it is called before @ref bs::Component::onDestroyed "Component::onDestroyed". 
+ - @ref bs::Component::onDestroyed "Component::onDestroyed" - Called before the component is destroyed. Destruction is usually delayed until the end of the current frame unless specified otherwise in a call to @ref bs::Component::destroy "Component::destroy". 
+ - @ref bs::Component::onTransformChanged "Component::onTransformChanged" - Called when the transform of the owning scene object changes. You must subscribe to this event by calling @ref bs::Component::setNotifyFlags "Component::setNotifyFlags".
  
-Since components are a part of the scene you must also make sure to implement their @ref BansheeEngine::RTTITypeBase "RTTIType", so they can be saved and loaded. Read the [RTTI](@ref rtti) manual for more information. Their creation differs slightly to normal RTTI objects: when overloading @ref BansheeEngine::RTTITypeBase::newRTTIObject "RTTIType::newRTTIObject" make sure to use `GameObjectRTTI::createGameObject<T>` to create the component, instead of manually creating the shared pointer. This ensures that the component handle is properly created.
+Since components are a part of the scene you must also make sure to implement their @ref bs::RTTITypeBase "RTTIType", so they can be saved and loaded. Read the [RTTI](@ref rtti) manual for more information. Their creation differs slightly to normal RTTI objects: when overloading @ref bs::RTTITypeBase::newRTTIObject "RTTIType::newRTTIObject" make sure to use `GameObjectRTTI::createGameObject<T>` to create the component, instead of manually creating the shared pointer. This ensures that the component handle is properly created.
 
 # Game object handles {#gameObjects_c}
-We have seen game object handles a lot in this manual, but haven't talked about them. All game objects are referenced via a @ref BansheeEngine::GameObjectHandle<T> "GameObjectHandle<T>". They act similar to pointers where you can use the pointer member access "->" operator to access the underlying game object, while the normal member access "." operator can be used for operating directly on the handle data. 
+We have seen game object handles a lot in this manual, but haven't talked about them. All game objects are referenced via a @ref bs::GameObjectHandle<T> "GameObjectHandle<T>". They act similar to pointers where you can use the pointer member access "->" operator to access the underlying game object, while the normal member access "." operator can be used for operating directly on the handle data. 
 
-You can use @ref BansheeEngine::GameObjectHandle<T>::isDestroyed "GameObjectHandle<T>::isDestroyed" to check if a game object a handle is pointing to has been destroyed.
+You can use @ref bs::GameObjectHandle<T>::isDestroyed "GameObjectHandle<T>::isDestroyed" to check if a game object a handle is pointing to has been destroyed.
 
 To create your own game object handle it is suggested you create a `typedef` and prefix your component name with an "H", like so:
 ~~~~~~~~~~~~~{.cpp}
@@ -93,11 +93,11 @@ typedef GameObjectHandle<MyComponent> HMyComponent;
 ~~~~~~~~~~~~~
 
 # Prefabs {#gameObjects_d}
-@ref BansheeEngine::Prefab "Prefabs" allow you to store groups of scene objects (and their components) and then re-use them. A prefab can be an entire scene or just a small subset of scene objects.
+@ref bs::Prefab "Prefabs" allow you to store groups of scene objects (and their components) and then re-use them. A prefab can be an entire scene or just a small subset of scene objects.
 
-To create one call @ref BansheeEngine::Prefab::create "Prefab::create" with a @ref BansheeEngine::SceneObject "SceneObject" you want to create a prefab of. The object, all of its children and all of the components will be stored in the prefab. You can then save that prefab to disk like any other @ref BansheeEngine::Resource "Resource" (see the [resources](@ref resources) manual), and load it later.
+To create one call @ref bs::Prefab::create "Prefab::create" with a @ref bs::SceneObject "SceneObject" you want to create a prefab of. The object, all of its children and all of the components will be stored in the prefab. You can then save that prefab to disk like any other @ref bs::Resource "Resource" (see the [resources](@ref resources) manual), and load it later.
 
-@ref BansheeEngine::Prefab "Prefabs" can be instantiated back into @ref BansheeEngine::SceneObject "SceneObjects" by calling @ref BansheeEngine::Prefab::instantiate "Prefab::instantiate".
+@ref bs::Prefab "Prefabs" can be instantiated back into @ref bs::SceneObject "SceneObjects" by calling @ref bs::Prefab::instantiate "Prefab::instantiate".
 
 For example:
 ~~~~~~~~~~~~~{.cpp}
@@ -109,10 +109,10 @@ HPrefab myPrefab = Prefab::create(mySO);
 HSceneObject clonedSO = myPrefab->instantiate();
 ~~~~~~~~~~~~~
 
-Prefabs are used for more than just cloning. Any scene objects that are instantiated from a @ref BansheeEngine::Prefab "Prefabs" (including the original scene object that the prefab was created from) become permanently linked to that scene object hierarchy. We call such scene objects "prefab instances". You can use @ref BansheeEngine::SceneObject::getPrefabParent "SceneObject::getPrefabParent" to find a @ref BansheeEngine::Prefab "Prefab" that a scene object might be an instance of.
+Prefabs are used for more than just cloning. Any scene objects that are instantiated from a @ref bs::Prefab "Prefabs" (including the original scene object that the prefab was created from) become permanently linked to that scene object hierarchy. We call such scene objects "prefab instances". You can use @ref bs::SceneObject::getPrefabParent "SceneObject::getPrefabParent" to find a @ref bs::Prefab "Prefab" that a scene object might be an instance of.
 
-This can be useful if you have many prefab instances of a particular prefab (e.g. buildings or trees in a level). You can quickly apply changes to all scene objects linked to a particular prefab. Simply make your modifications on an existing prefab instance, or create a new scene object hierarchy. Then call @ref BansheeEngine::Prefab::update "Prefab::update" with the new data. This will replace contents of the prefab with the new hierarchy. After that you can use @ref BansheeEngine::PrefabUtility::updateFromPrefab "PrefabUtility::updateFromPrefab" on all prefab instances and they will replace their contents with the new contents of the prefab.
+This can be useful if you have many prefab instances of a particular prefab (e.g. buildings or trees in a level). You can quickly apply changes to all scene objects linked to a particular prefab. Simply make your modifications on an existing prefab instance, or create a new scene object hierarchy. Then call @ref bs::Prefab::update "Prefab::update" with the new data. This will replace contents of the prefab with the new hierarchy. After that you can use @ref bs::PrefabUtility::updateFromPrefab "PrefabUtility::updateFromPrefab" on all prefab instances and they will replace their contents with the new contents of the prefab.
 
-You are also allowed to make changes to prefab instances. @ref BansheeEngine::PrefabUtility::updateFromPrefab "PrefabUtility::updateFromPrefab" will try its best to keep the changes made, while also updating the underlying hierarchy. Obviously this is not possible if the hierarchy fully changes, but in most cases there will only be minor changes.
+You are also allowed to make changes to prefab instances. @ref bs::PrefabUtility::updateFromPrefab "PrefabUtility::updateFromPrefab" will try its best to keep the changes made, while also updating the underlying hierarchy. Obviously this is not possible if the hierarchy fully changes, but in most cases there will only be minor changes.
 
-In case you made some changes to a prefab instance you can revert back to original prefab state by calling @ref BansheeEngine::PrefabUtility::revertToPrefab "PrefabUtility::revertToPrefab". If you wish to break a link of a scene object with a prefab, call @ref BansheeEngine::SceneObject::breakPrefabLink "PrefabUtility::breakPrefabLink".
+In case you made some changes to a prefab instance you can revert back to original prefab state by calling @ref bs::PrefabUtility::revertToPrefab "PrefabUtility::revertToPrefab". If you wish to break a link of a scene object with a prefab, call @ref bs::SceneObject::breakPrefabLink "PrefabUtility::breakPrefabLink".

Documentation/Manuals/Native/gettingStarted.md

@@ -5,11 +5,11 @@ Getting started								{#gettingStarted}
 This manual offers a quick overview of commonly used Banshee functionality, in order to give you a better idea of how Banshee works. For a fully working example check out the `ExampleProject` project available with the source code.
 
 # Starting an application
-Banshee is started through the @ref BansheeEngine::Application "Application" interface. To start the engine you need to provide it with a description of the primary render window and choose which modules to load. Since Banshee is a plugin based engine you have a selection between multiple modules for each system like render API or physics, and a set of completely optional plugins (like importers for various file formats).
+Banshee is started through the @ref bs::Application "Application" interface. To start the engine you need to provide it with a description of the primary render window and choose which modules to load. Since Banshee is a plugin based engine you have a selection between multiple modules for each system like render API or physics, and a set of completely optional plugins (like importers for various file formats).
 
-After the application is started by calling @ref BansheeEngine::Application::startUp "Application::startUp", you can set up your custom code in the form of @ref BansheeEngine::Component "components" (see later). After that you can run the main loop with @ref BansheeEngine::Application::runMainLoop "Application::runMainLoop" which will execute your code and actually get everything in motion.
+After the application is started by calling @ref bs::Application::startUp "Application::startUp", you can set up your custom code in the form of @ref bs::Component "components" (see later). After that you can run the main loop with @ref bs::Application::runMainLoop "Application::runMainLoop" which will execute your code and actually get everything in motion.
 
-Once the main loop terminates use @ref BansheeEngine::Application::shutDown "Application::shutDown" to clean everything up.
+Once the main loop terminates use @ref bs::Application::shutDown "Application::shutDown" to clean everything up.
 
 ~~~~~~~~~~~~~{.cpp}
 // Descriptor used for initializing the engine
@@ -43,16 +43,16 @@ Application::shutDown();
 Read the [render targets](@ref renderTargets) manual for more information about creating render windows, and the [game objects](@ref gameObjects) manual on how to create your own components.
 
 # Importing resources
-To import a resource from a third party format into an engine-readable format use the @ref BansheeEngine::Importer "Importer" module. A variety of formats like PNG, JPG, PSD, FBX, etc. are supported. Read the [importer](@ref customImporters) manual for more information about importers. 
+To import a resource from a third party format into an engine-readable format use the @ref bs::Importer "Importer" module. A variety of formats like PNG, JPG, PSD, FBX, etc. are supported. Read the [importer](@ref customImporters) manual for more information about importers. 
 
-In the example below we'll import a @ref BansheeEngine::Mesh "Mesh" and a @ref BansheeEngine::Texture "Texture".
+In the example below we'll import a @ref bs::Mesh "Mesh" and a @ref bs::Texture "Texture".
 ~~~~~~~~~~~~~{.cpp}
 HMesh dragonModel = gImporter().import<Mesh>("Dragon.fbx");
 HTexture dragonTexture = gImporter().import<Texture>("Dragon.psd");
 ~~~~~~~~~~~~~
 
 # Setting up a material
-Once we have a mesh and a texture we need some way to apply that texture to the mesh. For that reason we first import a @ref BansheeEngine::Shader "Shader" that describes how is an object rendered, which we then use to create a @ref BansheeEngine::Material "Material" which allows us to apply our previously loaded @ref BansheeEngine::Texture "Texture".
+Once we have a mesh and a texture we need some way to apply that texture to the mesh. For that reason we first import a @ref bs::Shader "Shader" that describes how is an object rendered, which we then use to create a @ref bs::Material "Material" which allows us to apply our previously loaded @ref bs::Texture "Texture".
 
 Read the [material](@ref materials) manual for more information about shaders and materials.
 
@@ -64,11 +64,11 @@ dragonMaterial->setTexture("albedo", dragonTexture);
 ~~~~~~~~~~~~~
 
 # Adding an object for rendering
-To actually make our mesh render with our material, we need to add a @ref BansheeEngine::SceneObject "SceneObject" onto which we attach a @ref BansheeEngine::CRenderable "CRenderable" component. This component allows us to set up a mesh and a material, after which they will be automatically rendered to the active camera.
+To actually make our mesh render with our material, we need to add a @ref bs::SceneObject "SceneObject" onto which we attach a @ref bs::CRenderable "CRenderable" component. This component allows us to set up a mesh and a material, after which they will be automatically rendered to the active camera.
 
-To learn more about @ref BansheeEngine::SceneObject "scene objects" and @ref BansheeEngine::Component "components" read the [game object](@ref gameObjects) manual. You can use the same approach we followed here to add your own custom components, containing custom code.
+To learn more about @ref bs::SceneObject "scene objects" and @ref bs::Component "components" read the [game object](@ref gameObjects) manual. You can use the same approach we followed here to add your own custom components, containing custom code.
 
-You can also read up on the [renderer](@ref renderer) manual to learn more about how the @ref BansheeEngine::CRenderable "CRenderable" components works.
+You can also read up on the [renderer](@ref renderer) manual to learn more about how the @ref bs::CRenderable "CRenderable" components works.
 
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject dragonSO = SceneObject::create("Dragon");
@@ -79,7 +79,7 @@ renderable->setMaterial(dragonMaterial);
 ~~~~~~~~~~~~~
 
 # Adding a scene camera
-In order to actually see our object we need to set up a camera. First create a new @ref BansheeEngine::SceneObject "SceneObject" onto which you can then attach a @ref BansheeEngine::CCamera "CCamera" component. After that we position the @ref BansheeEngine::SceneObject "SceneObject" so it is looking at the object we set up in previous steps.
+In order to actually see our object we need to set up a camera. First create a new @ref bs::SceneObject "SceneObject" onto which you can then attach a @ref bs::CCamera "CCamera" component. After that we position the @ref bs::SceneObject "SceneObject" so it is looking at the object we set up in previous steps.
 
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject sceneCameraSO = SceneObject::create("SceneCamera");
@@ -90,9 +90,9 @@ sceneCameraSO->lookAt(Vector3(0, 0, 0));
 ~~~~~~~~~~~~~
 
 # Adding a GUI element
-Finally you might want to add a GUI to your application. Similar to above, create a new @ref BansheeEngine::SceneObject "SceneObject" onto which we add a new @ref BansheeEngine::CCamera "CCamera" used only for rendering GUI. Since we don't want it to render normal scene objects, we let it's filter `layers` to 0. 
+Finally you might want to add a GUI to your application. Similar to above, create a new @ref bs::SceneObject "SceneObject" onto which we add a new @ref bs::CCamera "CCamera" used only for rendering GUI. Since we don't want it to render normal scene objects, we let it's filter `layers` to 0. 
 
-We also add a @ref BansheeEngine::CGUIWidget "CGUIWidget" component onto the same @ref BansheeEngine::SceneObject "SceneObject", which is used as a container for all GUI elements. After that we add a couple of @ref BansheeEngine::GUIButton "GUIButtons" to the GUI.
+We also add a @ref bs::CGUIWidget "CGUIWidget" component onto the same @ref bs::SceneObject "SceneObject", which is used as a container for all GUI elements. After that we add a couple of @ref bs::GUIButton "GUIButtons" to the GUI.
 
 Read the [GUI](@ref customGUI) manual for more information about GUI.
 

Documentation/Manuals/Native/gpuPrograms.md

@@ -4,21 +4,21 @@ GPU programs									{#gpuPrograms}
 
 GPU programs are programmable parts of the GPU pipeline, in other literature often called shaders (Banshee uses the word shader for a higher level concept, see the [material](@ref materials) manual).
 
-GPU programs in Banshee are represented with the @ref BansheeEngine::GpuProgram "GpuProgram" and @ref BansheeEngine::GpuProgramCore "GpuProgramCore" classes. Both of these provide almost equivalent functionality, but the former is for use on the simulation thread, and the latter is for use on the core thread. If you are confused by the dual nature of the objects, read the [core thread](@ref coreThread) manual. 
+GPU programs in Banshee are represented with the @ref bs::GpuProgram "GpuProgram" and @ref bs::GpuProgramCore "GpuProgramCore" classes. Both of these provide almost equivalent functionality, but the former is for use on the simulation thread, and the latter is for use on the core thread. If you are confused by the dual nature of the objects, read the [core thread](@ref coreThread) manual. 
 
 In this manual we will focus on the simulation thread implementation, and then note the differences in the core thread version at the end.
 
 There are six types of GPU programs: vertex, hull (tesselation control), geometry, domain (tesselation evaluation), fragment (pixel) and compute programs. Each is used for a different purpose but has the same interface. We assume the user is familiar with the GPU pipeline and what the different programs types do. 
 
-Although GPU programs can be used on their own (which we will cover in this manual), they are more commonly used as parts of @ref BansheeEngine::Shader "Shaders". Read the [material](@ref materials) manual for more information.
+Although GPU programs can be used on their own (which we will cover in this manual), they are more commonly used as parts of @ref bs::Shader "Shaders". Read the [material](@ref materials) manual for more information.
 
 # Creating GPU programs {#gpuPrograms_a}
-To create a GPU program call @ref BansheeEngine::GpuProgram::create() "GpuProgram::create". This method expects the following parameters:
+To create a GPU program call @ref bs::GpuProgram::create() "GpuProgram::create". This method expects the following parameters:
  - Source code of the GPU program. This should be in a language supported by the current render API (e.g. HLSL for DirectX, GLSL for OpenGL).
  - Name of the entry point into the GPU program. This is the name of the function that will be called when the program is ran. Must be "main" for OpenGL.
  - Language the source code is written in. This can be "hlsl" or "glsl" by default, but more languages can be added by extensions.
- - @ref BansheeEngine::GpuProgramType "Type" of the GPU program (vertex, fragment, etc.).
- - @ref BansheeEngine::GpuProgramProfile "Profile" of the GPU program. Determines what functionality does the underyling hardware support. Nowadays it is safe to always set this to profile 5.0 unless creating programs for very old hardware.
+ - @ref bs::GpuProgramType "Type" of the GPU program (vertex, fragment, etc.).
+ - @ref bs::GpuProgramProfile "Profile" of the GPU program. Determines what functionality does the underyling hardware support. Nowadays it is safe to always set this to profile 5.0 unless creating programs for very old hardware.
  
 For example if we wanted to create a HLSL fragment program (HLSL source not shown):
 ~~~~~~~~~~~~~{.cpp}
@@ -34,12 +34,12 @@ desc.profile = GPP_FS_5_0;
 SPtr<GpuProgram> myProgram = GpuProgram::create(desc);
 ~~~~~~~~~~~~~ 
  
-Once the GPU program has been created it is not guaranteed to be usable. The compilation of the provided source code could have failed, which you can check by calling @ref BansheeEngine::GpuProgram::isCompiled() "GpuProgram::isCompiled", and retrieve the error message by calling @ref BansheeEngine::GpuProgram::getCompileErrorMessage() "GpuProgram::getCompileErrorMessage". Be aware that both of these methods are only valid after the core thread has initialized the object. You can ensure this by calling @ref BansheeEngine::CoreObject::blockUntilCoreInitialized "GpuProgram::blockUntilCoreInitialized" but be aware this will block the calling thread which can result in a significant performance impact.
+Once the GPU program has been created it is not guaranteed to be usable. The compilation of the provided source code could have failed, which you can check by calling @ref bs::GpuProgram::isCompiled() "GpuProgram::isCompiled", and retrieve the error message by calling @ref bs::GpuProgram::getCompileErrorMessage() "GpuProgram::getCompileErrorMessage". Be aware that both of these methods are only valid after the core thread has initialized the object. You can ensure this by calling @ref bs::CoreObject::blockUntilCoreInitialized "GpuProgram::blockUntilCoreInitialized" but be aware this will block the calling thread which can result in a significant performance impact.
 
 # Using GPU programs for rendering {#gpuPrograms_b}
 To use a GPU program in a draw or dispatch call, you must first create a GPU pipeline object using the relevant GPU programs.
 
-There are two types of pipeline objects: @ref BansheeEngine::GraphicsPipelineState "GraphicsPipelineState" and @ref BansheeEngine::ComputePipelineState "ComputePipelineState".
+There are two types of pipeline objects: @ref bs::GraphicsPipelineState "GraphicsPipelineState" and @ref bs::ComputePipelineState "ComputePipelineState".
 
 Example to create a graphics pipeline:
 ~~~~~~~~~~~~~{.cpp}
@@ -59,7 +59,7 @@ SPtr<GpuProgramCore> computeProgram = ...;
 SPtr<ComputePipelineStateCore> computePipeline = ComputePipelineStateCore::create(computeProgram);
 ~~~~~~~~~~~~~
 
-Once created the pipeline can be bound for rendering by calling @ref BansheeEngine::RenderAPICore::setGraphicsPipeline "RenderAPICore::setGraphicsPipeline" or @ref BansheeEngine::RenderAPI::setComputePipeline "RenderAPI::setComputePipeline".
+Once created the pipeline can be bound for rendering by calling @ref bs::RenderAPICore::setGraphicsPipeline "RenderAPICore::setGraphicsPipeline" or @ref bs::RenderAPI::setComputePipeline "RenderAPI::setComputePipeline".
 
 ~~~~~~~~~~~~~{.cpp}
 // Bind pipeline for use (continued from above)
@@ -76,12 +76,12 @@ Much more detailed information about pipelines and rendering is provided in the
 # GPU program parameters {#gpuPrograms_c}
 Although you can use a GPU program without any parameters, most will require some additional data in order to perform their operations. Program parameters represent data that is static throughout a single GPU program execution (e.g. a draw call). For example, when drawing a 3D object you will usually want to provide a projection matrix that transforms the object from 3D to 2D, according to the camera the user is viewing the object through.
 
-You can access information about GPU program parameters by calling @ref BansheeEngine::GpuProgram::getParamDesc "GpuProgram::getParamDesc". This will return a structure containing information about all GPU parameters used by that GPU program. This includes primitives (int, float, etc.), textures, samplers, buffers and parameter buffers (constant/uniform buffers in DirectX/OpenGL lingo). 
+You can access information about GPU program parameters by calling @ref bs::GpuProgram::getParamDesc "GpuProgram::getParamDesc". This will return a structure containing information about all GPU parameters used by that GPU program. This includes primitives (int, float, etc.), textures, samplers, buffers and parameter buffers (constant/uniform buffers in DirectX/OpenGL lingo). 
 
 You generally don't need to use this information directly. It is instead automatically parsed when you create a GPU pipeline. Once you have a pipeline you can use it to create a *GpuParams* object that allows you to assign values to all parameters of a specific pipeline.
 
 ## GpuParams {#gpuPrograms_b_a}
-@ref BansheeEngine::GpuParams "GpuParams" is a container for all parameters required by a single GPU pipeline (graphics or compute). It allows you to set primitive/texture/sampler/buffer parameters used by the GPU programs, which it stores in an internal buffer. You can then bind it before executing at draw/dispatch call, and the assigned parameters will be used by GPU programs in the current pipeline.
+@ref bs::GpuParams "GpuParams" is a container for all parameters required by a single GPU pipeline (graphics or compute). It allows you to set primitive/texture/sampler/buffer parameters used by the GPU programs, which it stores in an internal buffer. You can then bind it before executing at draw/dispatch call, and the assigned parameters will be used by GPU programs in the current pipeline.
 
 For example to assign a texture and a 2D vector as input to the program we created earlier:
 ~~~~~~~~~~~~~{.cpp}
@@ -104,9 +104,9 @@ As you can see we must first retrieve a handle to the parameter, and then we can
 See the [render API manual](@ref renderAPI) for more information about how to set and bind GPU program parameters.
 
 # Core thread GPU programs {#gpuPrograms_e}
-So far we have only talked about the simulation thread @ref BansheeEngine::GpuProgram "GpuProgram" but have ignored the core thread @ref BansheeEngine::GpuProgramCore "GpuProgramCore". The functionality between the two is mostly the same, with the major difference being that operations performed on the core thread version are immediate. So calls to @ref BansheeEngine::GpuProgramCore::isCompiled() "GpuProgramCore::isCompiled" and @ref BansheeEngine::GpuProgramCore::getCompileErrorMessage() "GpuProgramCore::getCompileErrorMessage" don't require any waiting.
+So far we have only talked about the simulation thread @ref bs::GpuProgram "GpuProgram" but have ignored the core thread @ref bs::GpuProgramCore "GpuProgramCore". The functionality between the two is mostly the same, with the major difference being that operations performed on the core thread version are immediate. So calls to @ref bs::GpuProgramCore::isCompiled() "GpuProgramCore::isCompiled" and @ref bs::GpuProgramCore::getCompileErrorMessage() "GpuProgramCore::getCompileErrorMessage" don't require any waiting.
 
-Addtionally the core thread object can provide information about vertex input declaration. Vertex input declaration is only available for vertex shaders, and it defines in what format does the GPU program expect vertices to be in. This can be useful for setting up your meshes in the valid format. Use @ref BansheeEngine::GpuProgramCore::getInputDeclaration "GpuProgramCore::getInputDeclaration" to retrieve the @ref BansheeEngine::VertexDeclarationCore "VertexDeclaration". Check out the [mesh](@ref meshes) manual for more information on how to use vertex declarations.
+Addtionally the core thread object can provide information about vertex input declaration. Vertex input declaration is only available for vertex shaders, and it defines in what format does the GPU program expect vertices to be in. This can be useful for setting up your meshes in the valid format. Use @ref bs::GpuProgramCore::getInputDeclaration "GpuProgramCore::getInputDeclaration" to retrieve the @ref bs::VertexDeclarationCore "VertexDeclaration". Check out the [mesh](@ref meshes) manual for more information on how to use vertex declarations.
 
 # OpenGL specifics {#gpuPrograms_f}
 When creating vertex inputs for a GPU program written in GLSL a set of built-in variables are provided:

Documentation/Manuals/Native/gui.md

@@ -6,86 +6,86 @@ Sometimes the built-in GUI elements are just not enough, for example when you ne
 
 Before starting you should familiarize yourself how Banshee's GUI works from the users perspective. Make sure to read the scripting GUI manual to understand the basics (although the manual is for scripting, the C++ versions of these methods are essentially equivalent and the same concepts apply).
 
-All GUI elements derive from the base @ref BansheeEngine::GUIElementBase "GUIElementBase" type. The elements can be categorized into two major groups:
- - GUILayout: They derive from @ref BansheeEngine::GUILayout "GUILayout" and do not have any graphics, but instead they control the placement of all elements attached to them.
- - GUIElement: They derive from @ref BansheeEngine::GUIElement "GUIElement", and they're standard GUI elements like buttons, input boxes, sliders and such.
+All GUI elements derive from the base @ref bs::GUIElementBase "GUIElementBase" type. The elements can be categorized into two major groups:
+ - GUILayout: They derive from @ref bs::GUILayout "GUILayout" and do not have any graphics, but instead they control the placement of all elements attached to them.
+ - GUIElement: They derive from @ref bs::GUIElement "GUIElement", and they're standard GUI elements like buttons, input boxes, sliders and such.
  
 You will almost certainly be interested in `GUIElement`, and are unlikely to need to create custom `GUILayout` types.
 
 # Basic GUI element # {#customGUI_a}
-When creating a custom GUI element you will need to override the @ref BansheeEngine::GUIElement "GUIElement" type. The minimum set of methods you need to implement for your custom elements are:
- - @ref BansheeEngine::GUIElement::_getOptimalSize "_getOptimalSize()" - Return the optimal size of your GUI element. This is used for controlling the size of the element in a layout (if it's not fixed). For example if your element was displaying a texture 64x64 in size, then the optimal size should probably return 64x64. If you element is displaying text you can use @ref BansheeEngine::GUIHelper "GUIHelper" to help you calculate the bounds of the text. If displaying something else then it's up to you to determine what constitutes an optimal size.
- - @ref BansheeEngine::GUIElement::_getNumRenderElements() "_getNumRenderElements()" - Return the number of separate elements that your GUIElement consists of. Each element has its own mesh, material and texture. In most cases there is only one element.
- - @ref BansheeEngine::GUIElement::_getMeshInfo() "_getMeshInfo()" - Returns the number of vertices and indices for the mesh of the render element at the specified index (e.g. one quad (4 vertices, 6 indices) if the GUI element displays just one texture). This allows external systems to know how big of a buffer to allocate for the element's mesh. It also returns the type of the mesh which lets external systems know in which format will be vertices be provided (e.g. 2D vertex followed by 2D UV coordinate) when calling @ref BansheeEngine::GUIElement::_fillBuffer() "_fillBuffer()".
- - @ref BansheeEngine::GUIElement::_fillBuffer() "_fillBuffer()" - This is the meat of the `GUIElement` override. It allows you to fill a buffer with vertices, uv coordinates and indices for a mesh for the specified render element. This allows you to fully control the look of your GUI element by providing customized geometry.
- - @ref BansheeEngine::GUIElement::_getMaterial() "_getMaterial()" - Here you should return a material that will be applied to the mesh output in the previous method, as well as an optional texture or color tint. You can choose from a set of pre-built materials or use your own material. 
- - @ref BansheeEngine::GUIElement::updateRenderElementsInternal() "updateRenderElementsInternal()" - Called whenever the element's size or style changes. In this method you should rebuild the element's mesh. (While you could build the mesh in `_fillBuffer` it is inefficient as `_fillBuffer` will get called much more often than `updateRenderElementsInternal` due to mesh batching).
+When creating a custom GUI element you will need to override the @ref bs::GUIElement "GUIElement" type. The minimum set of methods you need to implement for your custom elements are:
+ - @ref bs::GUIElement::_getOptimalSize "_getOptimalSize()" - Return the optimal size of your GUI element. This is used for controlling the size of the element in a layout (if it's not fixed). For example if your element was displaying a texture 64x64 in size, then the optimal size should probably return 64x64. If you element is displaying text you can use @ref bs::GUIHelper "GUIHelper" to help you calculate the bounds of the text. If displaying something else then it's up to you to determine what constitutes an optimal size.
+ - @ref bs::GUIElement::_getNumRenderElements() "_getNumRenderElements()" - Return the number of separate elements that your GUIElement consists of. Each element has its own mesh, material and texture. In most cases there is only one element.
+ - @ref bs::GUIElement::_getMeshInfo() "_getMeshInfo()" - Returns the number of vertices and indices for the mesh of the render element at the specified index (e.g. one quad (4 vertices, 6 indices) if the GUI element displays just one texture). This allows external systems to know how big of a buffer to allocate for the element's mesh. It also returns the type of the mesh which lets external systems know in which format will be vertices be provided (e.g. 2D vertex followed by 2D UV coordinate) when calling @ref bs::GUIElement::_fillBuffer() "_fillBuffer()".
+ - @ref bs::GUIElement::_fillBuffer() "_fillBuffer()" - This is the meat of the `GUIElement` override. It allows you to fill a buffer with vertices, uv coordinates and indices for a mesh for the specified render element. This allows you to fully control the look of your GUI element by providing customized geometry.
+ - @ref bs::GUIElement::_getMaterial() "_getMaterial()" - Here you should return a material that will be applied to the mesh output in the previous method, as well as an optional texture or color tint. You can choose from a set of pre-built materials or use your own material. 
+ - @ref bs::GUIElement::updateRenderElementsInternal() "updateRenderElementsInternal()" - Called whenever the element's size or style changes. In this method you should rebuild the element's mesh. (While you could build the mesh in `_fillBuffer` it is inefficient as `_fillBuffer` will get called much more often than `updateRenderElementsInternal` due to mesh batching).
  
-In order to help you with creating GUI meshes and materials make sure to take a look at @ref BansheeEngine::ImageSprite "ImageSprite" and @ref BansheeEngine::TextSprite "TextSprite" classes. `ImageSprite` can easily generate image geometry of specified size, whether a simple quad or a scale-9-grid image. And `TextSprite` will take a text string, font and additional options as input, and output a set of quads required for text rendering.
+In order to help you with creating GUI meshes and materials make sure to take a look at @ref bs::ImageSprite "ImageSprite" and @ref bs::TextSprite "TextSprite" classes. `ImageSprite` can easily generate image geometry of specified size, whether a simple quad or a scale-9-grid image. And `TextSprite` will take a text string, font and additional options as input, and output a set of quads required for text rendering.
 
-To retrieve materials used for rendering GUI use the @ref BansheeEngine::SpriteManager "SpriteManager", which contains a few built-in materials. You can also create your own materials by implementing the @ref BansheeEngine::SpriteMaterial "SpriteMaterial" interface and registering it with @ref BansheeEngine::SpriteManager "SpriteManager" by calling @ref BansheeEngine::SpriteManager::registerMaterial "SpriteManager::registerMaterial".
+To retrieve materials used for rendering GUI use the @ref bs::SpriteManager "SpriteManager", which contains a few built-in materials. You can also create your own materials by implementing the @ref bs::SpriteMaterial "SpriteMaterial" interface and registering it with @ref bs::SpriteManager "SpriteManager" by calling @ref bs::SpriteManager::registerMaterial "SpriteManager::registerMaterial".
 
-When constructing the `GUIElement` you will also need to provide a style-name (see next chapter) and dimensions to the `GUIElement` constructor. The dimensions determine the initial size of the element. To use the default dimensions just provide the constructor with return value from @ref BansheeEngine::GUIDimensions::create() "GUIDimensions::create()". `GUIElement` will internally use dimensions provided by its style, but providing custom `GUIDimensions` allows you to override the dimensions of the style. For that reason you should provide the user with a constructor that accepts @ref BansheeEngine::GUIOptions "GUIOptions" object, which will contain optional dimension overrides the user can specify. Then you can create a `GUIDimension` by providing the `GUIOptions` object as a parameter.
+When constructing the `GUIElement` you will also need to provide a style-name (see next chapter) and dimensions to the `GUIElement` constructor. The dimensions determine the initial size of the element. To use the default dimensions just provide the constructor with return value from @ref bs::GUIDimensions::create() "GUIDimensions::create()". `GUIElement` will internally use dimensions provided by its style, but providing custom `GUIDimensions` allows you to override the dimensions of the style. For that reason you should provide the user with a constructor that accepts @ref bs::GUIOptions "GUIOptions" object, which will contain optional dimension overrides the user can specify. Then you can create a `GUIDimension` by providing the `GUIOptions` object as a parameter.
 
-It is highly suggested you check out an implementation of @ref BansheeEngine::GUITexture "GUITexture" (in *BsGUITexture.cpp*) for a simple implementation of everything mentioned.
+It is highly suggested you check out an implementation of @ref bs::GUITexture "GUITexture" (in *BsGUITexture.cpp*) for a simple implementation of everything mentioned.
 
 # Style # {#customGUI_b}
 
-Every `GUIElement` has an access to a specific style (@ref BansheeEngine::GUIElementStyle "GUIElementStyle"). You can access the style by calling @ref BansheeEngine::GUIElement::_getStyle() "GUIElement::_getStyle()". The style controls the look of your elements, including its texture, text style and margins. When creating a custom `GUIElement` you normally don't need to worry about style options like margins or padding, but you should take the rest into account when creating your mesh and material. You could also choose to ignore the style at the consequence of not having a skinnable `GUIElement`.
+Every `GUIElement` has an access to a specific style (@ref bs::GUIElementStyle "GUIElementStyle"). You can access the style by calling @ref bs::GUIElement::_getStyle() "GUIElement::_getStyle()". The style controls the look of your elements, including its texture, text style and margins. When creating a custom `GUIElement` you normally don't need to worry about style options like margins or padding, but you should take the rest into account when creating your mesh and material. You could also choose to ignore the style at the consequence of not having a skinnable `GUIElement`.
 
-You might also need to override @ref BansheeEngine::GUIElement::styleUpdated() "GUIElement::styleUpdated()" method that will trigger when the user changes the `GUIElement`'s style, depending on your needs. Although in most cases it will be not necessary as a style change will trigger a call to `updateRenderElementsInternal()`, so you can retrieve the new style information there, as well as rebuild any contents as needed.
+You might also need to override @ref bs::GUIElement::styleUpdated() "GUIElement::styleUpdated()" method that will trigger when the user changes the `GUIElement`'s style, depending on your needs. Although in most cases it will be not necessary as a style change will trigger a call to `updateRenderElementsInternal()`, so you can retrieve the new style information there, as well as rebuild any contents as needed.
 
 You should also provide a style-name for your element. This is a string that will be used for looking up the default style for the element, and you must provide it to the `GUIElement` constructor. This name will be used for looking up the exact `GUIElementStyle` in the currently active `GUISkin` (see later for infomation about GUI skins). You might also allow the user to provide a custom style name if needed (e.g. sometimes its nice to be able to style a `GUIToggle` element so it looks like a `GUIButton`).
 
 # Input # {#customGUI_c}
 
 If you implemented everything so far you should have a functional GUIElement that has a custom look, but it still doesn't accept any input. In order to accept input you must override some or all of the following methods:
- - @ref BansheeEngine::GUIElement::_mouseEvent "GUIElement::_mouseEvent" - Triggered when the mouse moves and/or is clicked
- - @ref BansheeEngine::GUIElement::_textInputEvent "GUIElement::_textInputEvent" - Triggered when the user inputs some text on the keyboard
- - @ref BansheeEngine::GUIElement::_virtualButtonEvent "GUIElement::_virtualButtonEvent" - Triggered when a certain virtual button is pressed.
- - @ref BansheeEngine::GUIElement::_commandEvent "GUIElement::_commandEvent" - Triggers when some kind of a specialized event happens, like losing/gaining focus, deleting text, selecting text, forcing redraw and similar. See @ref BansheeEngine::GUICommandEventType "GUICommandEventType" for an explanation of what each event type does.
+ - @ref bs::GUIElement::_mouseEvent "GUIElement::_mouseEvent" - Triggered when the mouse moves and/or is clicked
+ - @ref bs::GUIElement::_textInputEvent "GUIElement::_textInputEvent" - Triggered when the user inputs some text on the keyboard
+ - @ref bs::GUIElement::_virtualButtonEvent "GUIElement::_virtualButtonEvent" - Triggered when a certain virtual button is pressed.
+ - @ref bs::GUIElement::_commandEvent "GUIElement::_commandEvent" - Triggers when some kind of a specialized event happens, like losing/gaining focus, deleting text, selecting text, forcing redraw and similar. See @ref bs::GUICommandEventType "GUICommandEventType" for an explanation of what each event type does.
  
-Check out `_mouseEvent` implementation in @ref BansheeEngine::GUIButtonBase "GUIButtonBase" for a simple implementation of a mouse hover on/off and click functionality. Check @ref BansheeEngine::GUIInputBox "GUIInputBox" for a more complex implementation of input.
+Check out `_mouseEvent` implementation in @ref bs::GUIButtonBase "GUIButtonBase" for a simple implementation of a mouse hover on/off and click functionality. Check @ref bs::GUIInputBox "GUIInputBox" for a more complex implementation of input.
 
-If working with text input also take a look at @ref BansheeEngine::GUIInputCaret "GUIInputCaret" and @ref BansheeEngine::GUIInputSelection "GUIInputSelection", as they help with input caret movement and text selection. Instances of these classes can be accessed from @ref BansheeEngine::GUIManager "GUIManager" with @ref BansheeEngine::GUIManager::getInputCaretTool() "getInputCaretTool()" and @ref BansheeEngine::GUIManager::getInputSelectionTool() "getInputSelectionTool()". This is completely optional and you may choose to handle these manually. See @ref BansheeEngine::GUIInputBox "GUIInputBox" for example usage.
+If working with text input also take a look at @ref bs::GUIInputCaret "GUIInputCaret" and @ref bs::GUIInputSelection "GUIInputSelection", as they help with input caret movement and text selection. Instances of these classes can be accessed from @ref bs::GUIManager "GUIManager" with @ref bs::GUIManager::getInputCaretTool() "getInputCaretTool()" and @ref bs::GUIManager::getInputSelectionTool() "getInputSelectionTool()". This is completely optional and you may choose to handle these manually. See @ref bs::GUIInputBox "GUIInputBox" for example usage.
 
 # Updating # {#customGUI_d}
 
 If your element allows the user to update certain contents of it after creation (i.e. it's not static), you need to notify the GUI system so it knows when to rebuild the element. For example if your GUI element displays a text string you might provide a `setText` method that allows the user to change what is displayed. When that is done the GUI system will need to update the batched GUI mesh, update the GUI element's mesh and/or update the layout position/size of the element.
 
 There are three ways to notify the GUI system the element is dirty, each more expensive in performance than the previous:
- - @ref BansheeEngine::GUIElement::_markMeshAsDirty() "_markMeshAsDirty()" - Causes the batched GUI mesh to be re-assembled, will cause a call to `_fillBuffer`. Call this if element's size didn't change (e.g. when its position, or depth changes). Batched GUI mesh is a mesh managed by the GUI system that consists of multiple GUI elements sharing the same material properties (used to improve rendering performance).
- - @ref BansheeEngine::GUIElement::_markContentAsDirty() "_markContentAsDirty()" - Has the same effect as `_markMeshDirty()`, but will also trigger an `updateRenderElementsInternal` call so the GUI element mesh will be fully rebuilt. Call this when contents of the GUI element change, but not its size (e.g. changing a texture but it is the same dimensions as the old one.)
- - @ref BansheeEngine::GUIElement::_markLayoutAsDirty() "_markLayoutAsDirty()" - Has the same effect as `_markContentDirty()`, but will also cause the layout system to recalculate the element's position and size. This can be very expensive as this will generally trigger layout updates for all siblings and children, potentially even parent GUI elements. Call this when element changes and no other dirty calls are appropriate. Normally you have to call this whenever the element's size changes.
+ - @ref bs::GUIElement::_markMeshAsDirty() "_markMeshAsDirty()" - Causes the batched GUI mesh to be re-assembled, will cause a call to `_fillBuffer`. Call this if element's size didn't change (e.g. when its position, or depth changes). Batched GUI mesh is a mesh managed by the GUI system that consists of multiple GUI elements sharing the same material properties (used to improve rendering performance).
+ - @ref bs::GUIElement::_markContentAsDirty() "_markContentAsDirty()" - Has the same effect as `_markMeshDirty()`, but will also trigger an `updateRenderElementsInternal` call so the GUI element mesh will be fully rebuilt. Call this when contents of the GUI element change, but not its size (e.g. changing a texture but it is the same dimensions as the old one.)
+ - @ref bs::GUIElement::_markLayoutAsDirty() "_markLayoutAsDirty()" - Has the same effect as `_markContentDirty()`, but will also cause the layout system to recalculate the element's position and size. This can be very expensive as this will generally trigger layout updates for all siblings and children, potentially even parent GUI elements. Call this when element changes and no other dirty calls are appropriate. Normally you have to call this whenever the element's size changes.
 
-When updating your GUI element with new contents consider using the provided @ref BansheeEngine::GUIContent "GUIContent" type, in order to stay consistent with the built-in elements. It allows you to specify an image, text and a tooltip all in one. But this is completely optional.
+When updating your GUI element with new contents consider using the provided @ref bs::GUIContent "GUIContent" type, in order to stay consistent with the built-in elements. It allows you to specify an image, text and a tooltip all in one. But this is completely optional.
  
 # Various # {#customGUI_e}
  
 ## GUIWidget ## {#customGUI_d_a}
  
-Every `GUIElement` is internally part of a specific `GUIWidget`. A `GUIWidget` is a @ref BansheeEngine::Component "Component" (@ref BansheeEngine::CGUIWidget "CGUIWidget") that can be attached to a scene object, and transformed like one. This allows you to perform arbitrary transformations on GUI elements.
+Every `GUIElement` is internally part of a specific `GUIWidget`. A `GUIWidget` is a @ref bs::Component "Component" (@ref bs::CGUIWidget "CGUIWidget") that can be attached to a scene object, and transformed like one. This allows you to perform arbitrary transformations on GUI elements.
 
-You attach elements to a `GUIWidget` by adding them to the widget's @ref BansheeEngine::GUIPanel "GUIPanel". Each widget has a `GUIPanel` which is a `GUILayout` object that allows you to manually position GUI elements within it. Every GUI element's top level parent must be such a panel or they will not be rendered.
+You attach elements to a `GUIWidget` by adding them to the widget's @ref bs::GUIPanel "GUIPanel". Each widget has a `GUIPanel` which is a `GUILayout` object that allows you to manually position GUI elements within it. Every GUI element's top level parent must be such a panel or they will not be rendered.
 
 `GUIWidget` also allows you to control to which camera should the GUI elements within it be rendered. The camera provides the dimensions of the widget, and in turn the available area for all child GUI elements.
 
-Every style that a `GUIElement` uses is retrieved from its parent `GUIWidget`. GUIWidget contains a @ref BansheeEngine::GUISkin "GUISkin" object which has a key-value map where style-names are mapped to particular GUI element styles. Changing the `GUISkin`, or moving a `GUIElement` to a widget with a different style will trigger the GUI element rebuild, so it can apply the new style options.
+Every style that a `GUIElement` uses is retrieved from its parent `GUIWidget`. GUIWidget contains a @ref bs::GUISkin "GUISkin" object which has a key-value map where style-names are mapped to particular GUI element styles. Changing the `GUISkin`, or moving a `GUIElement` to a widget with a different style will trigger the GUI element rebuild, so it can apply the new style options.
 
 ## GUIManager ## {#customGUI_d_b}
 
-@ref BansheeEngine::GUIManager "GUIManager" is the top level GUI manager that handles almost everything GUI related. It keeps tracks of all `GUIWidget`s and `GUIElement`s. It updates layout when element properties change, rebuilds the GUI meshes, sets up GUI materials and ultimately renders the GUI. It also dispatches all GUI input events.
+@ref bs::GUIManager "GUIManager" is the top level GUI manager that handles almost everything GUI related. It keeps tracks of all `GUIWidget`s and `GUIElement`s. It updates layout when element properties change, rebuilds the GUI meshes, sets up GUI materials and ultimately renders the GUI. It also dispatches all GUI input events.
 
 If you need to do some very deep changes to the GUI system this is where you do it.
 
 ## Text ##  {#customGUI_d_c}
 
-If you ever require to render text completely manually (perhaps even outside of the GUI system), take a look at @ref BansheeEngine::TextData "TextData". It will take a text string with a font and optional bounds as input, and output (optionally) word wrapped text in the form of words and lines, from which you can easily retrieve a mesh for rendering.
+If you ever require to render text completely manually (perhaps even outside of the GUI system), take a look at @ref bs::TextData "TextData". It will take a text string with a font and optional bounds as input, and output (optionally) word wrapped text in the form of words and lines, from which you can easily retrieve a mesh for rendering.
  
 ## Scripting integration ## {#customGUI_d_d}
 
 Once you have a custom GUI element you might want to expose it to the scripting API. Take a look at the [scripting interop guide](@ref scripting) to learn how to create scripting API objects. 
 
-Every GUI scripting interop object must implement @ref BansheeEngine::TScriptGUIElement "TScriptGUIElement", but other than that creating GUI interop objects is the same as the general case described in the guide above. See @ref BansheeEngine::ScriptGUITexture "ScriptGUITexture" in `BsScriptGUITexture.cpp` for an example.
+Every GUI scripting interop object must implement @ref bs::TScriptGUIElement "TScriptGUIElement", but other than that creating GUI interop objects is the same as the general case described in the guide above. See @ref bs::ScriptGUITexture "ScriptGUITexture" in `BsScriptGUITexture.cpp` for an example.
 
 Creating managed GUI objects is again the same as the general case. Take a look at the managed GUITexture implementation in `GUITexture.cs` for an example.

Documentation/Manuals/Native/import.md

@@ -2,24 +2,24 @@ Creating custom importers						{#customImporters}
 ===============
 [TOC]
 
-Importers process a raw resource in a third-party format (like FBX mesh or a PNG image) into an engine-ready format (e.g. a @ref BansheeEngine::Mesh "Mesh" or a @ref BansheeEngine::Texture "Texture"). Banshee has an extensible importer system so you may easily add your own, either for existing resource types, or for new ones. If you are also interested in creating new resource types check out [this manual](@ref resources).
+Importers process a raw resource in a third-party format (like FBX mesh or a PNG image) into an engine-ready format (e.g. a @ref bs::Mesh "Mesh" or a @ref bs::Texture "Texture"). Banshee has an extensible importer system so you may easily add your own, either for existing resource types, or for new ones. If you are also interested in creating new resource types check out [this manual](@ref resources).
 
-On the user-facing level resource import works through the @ref BansheeEngine::Importer "Importer" module. You call its @ref BansheeEngine::Importer::import "Importer::import" method which takes a path to the resource you want to import, and the system automatically finds the necessary importer plugin (if one is available) and returns the resource in an engine ready format. Optionally you can also supply the importer with @ref BansheeEngine::ImportOptions "ImportOptions" to control resource import in more detail.
+On the user-facing level resource import works through the @ref bs::Importer "Importer" module. You call its @ref bs::Importer::import "Importer::import" method which takes a path to the resource you want to import, and the system automatically finds the necessary importer plugin (if one is available) and returns the resource in an engine ready format. Optionally you can also supply the importer with @ref bs::ImportOptions "ImportOptions" to control resource import in more detail.
 
-To implement your own importer you need to implement the @ref BansheeEngine::SpecificImporter "SpecificImporter" interface.
+To implement your own importer you need to implement the @ref bs::SpecificImporter "SpecificImporter" interface.
 
 # Implementing SpecificImporter # {#customImporters_a}
 Implementing this interface involves implementation of the following methods:
- * @ref BansheeEngine::SpecificImporter::isExtensionSupported "isExtensionSupported" - Receives an extension and returns true or false depending if the importer can process that file. Used by the importer to find which importer plugin to use for import of a specific file.
- * @ref BansheeEngine::SpecificImporter::isMagicNumberSupported "isMagicNumberSupported" - Similar to the method above, but receives a magic number (first few bytes of a file) instead of the extension, as this is the more common way of identifying files on non-Windows systems.
- * @ref BansheeEngine::SpecificImporter::import "import" - Receives a path to a file, as well as a set of import options. This is the meat of the importer where you will read the file and convert it into engine ready format. When done the method returns a @ref BansheeEngine::Resource "Resource" of a valid type, or null if it failed. The method should take into account the import options it was provided (if your importer supports any).
+ * @ref bs::SpecificImporter::isExtensionSupported "isExtensionSupported" - Receives an extension and returns true or false depending if the importer can process that file. Used by the importer to find which importer plugin to use for import of a specific file.
+ * @ref bs::SpecificImporter::isMagicNumberSupported "isMagicNumberSupported" - Similar to the method above, but receives a magic number (first few bytes of a file) instead of the extension, as this is the more common way of identifying files on non-Windows systems.
+ * @ref bs::SpecificImporter::import "import" - Receives a path to a file, as well as a set of import options. This is the meat of the importer where you will read the file and convert it into engine ready format. When done the method returns a @ref bs::Resource "Resource" of a valid type, or null if it failed. The method should take into account the import options it was provided (if your importer supports any).
  
 You may also optionally implement the following methods:
- * @ref BansheeEngine::SpecificImporter::createImportOptions "createImportOptions" - If your importer supports specific import options this should return a brand new empty instance of such import options. These will eventually be provided to the @ref BansheeEngine::SpecificImporter::import "import" method. Import options must implement @ref BansheeEngine::ImportOptions "ImportOptions" and you may include any necessary fields in your implementation. You must also [implement RTTI](@ref rtti) for your custom import options. You should strive to use same type of import options for same resource types (for example all textures use @ref BansheeEngine::TextureImportOptions "TextureImportOptions").
- * @ref BansheeEngine::SpecificImporter::importAll "importAll" - Sometimes a single third-party resource can contain multiple engine resources (for a example an .fbx may contain both a mesh and animation). In such cases you will want to implement this method, which allows you to return multiple resources, each with a unique identifier. One of the resources must always be considered primary, and that's the resource that should be returned by @ref BansheeEngine::SpecificImporter::import "import" (others should be ignored). In this method the primary resource must have the "primary" identifier, while you are free to add custom identifiers for every other resource.
+ * @ref bs::SpecificImporter::createImportOptions "createImportOptions" - If your importer supports specific import options this should return a brand new empty instance of such import options. These will eventually be provided to the @ref bs::SpecificImporter::import "import" method. Import options must implement @ref bs::ImportOptions "ImportOptions" and you may include any necessary fields in your implementation. You must also [implement RTTI](@ref rtti) for your custom import options. You should strive to use same type of import options for same resource types (for example all textures use @ref bs::TextureImportOptions "TextureImportOptions").
+ * @ref bs::SpecificImporter::importAll "importAll" - Sometimes a single third-party resource can contain multiple engine resources (for a example an .fbx may contain both a mesh and animation). In such cases you will want to implement this method, which allows you to return multiple resources, each with a unique identifier. One of the resources must always be considered primary, and that's the resource that should be returned by @ref bs::SpecificImporter::import "import" (others should be ignored). In this method the primary resource must have the "primary" identifier, while you are free to add custom identifiers for every other resource.
  
-Once your importer is implemented you must register it with the global importer system. You may do this by calling @ref BansheeEngine::Importer::_registerAssetImporter "_registerAssetImporter" with an instance of your importer. It should be allocated using the general allocator and will be freed automatically on system shutdown.
+Once your importer is implemented you must register it with the global importer system. You may do this by calling @ref bs::Importer::_registerAssetImporter "_registerAssetImporter" with an instance of your importer. It should be allocated using the general allocator and will be freed automatically on system shutdown.
 
-Optionally you can do this on the higher level by providing a list of importers to @ref BansheeEngine::Application::startUp "Application::startUp" method. This methods expects a list of dynamic library file-names, which means you must implement your importer as a [plugin](@ref customPlugins).
+Optionally you can do this on the higher level by providing a list of importers to @ref bs::Application::startUp "Application::startUp" method. This methods expects a list of dynamic library file-names, which means you must implement your importer as a [plugin](@ref customPlugins).
 
-See @ref BansheeEngine::PlainTextImporter "PlainTextImporter" for an implementation of a very simple importer that just imports raw textual files.
+See @ref bs::PlainTextImporter "PlainTextImporter" for an implementation of a very simple importer that just imports raw textual files.

Documentation/Manuals/Native/materials.md

@@ -2,11 +2,11 @@ Materials									{#materials}
 ===============
 [TOC]
 
-A material controls how is an object rendered. In Banshee it is represented with @ref BansheeEngine::Material "Material" and @ref BansheeEngine::MaterialCore "MaterialCore" classes. Both of these provide almost equivalent functionality, but the former is for use on the simulation thread, and the latter is for use on the core thread. If you are confused by the dual nature of the objects, read the [core thread](@ref coreThread) manual. 
+A material controls how is an object rendered. In Banshee it is represented with @ref bs::Material "Material" and @ref bs::MaterialCore "MaterialCore" classes. Both of these provide almost equivalent functionality, but the former is for use on the simulation thread, and the latter is for use on the core thread. If you are confused by the dual nature of the objects, read the [core thread](@ref coreThread) manual. 
 
-We'll focus on the simulation thread @ref BansheeEngine::Material "Material" throughout this manual, but aside from the `Core` suffix there are no major differences between the two interfaces.
+We'll focus on the simulation thread @ref bs::Material "Material" throughout this manual, but aside from the `Core` suffix there are no major differences between the two interfaces.
 
-Internally material contains a set of GPU programs, render states and GPU program parameters. GPU programs and render states are immutable and are controlled by the @ref BansheeEngine::Shader "Shader" assigned to the material. The parameters can be modified by the interface provided by the material, and this parameter access actually constitutes the bulk of the material's interface. Essentially materials can be thought of as shader "instances".
+Internally material contains a set of GPU programs, render states and GPU program parameters. GPU programs and render states are immutable and are controlled by the @ref bs::Shader "Shader" assigned to the material. The parameters can be modified by the interface provided by the material, and this parameter access actually constitutes the bulk of the material's interface. Essentially materials can be thought of as shader "instances".
 
 Since shaders are such intrical parts of materials, we'll explain how to create them before continuing with the discussion about materials.
 
@@ -15,15 +15,15 @@ A shader is a group of GPU programs and render states that fully control the ren
 
 To learn more about GPU programs and render states read the [GPU program](@ref gpuPrograms) and [render API](@ref renderAPI) manuals.
 
-A shader can actually contain multiple sets of GPU programs and render states. Such set is called a @ref BansheeEngine::Technique "Technique", but only one technique can ever be active for rendering. Different techniques can be used for supporting different render API's or renderers (e.g. one technique for DirectX 11, other for OpenGL). Each shader can contain one or multiple techniques and the most appropriate technique will be chosen according to the active render API and renderer.
+A shader can actually contain multiple sets of GPU programs and render states. Such set is called a @ref bs::Technique "Technique", but only one technique can ever be active for rendering. Different techniques can be used for supporting different render API's or renderers (e.g. one technique for DirectX 11, other for OpenGL). Each shader can contain one or multiple techniques and the most appropriate technique will be chosen according to the active render API and renderer.
 
-Each technique contains one or multiple @ref BansheeEngine::Pass "passes". Each pass contains a set of GPU programs and render states. When rendering using a certain technique each pass will be executed one after another. This allows you to render objects that require more complex rendering that requires multiple separate steps.
+Each technique contains one or multiple @ref bs::Pass "passes". Each pass contains a set of GPU programs and render states. When rendering using a certain technique each pass will be executed one after another. This allows you to render objects that require more complex rendering that requires multiple separate steps.
 
 To summarize, the relationship between materials, shaders, techniques and passes is:
  - Material [contains one]-> Shader [contains one or multiple]-> Technique [contains one or multiple]-> Pass
 
 ## Pass {#materials_a_a}
-Before we can create a shader we must first know how to create a @ref BansheeEngine::Pass "Pass". Pass can be created by filling out a @ref BansheeEngine::PASS_DESC "PASS_DESC" descriptor and passing it to @ref BansheeEngine::Pass::create "Pass::create". @ref BansheeEngine::PASS_DESC "PASS_DESC" is fairly simple and it expects a set of GPU programs and render states. For example:
+Before we can create a shader we must first know how to create a @ref bs::Pass "Pass". Pass can be created by filling out a @ref bs::PASS_DESC "PASS_DESC" descriptor and passing it to @ref bs::Pass::create "Pass::create". @ref bs::PASS_DESC "PASS_DESC" is fairly simple and it expects a set of GPU programs and render states. For example:
 ~~~~~~~~~~~~~{.cpp}
 SPtr<GpuProgram> vertexProg = ...;
 SPtr<GpuProgram> fragmentProg = ...;
@@ -42,12 +42,12 @@ SPtr<Pass> pass = Pass::create(desc);
 [GPU program](@ref gpuPrograms) and [render API](@ref renderAPI) manuals teach you how to create GPU programs and render states. 
 
 ## Technique {#materials_a_b}
-Now that we know how to create a pass, we can use one or multiple passes to initialize a @ref BansheeEngine::Technique "Technique". A technique is just a container for passes for a specific render API and renderer.
+Now that we know how to create a pass, we can use one or multiple passes to initialize a @ref bs::Technique "Technique". A technique is just a container for passes for a specific render API and renderer.
 
-To create a technique call @ref BansheeEngine::Technique::create "Technique::create" and provide it with:
+To create a technique call @ref bs::Technique::create "Technique::create" and provide it with:
  - One or multiple passes
- - Supported render API name: Use built-in `RenderAPIAny` to signal that the technique works on any API, or use the render API identifier to signal that it only works on a specific one. By default supported identifiers are: `"VulkanRenderAPI"`, `"D3D11RenderAPI"`, `"GLRenderAPI"`, but more can be added via plugins. In general those identifiers are returned from @ref BansheeEngine::RenderAPICore::getName "RenderAPICore::getName". Most users should be okay by providing `RenderAPIAny`.
- - Supported renderer name: Use built-in `RendererAny` to signal that the technique works on any renderer, or use the renderer identifier to signal that it only works on a specific one. By default the only supported identifier is `"RenderBeast"`, but more can be added via plugins. In general those identifiers are returned from @ref BansheeEngine::Renderer::getName "Renderer::getName". Most users should be okay by providing `RendererAny`.
+ - Supported render API name: Use built-in `RenderAPIAny` to signal that the technique works on any API, or use the render API identifier to signal that it only works on a specific one. By default supported identifiers are: `"VulkanRenderAPI"`, `"D3D11RenderAPI"`, `"GLRenderAPI"`, but more can be added via plugins. In general those identifiers are returned from @ref bs::RenderAPICore::getName "RenderAPICore::getName". Most users should be okay by providing `RenderAPIAny`.
+ - Supported renderer name: Use built-in `RendererAny` to signal that the technique works on any renderer, or use the renderer identifier to signal that it only works on a specific one. By default the only supported identifier is `"RenderBeast"`, but more can be added via plugins. In general those identifiers are returned from @ref bs::Renderer::getName "Renderer::getName". Most users should be okay by providing `RendererAny`.
  - An optional list of tags that allows renderer to pick which technique to use when rendering objects. Can be left empty in most cases.
 
 For example:
@@ -59,15 +59,15 @@ SPtr<Technique> technique = Technique::create(RenderAPIAny, RendererAny, { pass
 ~~~~~~~~~~~~~
  
 ## Creating a shader {#materials_a_c}
-Now that we have a technique we can create our shader by calling @ref BansheeEngine::Shader::create "Shader::create", which expects a list of techniques, name of the shader and @ref BansheeEngine::TSHADER_DESC<T> "SHADER_DESC" as input.
+Now that we have a technique we can create our shader by calling @ref bs::Shader::create "Shader::create", which expects a list of techniques, name of the shader and @ref bs::TSHADER_DESC<T> "SHADER_DESC" as input.
 	
-@ref BansheeEngine::TSHADER_DESC<T> "SHADER_DESC" allows you to specify a set of optional parameters to control how the shader rendering works:
+@ref bs::TSHADER_DESC<T> "SHADER_DESC" allows you to specify a set of optional parameters to control how the shader rendering works:
   - `queueSortType` - Controls how should objects rendered with this shader be sorted. Either front to back, back to front, or without sorting. This property can be used for the active renderer to properly render objects, as certain effects (like transparency) require their objects to be rendered in a specific order.
   - `queuePriority` - Controls when should objects rendered with this shader be rendered relative to other objects. Objects with higher priority will be rendered before ones with lower priority, and sorting due to `queueSortType` will never sort outside of priority groups. This can allow you to render a certain type of objects before all others (e.g. all opaque objects should be rendered before transparent ones).
   - `separablePasses` - An optimization hint to the renderer that can improve performance when turned on. Only relevant if the shader has techniques with multiple passes. When true the renderer will not necessarily execute passes right after another, but might render other objects in-between passes. This can reduce state switching as multiple objects can be rendered with a single pass, but is only relevant for algorithms that can handle such a process (most can't).
   - `flags` - Allows you to provide custom flags to the renderer. Interpretation of this value depends on the renderer used and by default its value is ignored.
 	
-@ref BansheeEngine::TSHADER_DESC<T> "SHADER_DESC" also expects you to provide a set of parameters accepted by the GPU programs used by the passes. We'll explain parameters later, but for now assume we're creating a shader with no parameters:
+@ref bs::TSHADER_DESC<T> "SHADER_DESC" also expects you to provide a set of parameters accepted by the GPU programs used by the passes. We'll explain parameters later, but for now assume we're creating a shader with no parameters:
 ~~~~~~~~~~~~~{.cpp}
 SPtr<Technique> technique = ...;
 	
@@ -83,13 +83,13 @@ SPtr<Shader> shader = Shader::create("MyShader", desc, { technique });
 ## Shader parameters {#materials_a_d}
 Shader parameters allow you to change values of parameters in GPU programs. They are similar to GPU program parameters described in the [GPU program](@ref gpuPrograms) manual, but they set the values on all GPU programs on all passes, instead of working only on a single GPU program. Additionally they also support renderer semantics (see below).
 
-Shader only defines the parameter interface (their name, type and description), but actual parameters can only be changed from a @ref BansheeEngine::Material "Material", as we'll show later. To create the parameter interface you must populate the @ref BansheeEngine::TSHADER_DESC<T> "SHADER_DESC" structure by calling one of the @ref BansheeEngine::TSHADER_DESC<T>::addParameter "SHADER_DESC::addParameter" overloads.
+Shader only defines the parameter interface (their name, type and description), but actual parameters can only be changed from a @ref bs::Material "Material", as we'll show later. To create the parameter interface you must populate the @ref bs::TSHADER_DESC<T> "SHADER_DESC" structure by calling one of the @ref bs::TSHADER_DESC<T>::addParameter "SHADER_DESC::addParameter" overloads.
 
 Parameters come in two variants:
- - Data - These are primitive types like float, int or bool. This includes their vector and array variants. Check @ref BansheeEngine::GpuParamDataType "GpuParamDataType" for a list of all data parameter types.
- - Object - These are object types like texture, buffer or sampler state. Check @ref BansheeEngine::GpuParamObjectType "GpuParamObjectType" for a list of all object parameter types.
+ - Data - These are primitive types like float, int or bool. This includes their vector and array variants. Check @ref bs::GpuParamDataType "GpuParamDataType" for a list of all data parameter types.
+ - Object - These are object types like texture, buffer or sampler state. Check @ref bs::GpuParamObjectType "GpuParamObjectType" for a list of all object parameter types.
 
-Each parameter must have a name and a GPU variable it maps to. The name can be anything you like (as long as its unique) and it will be used for accessing the parameter from the @ref BansheeEngine::Material "Material". The GPU variable must be a name of the GPU variable defined in GPU program code. This is the name contained in @ref BansheeEngine::GpuParamDesc "GpuParamDesc" which is returned from @ref BansheeEngine::GpuProgram::getParamDesc "GpuProgram::getParamDesc". 
+Each parameter must have a name and a GPU variable it maps to. The name can be anything you like (as long as its unique) and it will be used for accessing the parameter from the @ref bs::Material "Material". The GPU variable must be a name of the GPU variable defined in GPU program code. This is the name contained in @ref bs::GpuParamDesc "GpuParamDesc" which is returned from @ref bs::GpuProgram::getParamDesc "GpuProgram::getParamDesc". 
 
 You must also provide the type of the parameter. This way the system can know how to distinguish parameters in case multiple GPU programs have the same-named GPU variable but with different type. For data parameters you can also provide the size of the array (in case the GPU variable is an array), or the size of a single element (only needed for structs).
 
@@ -113,13 +113,13 @@ SPtr<Shader> shader = Shader::create("MyShader", desc, { technique });
 ~~~~~~~~~~~~~
 
 ### Advanced parameters {#materials_a_d_a}
-@ref BansheeEngine::SHADER_DESC::addParameter "SHADER_DESC::addParameter" also supports two additional arguments we didn't touch on in the previous section: renderer semantic and default value.
+@ref bs::SHADER_DESC::addParameter "SHADER_DESC::addParameter" also supports two additional arguments we didn't touch on in the previous section: renderer semantic and default value.
 
 Renderer semantic allows you to give the parameter a unique name that can be recognized by the active renderer. The renderer can then use these semantics to automatically assign values to them while rendering. For example the "WVP" semantic might notify the renderer to populate this parameter with the world-view-projection matrix. This way the user is not responsible for setting such parameters manually.
 
 The list of supported semantics depends on the currently active renderer. The default renderer is still in the implementation phase and supports no semantics. Read more about semantics in the [renderer](@ref renderer) manual.
 
-The parameter default value allows you to provide a value that will be used for initializing the parameter when a @ref BansheeEngine::Material "Material" is initially constructed. For data parameters the default value is a provided as a raw block of memory, and for object parameters it can be a reference to a @ref BansheeEngine::Texture "Texture" or a @ref BansheeEngine::SamplerState "SamplerState".
+The parameter default value allows you to provide a value that will be used for initializing the parameter when a @ref bs::Material "Material" is initially constructed. For data parameters the default value is a provided as a raw block of memory, and for object parameters it can be a reference to a @ref bs::Texture "Texture" or a @ref bs::SamplerState "SamplerState".
 
 An extended example from above with semantics and default values:
 ~~~~~~~~~~~~~{.cpp}
@@ -149,10 +149,10 @@ HShader shader = gImporter().import<Shader>("myShader.bsl");
 This is the preferred way of creating shaders, as its much simpler, concise and flexible. Learn about BSLFX syntax in the [BSLFX](@ref bslfx) manual.
 
 ## Saving/loading {#materials_a_d_c}
-A shader is a @ref BansheeEngine::Resource "Resource" and can be saved/loaded like any other. See the [resource](@ref resources) manual.
+A shader is a @ref bs::Resource "Resource" and can be saved/loaded like any other. See the [resource](@ref resources) manual.
 
 # Creating a material {#materials_b}
-Now that we finally have a shader we can create our material by calling @ref BansheeEngine::Material::create "Material::create" like so:
+Now that we finally have a shader we can create our material by calling @ref bs::Material::create "Material::create" like so:
 ~~~~~~~~~~~~~{.cpp}
 HShader shader = ...;
 HMaterial material = Material::create(shader);
@@ -162,8 +162,8 @@ This will select the most appropriate technique from the shader and initialize t
 
 # Material parameters {#materials_c}
 Material allows you to read and write parameters in two different ways:
- - By calling various set/get methods like @ref BansheeEngine::Material::getVec4 "Material::getVec4" or @ref BansheeEngine::Material::setVec4 "Material::setVec4" which read and write the parameter value directly.
- - By retrieving parameter handle by calling @ref BansheeEngine::Material::getParamVec4 "Material::getParamVec4" which returns a handle object @ref BansheeEngine::TMaterialDataParam<T, false> "MaterialParamVec4". This object can then be used by calling its @ref BansheeEngine::TMaterialDataParam<T, false>::get "MaterialParamVec4::get" and @ref BansheeEngine::TMaterialDataParam<T, false>::set "MaterialParamVec4::set" methods similar to above.
+ - By calling various set/get methods like @ref bs::Material::getVec4 "Material::getVec4" or @ref bs::Material::setVec4 "Material::setVec4" which read and write the parameter value directly.
+ - By retrieving parameter handle by calling @ref bs::Material::getParamVec4 "Material::getParamVec4" which returns a handle object @ref bs::TMaterialDataParam<T, false> "MaterialParamVec4". This object can then be used by calling its @ref bs::TMaterialDataParam<T, false>::get "MaterialParamVec4::get" and @ref bs::TMaterialDataParam<T, false>::set "MaterialParamVec4::set" methods similar to above.
  
 We have shown an example for a 4D vector but similarly named methods exist for other parameter types. The second method of accessing the parameters is prefered as it allows you to save the handle to the parameter, which avoids a potentially expensive name lookup every time we need to access it.
 
@@ -183,13 +183,13 @@ MaterialParamTexture albedoParam = material->getParamTexture("AlbedoTex");
 albedoParam.set(Texture::White);
 ~~~~~~~~~~~~~
 # Rendering with material {#materials_d}
-From the simulation thread you cannot use material to render manually (you must instead use GPU programs and states manually as described by the [render API](@ref renderAPI) manual). You are instead expected to set the material on a @ref BansheeEngine::Renderable "Renderable" object which will then be used for rendering automatically. Read the [renderer](@ref renderer) manual for more information.
+From the simulation thread you cannot use material to render manually (you must instead use GPU programs and states manually as described by the [render API](@ref renderAPI) manual). You are instead expected to set the material on a @ref bs::Renderable "Renderable" object which will then be used for rendering automatically. Read the [renderer](@ref renderer) manual for more information.
 
-Core thread gives you more flexibility and you can use @ref BansheeEngine::RendererUtility::setPass "RendererUtility::setPass" to bind a specific pass from a material to the pipeline, and @ref BansheeEngine::RendererUtility::setPassParams "RendererUtility::setPassParams" to bind material parameters for a specific pass. 
+Core thread gives you more flexibility and you can use @ref bs::RendererUtility::setPass "RendererUtility::setPass" to bind a specific pass from a material to the pipeline, and @ref bs::RendererUtility::setPassParams "RendererUtility::setPassParams" to bind material parameters for a specific pass. 
 
-In order to retrieve a set of per-pass @ref BansheeEngine::GpuParams "GpuParams" that can be used for binding directly to the pipeline, call @ref BansheeEngine::Material::createParamsSet "Material::createParamsSet", followed by @ref BansheeEngine::Material::updateParamsSet "Material::updateParamsSet". You are required to call @ref BansheeEngine::Material::updateParamsSet "Material::updateParamsSet" whenever material parameters change, in order to transfer the new data to @ref BansheeEngine::GpuParams "GpuParams".
+In order to retrieve a set of per-pass @ref bs::GpuParams "GpuParams" that can be used for binding directly to the pipeline, call @ref bs::Material::createParamsSet "Material::createParamsSet", followed by @ref bs::Material::updateParamsSet "Material::updateParamsSet". You are required to call @ref bs::Material::updateParamsSet "Material::updateParamsSet" whenever material parameters change, in order to transfer the new data to @ref bs::GpuParams "GpuParams".
 
 After pass and pass parameters are bound you can follow them with draw calls as described in the [render API](@ref renderAPI) manual to render objects manually. 
 
 # Saving/loading {#materials_e}
-A material is a @ref BansheeEngine::Resource "Resource" and can be saved/loaded like any other. See the [resource](@ref resources) manual.
+A material is a @ref bs::Resource "Resource" and can be saved/loaded like any other. See the [resource](@ref resources) manual.

Documentation/Manuals/Native/meshes.md

@@ -2,16 +2,16 @@ Meshes									{#meshes}
 ===============
 [TOC]
 
-Mesh is an object represented by a set of points, their properties and a set of primitives formed by those points. In Banshee mesh is represented with the @ref BansheeEngine::Mesh "Mesh" and @ref BansheeEngine::MeshCore "MeshCore" classes. Both of these provide almost equivalent functionality, but the former is for use on the simulation thread, and the latter is for use on the core thread. If you are confused by the dual nature of the objects, read the [core thread](@ref coreThread) manual. 
+Mesh is an object represented by a set of points, their properties and a set of primitives formed by those points. In Banshee mesh is represented with the @ref bs::Mesh "Mesh" and @ref bs::MeshCore "MeshCore" classes. Both of these provide almost equivalent functionality, but the former is for use on the simulation thread, and the latter is for use on the core thread. If you are confused by the dual nature of the objects, read the [core thread](@ref coreThread) manual. 
 
 We're going to focus on the simulation thread implementation in this manual, and then note the differences in the core thread version at the end.
 
 # Creating a mesh {#meshes_a}
-To create a mesh call @ref BansheeEngine::Mesh::create "Mesh::create" or one if its overloads. You'll need to populate the @ref BansheeEngine::MESH_DESC "MESH_DESC" structure and pass it as a parameter. At minimum you need to provide a @ref BansheeEngine::VertexDataDesc "vertex description" that describes in what format are the vertices stored in the vertex buffer and the number of vertices and indices. 
+To create a mesh call @ref bs::Mesh::create "Mesh::create" or one if its overloads. You'll need to populate the @ref bs::MESH_DESC "MESH_DESC" structure and pass it as a parameter. At minimum you need to provide a @ref bs::VertexDataDesc "vertex description" that describes in what format are the vertices stored in the vertex buffer and the number of vertices and indices. 
 
 Optionally you can also provide the type of indices, type of primitives, and a set of sub-meshes:
  - Indices can be 32- or 16-bit. This is controlled by the `indexType` parameter. Smaller indices can be used to save bandwidth if your mesh has a small enough number of primitives.
- - `drawOp` parameter determines how are the indices interpreted. By default they're interpreted as a list of triangles (every three indices forming a triangle, one after another) but different @ref BansheeEngine::DrawOperationType "types" are supported.
+ - `drawOp` parameter determines how are the indices interpreted. By default they're interpreted as a list of triangles (every three indices forming a triangle, one after another) but different @ref bs::DrawOperationType "types" are supported.
  - A mesh can have multiple sub-meshes. Each sub-mesh is described by an offset and a range of indices that belong to it. Sub-meshes can be used for rendering sections of a mesh, instead of all of it (for example if a single mesh uses different materials).
  
 For example to create a simple mesh:
@@ -27,20 +27,20 @@ meshDesc.vertexDesc = vertexDesc;
 HMesh mesh = Mesh::create(meshDesc);
 ~~~~~~~~~~~~~ 
  
-You can also create a non-empty mesh by creating it with a populated @ref BansheeEngine::MeshData "MeshData" object. More about @ref BansheeEngine::MeshData "MeshData" later. 
+You can also create a non-empty mesh by creating it with a populated @ref bs::MeshData "MeshData" object. More about @ref bs::MeshData "MeshData" later. 
  
 # Accessing properties {#meshes_b} 
-You can access various mesh properties by calling @ref BansheeEngine::Mesh::getProperties() "Mesh::getProperties()" which will return an instance of @ref BansheeEngine::MeshProperties "MeshProperties" which contains information such as mesh bounds, number of indices/vertices and sub-meshes. 
+You can access various mesh properties by calling @ref bs::Mesh::getProperties() "Mesh::getProperties()" which will return an instance of @ref bs::MeshProperties "MeshProperties" which contains information such as mesh bounds, number of indices/vertices and sub-meshes. 
  
 # Reading/writing {#meshes_c}
-To read and write from/to the mesh use the @ref BansheeEngine::Mesh::readSubresource "Mesh::readSubresource" and @ref BansheeEngine::Mesh::writeSubresource "Mesh::writeSubresource" methods. These expect an index of a sub-resource to read/write to, and a @ref BansheeEngine::MeshData "MeshData" object.
+To read and write from/to the mesh use the @ref bs::Mesh::readSubresource "Mesh::readSubresource" and @ref bs::Mesh::writeSubresource "Mesh::writeSubresource" methods. These expect an index of a sub-resource to read/write to, and a @ref bs::MeshData "MeshData" object.
 
 The sub-resource index for a mesh is currently ignored and should be always left as zero.
 
-@ref BansheeEngine::MeshData "MeshData" object is just a container for a set of vertices and indices. You can create one manually or use @ref BansheeEngine::Mesh::allocateSubresourceBuffer "Mesh::allocateSubresourceBuffer" to create the object of valid size and format for the specified mesh. When reading from the mesh the buffer will be filled with vertices/indices from the mesh, and when writing you are expected to populate the object.
+@ref bs::MeshData "MeshData" object is just a container for a set of vertices and indices. You can create one manually or use @ref bs::Mesh::allocateSubresourceBuffer "Mesh::allocateSubresourceBuffer" to create the object of valid size and format for the specified mesh. When reading from the mesh the buffer will be filled with vertices/indices from the mesh, and when writing you are expected to populate the object.
 
 ## MeshData {#meshes_c_a}
-You can create @ref BansheeEngine::MeshData "MeshData" manually by calling @ref BansheeEngine::MeshData::create "MeshData::create" and providing it with vertex description, index type and number of vertices and indices. You must ensure that the formats and sizes matches the mesh this will be used on.
+You can create @ref bs::MeshData "MeshData" manually by calling @ref bs::MeshData::create "MeshData::create" and providing it with vertex description, index type and number of vertices and indices. You must ensure that the formats and sizes matches the mesh this will be used on.
 
 ### Vertex description {#meshes_c_a_a}
 Creating a vertex description is simple, it requires you to specify a list of vertex properties, each identified by a type and a semantic. The semantic determines to which GPU program input field does the property map to. See the [gpu program](@ref gpuPrograms) manual for more information about semantics. For example:
@@ -52,14 +52,14 @@ vertexDesc->addVertElem(VET_FLOAT3, VES_NORMAL);
 vertexDesc->addVertElem(VET_FLOAT2, VES_TEXCOORD);
 ~~~~~~~~~~~~~ 
 
-See @ref BansheeEngine::VertexElementType "VertexElementType" for valid types, and @ref BansheeEngine::VertexElementSemantic "VertexElementSemantic" for a list of valid semantics. Each semantic can also optionally have an index in case multiple values of the same semantic are needed.
+See @ref bs::VertexElementType "VertexElementType" for valid types, and @ref bs::VertexElementSemantic "VertexElementSemantic" for a list of valid semantics. Each semantic can also optionally have an index in case multiple values of the same semantic are needed.
 
-Each vertex element can also be placed in a "stream". In the example above all the elements are in the 0th stream, but you can place different elements in different streams by providing a stream index to @ref BansheeEngine::VertexDataDesc::addVertElem "VertexDataDesc::addVertElem". Different streams will result in multiple vertex buffers created within the mesh. This can be useful if you are rendering the mesh with multiple GPU programs and not every GPU program requires all vertex elements, in which case you could only bind a subset of the vertex buffers and reduce the bandwidth costs by not sending the unnecessary data.
+Each vertex element can also be placed in a "stream". In the example above all the elements are in the 0th stream, but you can place different elements in different streams by providing a stream index to @ref bs::VertexDataDesc::addVertElem "VertexDataDesc::addVertElem". Different streams will result in multiple vertex buffers created within the mesh. This can be useful if you are rendering the mesh with multiple GPU programs and not every GPU program requires all vertex elements, in which case you could only bind a subset of the vertex buffers and reduce the bandwidth costs by not sending the unnecessary data.
 
-Once the @ref BansheeEngine::VertexDataDesc "VertexDataDesc" structure has been filled, you can use it for initializing a @ref BansheeEngine::Mesh "Mesh" or @ref BansheeEngine::MeshData "MeshData". You can also use it to manually create a vertex declaration by calling @ref BansheeEngine::VertexDeclaration::create "VertexDeclaration::create". @ref BansheeEngine::VertexDeclaration "VertexDeclaration" can be manually bound to the @ref BansheeEngine::RenderAPI "RenderAPI", which can be useful in the case you're manually creating vertex or index buffers.
+Once the @ref bs::VertexDataDesc "VertexDataDesc" structure has been filled, you can use it for initializing a @ref bs::Mesh "Mesh" or @ref bs::MeshData "MeshData". You can also use it to manually create a vertex declaration by calling @ref bs::VertexDeclaration::create "VertexDeclaration::create". @ref bs::VertexDeclaration "VertexDeclaration" can be manually bound to the @ref bs::RenderAPI "RenderAPI", which can be useful in the case you're manually creating vertex or index buffers.
 
 ### Reading/writing MeshData {#meshes_c_a_b}
-@ref BansheeEngine::MeshData "MeshData" provides multiple methods of reading/writing vertex data. The most trivial is setting the data in-bulk by using @ref BansheeEngine::MeshData::setVertexData "MeshData::setVertexData" and @ref BansheeEngine::MeshData::getVertexData "MeshData::getVertexData" which set vertex data for a single vertex element all at once. 
+@ref bs::MeshData "MeshData" provides multiple methods of reading/writing vertex data. The most trivial is setting the data in-bulk by using @ref bs::MeshData::setVertexData "MeshData::setVertexData" and @ref bs::MeshData::getVertexData "MeshData::getVertexData" which set vertex data for a single vertex element all at once. 
 
 ~~~~~~~~~~~~~{.cpp}
 SPtr<MeshData> meshData = ...; // Assume we have 4 vertices, with only a position element
@@ -71,7 +71,7 @@ Vector3 myVertices[4];
 meshData->setVertexData(VES_POSITION, myVertices, sizeof(myVertices));
 ~~~~~~~~~~~~~
 
-You can also use @ref BansheeEngine::MeshData::getElementData "MeshData::getElementData" which will return a pointer to the starting point of the vertex data for a specific element. You can then iterate over the pointer to read/write values. Make sure to use @ref BansheeEngine::VertexDataDesc::getVertexStride "VertexDataDesc::getVertexStride" to know how many bytes to advance between elements.
+You can also use @ref bs::MeshData::getElementData "MeshData::getElementData" which will return a pointer to the starting point of the vertex data for a specific element. You can then iterate over the pointer to read/write values. Make sure to use @ref bs::VertexDataDesc::getVertexStride "VertexDataDesc::getVertexStride" to know how many bytes to advance between elements.
 
 ~~~~~~~~~~~~~{.cpp}
 SPtr<MeshData> meshData = ...; // Assume we have 4 vertices, with only a position element
@@ -88,7 +88,7 @@ for(UINT32 i = 0; i < 4; i++)
 }
 ~~~~~~~~~~~~~
 
-And finally you can use iterators: @ref BansheeEngine::MeshData::getVec2DataIter "MeshData::getVec2DataIter", @ref BansheeEngine::MeshData::getVec3DataIter "MeshData::getVec3DataIter", @ref BansheeEngine::MeshData::getVec4DataIter "MeshData::getVec4DataIter", @ref BansheeEngine::MeshData::getDWORDDataIter "MeshData::getDWORDDataIter". They are similar to the previous example but you don't need to manually worry about the vertex stride, or going outside of valid bounds.
+And finally you can use iterators: @ref bs::MeshData::getVec2DataIter "MeshData::getVec2DataIter", @ref bs::MeshData::getVec3DataIter "MeshData::getVec3DataIter", @ref bs::MeshData::getVec4DataIter "MeshData::getVec4DataIter", @ref bs::MeshData::getDWORDDataIter "MeshData::getDWORDDataIter". They are similar to the previous example but you don't need to manually worry about the vertex stride, or going outside of valid bounds.
 
 ~~~~~~~~~~~~~{.cpp}
 SPtr<MeshData> meshData = ...; // Assume we have 4 vertices, with only a position element
@@ -102,7 +102,7 @@ do {
 } while(vecIter.moveNext()); // Iterate until we reach the end
 ~~~~~~~~~~~~~
 
-Accessing indices is simpler and is done through @ref BansheeEngine::MeshData::getIndices32 "MeshData::getIndices32" or @ref BansheeEngine::MeshData::getIndices16 "MeshData::getIndices16" depending if the indices are 32- or 16-bit. The returned value is a pointer to the index buffer you can use to read/write the indices directly.
+Accessing indices is simpler and is done through @ref bs::MeshData::getIndices32 "MeshData::getIndices32" or @ref bs::MeshData::getIndices16 "MeshData::getIndices16" depending if the indices are 32- or 16-bit. The returned value is a pointer to the index buffer you can use to read/write the indices directly.
 
 ~~~~~~~~~~~~~{.cpp}
 SPtr<MeshData> meshData = ...; // Assume we have 6 32-bit indices
@@ -118,33 +118,33 @@ indices[5] = 3;
 ~~~~~~~~~~~~~
 
 ## Cached CPU data {#meshes_c_b}
-When you read from a mesh using the @ref BansheeEngine::Mesh::readSubresource "Mesh::readSubresource" method the read will be performed from the GPU. This is useful if the GPU has in some way modified the mesh, but will also incur a potentially large performance penalty because it will introduce a CPU-GPU synchronization point. In a lot of cases you might just want to read mesh data from a mesh that was imported or created on the CPU in some other way.
+When you read from a mesh using the @ref bs::Mesh::readSubresource "Mesh::readSubresource" method the read will be performed from the GPU. This is useful if the GPU has in some way modified the mesh, but will also incur a potentially large performance penalty because it will introduce a CPU-GPU synchronization point. In a lot of cases you might just want to read mesh data from a mesh that was imported or created on the CPU in some other way.
 
-For this reason @ref BansheeEngine::Mesh::readData "Mesh::readData" exists. It will read data quickly with little performance impact. However you must create the mesh using the @ref BansheeEngine::MU_CPUCACHED "MU_CPUCACHED" usage. This also means that the mesh will keep a copy of its data in system memory, so use it sparingly. If the mesh is modified from the GPU this method will not reflect such changes.
+For this reason @ref bs::Mesh::readData "Mesh::readData" exists. It will read data quickly with little performance impact. However you must create the mesh using the @ref bs::MU_CPUCACHED "MU_CPUCACHED" usage. This also means that the mesh will keep a copy of its data in system memory, so use it sparingly. If the mesh is modified from the GPU this method will not reflect such changes.
 
 # Rendering using the mesh {#meshes_d}
-To use a mesh for rendering you need to bind its vertex buffer(s), index buffer, vertex declaration and draw operation using the @ref BansheeEngine::RenderAPI "RenderAPI". Relevant methods are @ref BansheeEngine::RenderAPI::setVertexBuffers "RenderAPI::setVertexBuffers", @ref BansheeEngine::RenderAPI::setIndexBuffer "RenderAPI::setIndexBuffer", @ref BansheeEngine::RenderAPI::setVertexDeclaration "RenderAPI::setVertexDeclaration" and @ref BansheeEngine::RenderAPI::setDrawOperation "RenderAPI::setDrawOperation". See below for information about how to retrieve this information from a mesh.
+To use a mesh for rendering you need to bind its vertex buffer(s), index buffer, vertex declaration and draw operation using the @ref bs::RenderAPI "RenderAPI". Relevant methods are @ref bs::RenderAPI::setVertexBuffers "RenderAPI::setVertexBuffers", @ref bs::RenderAPI::setIndexBuffer "RenderAPI::setIndexBuffer", @ref bs::RenderAPI::setVertexDeclaration "RenderAPI::setVertexDeclaration" and @ref bs::RenderAPI::setDrawOperation "RenderAPI::setDrawOperation". See below for information about how to retrieve this information from a mesh.
 
 See the [render API](@ref renderAPI) manual for more information on how to manually execute rendering commands.
 
-If working on the core thread you can use the helper @ref BansheeEngine::RendererUtility::draw "RendererUtility::draw" method that performs these operations for you.
+If working on the core thread you can use the helper @ref bs::RendererUtility::draw "RendererUtility::draw" method that performs these operations for you.
 
 # Saving/loading {#meshes_e}
-A mesh is a @ref BansheeEngine::Resource "Resource" and can be saved/loaded like any other. See the [resource](@ref resources) manual.
+A mesh is a @ref bs::Resource "Resource" and can be saved/loaded like any other. See the [resource](@ref resources) manual.
 
 # Core thread meshes {#meshes_f}
-So far we have only talked about the simulation thread @ref BansheeEngine::Mesh "Mesh" but have ignored the core thread @ref BansheeEngine::MeshCore "MeshCore". The functionality between the two is mostly the same, with the major difference being that the core thread version doesn't require a @ref BansheeEngine::CoreThreadAccessor "CoreAccessor" for access, and you can instead perform operations on it directly.
+So far we have only talked about the simulation thread @ref bs::Mesh "Mesh" but have ignored the core thread @ref bs::MeshCore "MeshCore". The functionality between the two is mostly the same, with the major difference being that the core thread version doesn't require a @ref bs::CoreThreadAccessor "CoreAccessor" for access, and you can instead perform operations on it directly.
 
-You can also use the core thread version to access and manipulate vertex and index buffers directly (including binding them to the pipeline as described earlier). Use @ref BansheeEngine::MeshCore::getVertexData "MeshCore::getVertexData" to retrieve information about all @ref BansheeEngine::VertexBufferCore "vertex buffers", @ref BansheeEngine::MeshCore::getIndexBuffer "MeshCore::getIndexBuffer" to retrieve the @ref BansheeEngine::IndexBufferCore "index buffer" and @ref BansheeEngine::MeshCore::getVertexDesc "MeshCore::getVertexDesc" to retrieve the @ref BansheeEngine::VertexDataDesc "vertex description".
+You can also use the core thread version to access and manipulate vertex and index buffers directly (including binding them to the pipeline as described earlier). Use @ref bs::MeshCore::getVertexData "MeshCore::getVertexData" to retrieve information about all @ref bs::VertexBufferCore "vertex buffers", @ref bs::MeshCore::getIndexBuffer "MeshCore::getIndexBuffer" to retrieve the @ref bs::IndexBufferCore "index buffer" and @ref bs::MeshCore::getVertexDesc "MeshCore::getVertexDesc" to retrieve the @ref bs::VertexDataDesc "vertex description".
 
 # Advanced meshes {#meshes_g}
 So far we have described the use of standard meshes. And while the described meshes can be used for all purposes, when we have a mesh that is updated often (every frame or every few frames) it can be beneficial for performance to use a different mesh type. This is because updates to a normal mesh can introduce GPU-CPU synchronization points if that mesh is still being used by the GPU while we are updating it (which can happen often).
 
-So instead we use a concept of a @ref BansheeEngine::MeshHeap "MeshHeap", which allows us to quickly create and allocate new meshes, without having to worry about introducing GPU-CPU synchronization points. This is perfect for systems like GUI or grass rendering, which might have their meshes rebuilt nearly every frame. The only downside is that the heap will allocate more memory than actually required for a mesh, as it keeps the memory for both the newly updated mesh and the one currently being used.
+So instead we use a concept of a @ref bs::MeshHeap "MeshHeap", which allows us to quickly create and allocate new meshes, without having to worry about introducing GPU-CPU synchronization points. This is perfect for systems like GUI or grass rendering, which might have their meshes rebuilt nearly every frame. The only downside is that the heap will allocate more memory than actually required for a mesh, as it keeps the memory for both the newly updated mesh and the one currently being used.
 
-Creation of a @ref BansheeEngine::MeshHeap::create "MeshHeap::create" is nearly identical to creation of a @ref BansheeEngine::Mesh "Mesh". It requires a vertex description and an index type, while the index/vertex counts are mostly arbitrary (the heap will grow as needed).
+Creation of a @ref bs::MeshHeap::create "MeshHeap::create" is nearly identical to creation of a @ref bs::Mesh "Mesh". It requires a vertex description and an index type, while the index/vertex counts are mostly arbitrary (the heap will grow as needed).
 
-You can allocate meshes from the heap by calling @ref BansheeEngine::MeshHeap::alloc "MeshHeap::alloc" and providing it with a @ref BansheeEngine::MeshData "MeshData". When done with the mesh call @ref BansheeEngine::MeshHeap::dealloc "MeshHeap::dealloc". @ref BansheeEngine::MeshHeap::alloc "MeshHeap::alloc" returns a @ref BansheeEngine::TransientMesh "TransientMesh" which shares mostly the same interface as a normal @ref BansheeEngine::Mesh "Mesh", with a few restrictions. You are not allowed to read/write to it (aside from the initial value), and it doesn't support sub-meshes.
+You can allocate meshes from the heap by calling @ref bs::MeshHeap::alloc "MeshHeap::alloc" and providing it with a @ref bs::MeshData "MeshData". When done with the mesh call @ref bs::MeshHeap::dealloc "MeshHeap::dealloc". @ref bs::MeshHeap::alloc "MeshHeap::alloc" returns a @ref bs::TransientMesh "TransientMesh" which shares mostly the same interface as a normal @ref bs::Mesh "Mesh", with a few restrictions. You are not allowed to read/write to it (aside from the initial value), and it doesn't support sub-meshes.
 
 A simple example of a mesh heap:
 ~~~~~~~~~~~~~{.cpp}
@@ -161,4 +161,4 @@ meshHeap->dealloc(mesh);
 
 ~~~~~~~~~~~~~
 
-See @ref BansheeEngine::GUIManager "GUIManager" implementation in "BsGUIManager.cpp" for a functional example.
+See @ref bs::GUIManager "GUIManager" implementation in "BsGUIManager.cpp" for a functional example.

Documentation/Manuals/Native/plugins.md

@@ -4,14 +4,14 @@ Creating custom plugins						{#customPlugins}
 
 Many systems in Banshee are implemented through plugins, libraries that are separate from the core of the engine and can be dynamically loaded or unloaded. If possible, it is the prefered way of extending the engine.
 
-The default Banshee @ref BansheeEngine::CoreApplication "Application" supports plugins for the following systems:
+The default Banshee @ref bs::CoreApplication "Application" supports plugins for the following systems:
  - Rendering API - Wrappers for render APIs like DirectX or OpenGL. See the manual about working with [low level render API] (@ref renderAPI) for more information.
  - Renderer - Renderer that determines how is the scene displayed (lighting, shadows, post-processing, etc.). See the manual about implementing [custom renderers](@ref renderer).
  - Input - Reports input events (mouse, keyboard, gamepad, etc.)
  - Physics - Runs the physics simulation (like NVIDIA PhysX)
  - Importers - Importers that handle conversion of some third party resource format into an engine-ready format. See the manual about implementing [custom importers](@ref customImporters).
  
-The supported plugins will be automatically loaded and unloaded by the application as needed, all you need to do is to provide names of their libraries to the @ref BansheeEngine::START_UP_DESC "START_UP_DESC" used to initialize the application. All plugins should be in the same folder as the main application executable. 
+The supported plugins will be automatically loaded and unloaded by the application as needed, all you need to do is to provide names of their libraries to the @ref bs::START_UP_DESC "START_UP_DESC" used to initialize the application. All plugins should be in the same folder as the main application executable. 
 
 Aside from the supported plugins you can also create fully custom plugins that you load or unload manually.
 
@@ -50,14 +50,14 @@ The exact implementations of these methods differ depending for which system are
 Custom plugins can do whatever you wish, engine has no expectations from them so its up to your to load/unload them and to call their methods.
 
 To load a custom plugin you can use:
- - @ref BansheeEngine::CoreApplication::loadPlugin "Application::loadPlugin" - Accepts the name of the plugin library and outputs the library object. Optionally you may also pass a parameter to the `loadPlugin` method, if yours accepts one.
- - @ref BansheeEngine::CoreApplication::unloadPlugin "Application::unloadPlugin" - Unloads a previously loaded plugin. 
+ - @ref bs::CoreApplication::loadPlugin "Application::loadPlugin" - Accepts the name of the plugin library and outputs the library object. Optionally you may also pass a parameter to the `loadPlugin` method, if yours accepts one.
+ - @ref bs::CoreApplication::unloadPlugin "Application::unloadPlugin" - Unloads a previously loaded plugin. 
 
-Both of those methods internally call @ref BansheeEngine::DynLibManager "DynLibManager". You can use it directly if you do not need the plugin interface (`loadPlugin` and etc.), it has two methods:
- - @ref BansheeEngine::DynLibManager::load "DynLibManager::load" - Accepts a file name to the library, and returns the @ref BansheeEngine::DynLib "DynLib" object if the load is successful or null otherwise. 
- - @ref BansheeEngine::DynLibManager::unload "DynLibManager::unload" - Unloads a previously loaded library.
+Both of those methods internally call @ref bs::DynLibManager "DynLibManager". You can use it directly if you do not need the plugin interface (`loadPlugin` and etc.), it has two methods:
+ - @ref bs::DynLibManager::load "DynLibManager::load" - Accepts a file name to the library, and returns the @ref bs::DynLib "DynLib" object if the load is successful or null otherwise. 
+ - @ref bs::DynLibManager::unload "DynLibManager::unload" - Unloads a previously loaded library.
  
-Once the library is loaded you can use the @ref BansheeEngine::DynLib "DynLib" object, and its @ref BansheeEngine::DynLib::getSymbol "DynLib::getSymbol" method to retrieve a function pointer within the dynamic library, and call into it. For example if we wanted to retrieve a function pointer for the `loadPlugin` method from the previous chapter:
+Once the library is loaded you can use the @ref bs::DynLib "DynLib" object, and its @ref bs::DynLib::getSymbol "DynLib::getSymbol" method to retrieve a function pointer within the dynamic library, and call into it. For example if we wanted to retrieve a function pointer for the `loadPlugin` method from the previous chapter:
 ~~~~~~~~~~~~~{.cpp}
 // Load library
 DynLib* myLibrary = DynLibManager::instance().load("myPlugin");

Documentation/Manuals/Native/profiling.md

@@ -5,33 +5,33 @@ Profiling code								{#profiling}
 Code profiling is an important process to determine performance bottlenecks. Profiling measures code execution times, memory allocations or various other resource usage. Banshee supports CPU and GPU profiling.
 
 # CPU profiling {#profiling_a}
-CPU profiler allow you to measure execution times of code executing on the CPU. It will also track the number of memory operations. CPU profiling is handled by the @ref BansheeEngine::ProfilerCPU "ProfilerCPU" module. You use that module to set up sampling points that determine which areas of code to measure, and to retrieve reports telling you the measured results.
+CPU profiler allow you to measure execution times of code executing on the CPU. It will also track the number of memory operations. CPU profiling is handled by the @ref bs::ProfilerCPU "ProfilerCPU" module. You use that module to set up sampling points that determine which areas of code to measure, and to retrieve reports telling you the measured results.
 
 The profiler supports two separate measuring modes, the normal mode measures time in milliseconds, while the precise mode measures time in CPU cycles. The precise mode does have drawbacks as it is inacurrate for longer code as it will not account for OS context switches and similar. Usually you will be using the normal measuring mode, and reserve the precise mode when you need to know exactly how many cycles some relatively small operation takes.
 
-To start profiling, issue a call to @ref BansheeEngine::ProfilerCPU::beginSample "ProfilerCPU::beginSample" or @ref BansheeEngine::ProfilerCPU::beginSamplePrecise "ProfilerCPU::beginSamplePrecise". Both of these methods accept a string that can be used for identifying the result when the profiler report is generated. You must follow each of these with a call to @ref BansheeEngine::ProfilerCPU::endSample "ProfilerCPU::endSample" or @ref BansheeEngine::ProfilerCPU::endSamplePrecise "ProfilerCPU::endSamplePrecise", which take the same identifier string as their counterparts. Any code executed between these calls will be measured.
+To start profiling, issue a call to @ref bs::ProfilerCPU::beginSample "ProfilerCPU::beginSample" or @ref bs::ProfilerCPU::beginSamplePrecise "ProfilerCPU::beginSamplePrecise". Both of these methods accept a string that can be used for identifying the result when the profiler report is generated. You must follow each of these with a call to @ref bs::ProfilerCPU::endSample "ProfilerCPU::endSample" or @ref bs::ProfilerCPU::endSamplePrecise "ProfilerCPU::endSamplePrecise", which take the same identifier string as their counterparts. Any code executed between these calls will be measured.
 
 You can also nest profiling calls, by calling another `beginSample` within an existing `beginSample` call.
 
-Once you are done sampling your code, call @ref BansheeEngine::ProfilerCPU::generateReport() "ProfilerCPU::generateReport". This will return a @ref BansheeEngine::CPUProfilerReport "CPUProfilerReport" which contains both normal and precise sampling data as a hierarchy of samples. You can then use this data to print it on the screen, save it to a log, or similar.
+Once you are done sampling your code, call @ref bs::ProfilerCPU::generateReport() "ProfilerCPU::generateReport". This will return a @ref bs::CPUProfilerReport "CPUProfilerReport" which contains both normal and precise sampling data as a hierarchy of samples. You can then use this data to print it on the screen, save it to a log, or similar.
 
-You may also use the built-in @ref BansheeEngine::ProfilerOverlay component to automatically display contents of both CPU and GPU profilers every frame, which will save you from manually parsing the profiler reports. Just add it to the scene and assign it a camera to render to.
+You may also use the built-in @ref bs::ProfilerOverlay component to automatically display contents of both CPU and GPU profilers every frame, which will save you from manually parsing the profiler reports. Just add it to the scene and assign it a camera to render to.
 
-If you just want to clear profiling data without generating a report, call @ref BansheeEngine::ProfilerCPU::reset "ProfilerCPU::reset()".
+If you just want to clear profiling data without generating a report, call @ref bs::ProfilerCPU::reset "ProfilerCPU::reset()".
 
 ## Threads {#profiling_b}
-The profiler is thread-safe, but if you will be profiling code on threads not managed by the engine, you must manually call @ref BansheeEngine::ProfilerCPU::beginThread "ProfilerCPU::beginThread" before any sample calls, and @ref BansheeEngine::ProfilerCPU::endThread "ProfilerCPU::endThread" after all sample calls.
+The profiler is thread-safe, but if you will be profiling code on threads not managed by the engine, you must manually call @ref bs::ProfilerCPU::beginThread "ProfilerCPU::beginThread" before any sample calls, and @ref bs::ProfilerCPU::endThread "ProfilerCPU::endThread" after all sample calls.
 
 ## Overhead {#profiling_c}
 Profiler code itself will introduce a certain amount of overhead which will slightly skew profiling results. The profiler attempts to estimate its error, which is reported in the returned reports. You can choose to take this into consideration if you need really precise results.
 
 # GPU profiling {#profiling_d}
-GPU profiling is handled through @ref BansheeEngine::ProfilerGPU "ProfilerGPU" module, which allows you to track execution times of GPU operations, as well as various resource usages.
+GPU profiling is handled through @ref bs::ProfilerGPU "ProfilerGPU" module, which allows you to track execution times of GPU operations, as well as various resource usages.
 
-Similar to CPU profiling, you issue sampling calls using @ref BansheeEngine::ProfilerGPU::beginSample "ProfilerGPU::beginSample" and @ref BansheeEngine::ProfilerGPU::endSample "ProfilerGPU::endSample". Any GPU commands executed between these two calls will be measured.
+Similar to CPU profiling, you issue sampling calls using @ref bs::ProfilerGPU::beginSample "ProfilerGPU::beginSample" and @ref bs::ProfilerGPU::endSample "ProfilerGPU::endSample". Any GPU commands executed between these two calls will be measured.
 
 Each GPU sample will measure the time to took the execute the command on the GPU, but will also measure various resource usage stats. For example it will measure number of draw calls, number of vertices/primitives drawn, render state switches, and similar.
 
-All this information will be contained in a @ref BansheeEngine::GPUProfilerReport "GPUProfilerReport". To retrieve the report use @ref BansheeEngine::ProfilerGPU::getNumAvailableReports() "ProfilerGPU::getNumAvailableReports()" and @ref BansheeEngine::ProfilerGPU::getNextReport "ProfilerGPU::getNextReport()". 
+All this information will be contained in a @ref bs::GPUProfilerReport "GPUProfilerReport". To retrieve the report use @ref bs::ProfilerGPU::getNumAvailableReports() "ProfilerGPU::getNumAvailableReports()" and @ref bs::ProfilerGPU::getNextReport "ProfilerGPU::getNextReport()". 
 
 GPU profiler always generates only a single report per frame. It will queue the reports, and the above method will return the oldest report and remove it from the queue. Only a certain small number of reports are queued, and old reports will be lost if you don't retrieve them every few frames.

Documentation/Manuals/Native/renderAPI.md

@@ -2,9 +2,9 @@ Render API									{#renderAPI}
 ===============
 [TOC]
 
-Render API is an interface that allows you to perform low-level rendering operations akin to DirectX or OpenGL. In Banshee this API is provided through the @ref BansheeEngine::RenderAPI "RenderAPI" for the simulation thread, and @ref BansheeEngine::RenderAPICore "RenderAPICore" for the core thread. If you are confused by the dual nature of  objects, read the [core thread](@ref coreThread) manual. 
+Render API is an interface that allows you to perform low-level rendering operations akin to DirectX or OpenGL. In Banshee this API is provided through the @ref bs::RenderAPI "RenderAPI" for the simulation thread, and @ref bs::RenderAPICore "RenderAPICore" for the core thread. If you are confused by the dual nature of  objects, read the [core thread](@ref coreThread) manual. 
 
-For the remainder of this manual we'll focus on the core thread portion of the API, but both provide essentially identical functionality, with the main difference that the simulation thread one expects a @ref BansheeEngine::CoreThreadAccessor "CoreAccessor" as input, and the execution of the actual commands is delayed until they reach the core thread.
+For the remainder of this manual we'll focus on the core thread portion of the API, but both provide essentially identical functionality, with the main difference that the simulation thread one expects a @ref bs::CoreThreadAccessor "CoreAccessor" as input, and the execution of the actual commands is delayed until they reach the core thread.
 
 Render API lets you manipulate the GPU pipeline by setting various states (depth stencil, blend and rasterizer), binding GPU programs, textures and executing draw calls. In this manual we'll cover how to use this API to perform rendering manually. 
 
@@ -28,13 +28,13 @@ We'll cover each step of this process, and at the end also show an alternate pip
 # Render targets {#renderAPI_a}
 Before any rendering can be done you must bind at least one render target. To learn more about, and how to create a render target check out the [render target](@ref renderTargets) manual. 
 
-Binding a render target involves calling @ref BansheeEngine::RenderAPICore::setRenderTarget "RenderAPICore::setRenderTarget". This will cause any rendering to be output to the entirety of the render target. Optionally you can also call @ref BansheeEngine::RenderAPICore::setViewport "RenderAPICore::setViewport" to select a sub-rectangle of the target to render to. 
+Binding a render target involves calling @ref bs::RenderAPICore::setRenderTarget "RenderAPICore::setRenderTarget". This will cause any rendering to be output to the entirety of the render target. Optionally you can also call @ref bs::RenderAPICore::setViewport "RenderAPICore::setViewport" to select a sub-rectangle of the target to render to. 
 
-Binding a render target means you cannot use it for reading within a GPU program. However if your render target has a depth-buffer you can optionally set the `readOnlyDepthStencil` parameter of @ref BansheeEngine::RenderAPICore::setRenderTarget "RenderAPICore::setRenderTarget" to true, which will allow you to have a depth buffer be bound for both depth-testing and reading from the GPU program.
+Binding a render target means you cannot use it for reading within a GPU program. However if your render target has a depth-buffer you can optionally set the `readOnlyDepthStencil` parameter of @ref bs::RenderAPICore::setRenderTarget "RenderAPICore::setRenderTarget" to true, which will allow you to have a depth buffer be bound for both depth-testing and reading from the GPU program.
  
-Before doing any rendering it's always good to clear the render target to some default value. Use @ref BansheeEngine::RenderAPICore::clearRenderTarget "RenderAPICore::clearRenderTarget" to clear the entire target, or @ref BansheeEngine::RenderAPICore::clearViewport "RenderAPICore::clearViewport" to clear just the viewport portion of the target. When clearing you can choose whether to clear color, depth or stencil buffers (or all) determined by @ref BansheeEngine::FrameBufferType "FrameBufferType" flags. You can also choose the values to clear each of the buffers to. And finally if your render target has multiple surfaces, you can choose to clear only some of the surfaces by providing a bitmask.
+Before doing any rendering it's always good to clear the render target to some default value. Use @ref bs::RenderAPICore::clearRenderTarget "RenderAPICore::clearRenderTarget" to clear the entire target, or @ref bs::RenderAPICore::clearViewport "RenderAPICore::clearViewport" to clear just the viewport portion of the target. When clearing you can choose whether to clear color, depth or stencil buffers (or all) determined by @ref bs::FrameBufferType "FrameBufferType" flags. You can also choose the values to clear each of the buffers to. And finally if your render target has multiple surfaces, you can choose to clear only some of the surfaces by providing a bitmask.
 
-Once you are done rendering make sure to call @ref BansheeEngine::RenderAPICore::swapBuffers "RenderAPICore::swapBuffers" if your render target has multiple buffers (like a window). This will swap the buffers and present the rendered image on the screen.
+Once you are done rendering make sure to call @ref bs::RenderAPICore::swapBuffers "RenderAPICore::swapBuffers" if your render target has multiple buffers (like a window). This will swap the buffers and present the rendered image on the screen.
 
 A simple example covering all these commands:
 ~~~~~~~~~~~~~{.cpp}
@@ -51,9 +51,9 @@ rapi.swapBuffers();
 ~~~~~~~~~~~~~
  
 # Pipeline state {#renderAPI_b}
-Before executing the drawing operation you must set up an @ref BansheeEngine::GraphicsPipelineStateCore "GraphicsPipelineStateCore" object, which contains a set of fixed and programmable states that control primitive rendering. This includes GPU programs (e.g. vertex/fragment) and fixed states (depth-stencil, blend, rasterizer).
+Before executing the drawing operation you must set up an @ref bs::GraphicsPipelineStateCore "GraphicsPipelineStateCore" object, which contains a set of fixed and programmable states that control primitive rendering. This includes GPU programs (e.g. vertex/fragment) and fixed states (depth-stencil, blend, rasterizer).
 
-To create a pipeline state you must fill out @ref BansheeEngine::PIPELINE_STATE_CORE_DESC "PIPELINE_STATE_CORE_DESC" descriptor, and use it to construct the state, like so:
+To create a pipeline state you must fill out @ref bs::PIPELINE_STATE_CORE_DESC "PIPELINE_STATE_CORE_DESC" descriptor, and use it to construct the state, like so:
 ~~~~~~~~~~~~~{.cpp}
 PIPELINE_STATE_CORE_DESC desc;
 // Fixed states (see below on how to create them)
@@ -71,7 +71,7 @@ desc.domainProgram = ...;
 SPtr<GraphicsPipelineStateCore> state = GraphicsPipelineStateCore::create(desc);
 ~~~~~~~~~~~~~
 
-Once created the pipeline can be bound for rendering by calling @ref BansheeEngine::RenderAPICore::setGraphicsPipeline "RenderAPICore::setGraphicsPipeline".
+Once created the pipeline can be bound for rendering by calling @ref bs::RenderAPICore::setGraphicsPipeline "RenderAPICore::setGraphicsPipeline".
 
 ~~~~~~~~~~~~~{.cpp}
 // Bind pipeline for use (continued from above)
@@ -86,16 +86,16 @@ We continue below with explanation on how to create fixed and programmable state
 Fixed pipeline states allow you to control (to some extent) non-programmable parts of the pipeline. This includes anything from blend operations, rasterization mode to depth testing. Setting these states is optional and if not set, default values will be used.
 
 States can be created by:
- - @ref BansheeEngine::DepthStencilStateCore "DepthStencilStateCore" - Populate @ref BansheeEngine::DEPTH_STENCIL_STATE_DESC "DEPTH_STENCIL_STATE_DESC" and call @ref BansheeEngine::DepthStencilStateCore::create "DepthStencilStateCore::create" 
- - @ref BansheeEngine::BlendStateCore "BlendStateCore" - Populate @ref BansheeEngine::BLEND_STATE_DESC "BLEND_STATE_DESC" and call @ref BansheeEngine::BlendStateCore::create "BlendStateCore::create" 
- - @ref BansheeEngine::RasterizerStateCore "RasterizerStateCore" - Populate @ref BansheeEngine::RASTERIZER_STATE_DESC "RASTERIZER_STATE_DESC" and call @ref BansheeEngine::RasterizerStateCore::create "RasterizerStateCore::create" 
+ - @ref bs::DepthStencilStateCore "DepthStencilStateCore" - Populate @ref bs::DEPTH_STENCIL_STATE_DESC "DEPTH_STENCIL_STATE_DESC" and call @ref bs::DepthStencilStateCore::create "DepthStencilStateCore::create" 
+ - @ref bs::BlendStateCore "BlendStateCore" - Populate @ref bs::BLEND_STATE_DESC "BLEND_STATE_DESC" and call @ref bs::BlendStateCore::create "BlendStateCore::create" 
+ - @ref bs::RasterizerStateCore "RasterizerStateCore" - Populate @ref bs::RASTERIZER_STATE_DESC "RASTERIZER_STATE_DESC" and call @ref bs::RasterizerStateCore::create "RasterizerStateCore::create" 
  
 We won't explain what each of the states does. For that you can check out the class documentation of the states themselves, or familiarize yourself with the modern GPU pipeline in general, as the states mirror it exactly.
 
 ## GPU programs {#renderAPI_b_b}
 The pipeline state also requires you to bind at least one GPU program (programmable state). At minimum you will need to bind a vertex program, while in most cases you will also need a fragment program. Optionally you can also bind geometry, hull or domain programs for more advanced functionality. To learn how to create GPU programs see [GPU program manual](@ref gpuPrograms).
 
-Most GPU programs also accept a number of parameters, whether textures, buffers, sampler states or primitive values like floats or integers. These parameters are accessed through @ref BansheeEngine::GpuParamsCore "GpuParamsCore" object. You can use this object to assign individual parameters and then bind the object to the render API using @ref BansheeEngine::RenderAPICore::setGpuParams "RenderAPICore::setGpuParams". See below for an example.
+Most GPU programs also accept a number of parameters, whether textures, buffers, sampler states or primitive values like floats or integers. These parameters are accessed through @ref bs::GpuParamsCore "GpuParamsCore" object. You can use this object to assign individual parameters and then bind the object to the render API using @ref bs::RenderAPICore::setGpuParams "RenderAPICore::setGpuParams". See below for an example.
 
 ~~~~~~~~~~~~~{.cpp}
 ... assuming graphics pipeline state and relevant GPU programs are created ...
@@ -119,24 +119,24 @@ rapi.setGpuParams(params);
  
 All parameters are bound by first retrieving their handles, and then using those handles for parameter access. In the example above we show how to bind a texture and a 2D vector to a GPU program. Same approach follows for all available parameter types.
 
-After the parameters are set, we bind them to the pipeline by calling @ref BansheeEngine::RenderAPICore::setGpuParams "RenderAPICore::setGpuParams".
+After the parameters are set, we bind them to the pipeline by calling @ref bs::RenderAPICore::setGpuParams "RenderAPICore::setGpuParams".
 
 ### Data parameters {#renderAPI_c_a_a} 
-Handles for data parameters like int, float, 2D vector, etc. can be retrieved by calling @ref BansheeEngine::GpuParamsCore::getParam "GpuParamsCore::getParam" which can then be assigned to as shown above.
+Handles for data parameters like int, float, 2D vector, etc. can be retrieved by calling @ref bs::GpuParamsCore::getParam "GpuParamsCore::getParam" which can then be assigned to as shown above.
 
-Alternatively you may also assign entire blocks of data parameters by calling @ref BansheeEngine::GpuParamsCore::setParamBlockBuffer(GpuProgramType,const String&,const ParamsBufferType&) "GpuParamsCore::setParamBlockBuffer". When assigning entire blocks you must create and populate the @ref BansheeEngine::GpuParamBlockBuffer "GpuParamBlockBuffer" object manually.
+Alternatively you may also assign entire blocks of data parameters by calling @ref bs::GpuParamsCore::setParamBlockBuffer(GpuProgramType,const String&,const ParamsBufferType&) "GpuParamsCore::setParamBlockBuffer". When assigning entire blocks you must create and populate the @ref bs::GpuParamBlockBuffer "GpuParamBlockBuffer" object manually.
 
-When writing to buffers manually you must ensure to write to offsets the GPU program expects the data to be at. You can find thise information from @ref BansheeEngine::GpuParamDesc "GpuParamDesc" structure accessible from @ref BansheeEngine::GpuProgramCore::getParamDesc "GpuProgramCore::getParamDesc". 
+When writing to buffers manually you must ensure to write to offsets the GPU program expects the data to be at. You can find thise information from @ref bs::GpuParamDesc "GpuParamDesc" structure accessible from @ref bs::GpuProgramCore::getParamDesc "GpuProgramCore::getParamDesc". 
 
 ### Texture parameters {#renderAPI_c_a_b} 
-Handles for texture parameters can be retrieved by calling @ref BansheeEngine::GpuParamsCore::getTextureParam "GpuParamsCore::getTextureParam", or @ref BansheeEngine::GpuParamsCore::getLoadStoreTextureParam "GpuParamsCore::getLoadStoreTextureParam" if the texture should be bound for load-store operations.
+Handles for texture parameters can be retrieved by calling @ref bs::GpuParamsCore::getTextureParam "GpuParamsCore::getTextureParam", or @ref bs::GpuParamsCore::getLoadStoreTextureParam "GpuParamsCore::getLoadStoreTextureParam" if the texture should be bound for load-store operations.
 
 Learn more about textures and their different types in the [texture manual](@ref textures).
 
 ### Sampler state parameters {#renderAPI_c_a_c}
-Sampler states can be used to customize how is the texture sampled. You can retrieve a handle for a sampler state parameter by calling @ref BansheeEngine::GpuParamsCore::getSamplerStateParam "GpuParamsCore::getSamplerStateParam".
+Sampler states can be used to customize how is the texture sampled. You can retrieve a handle for a sampler state parameter by calling @ref bs::GpuParamsCore::getSamplerStateParam "GpuParamsCore::getSamplerStateParam".
 
-Sampler states are represented by the @ref BansheeEngine::SamplerStateCore "SamplerStateCore" object, which you can create by populating the @ref BansheeEngine::SAMPLER_STATE_DESC "SAMPLER_STATE_DESC" and calling @ref BansheeEngine::SamplerStateCore::create "SamplerStateCore::create". 
+Sampler states are represented by the @ref bs::SamplerStateCore "SamplerStateCore" object, which you can create by populating the @ref bs::SAMPLER_STATE_DESC "SAMPLER_STATE_DESC" and calling @ref bs::SamplerStateCore::create "SamplerStateCore::create". 
 
 An example to create and bind a sampler state:
 ~~~~~~~~~~~~~{.cpp}
@@ -159,11 +159,11 @@ mySamplerParam.set(mySamplerState);
 ~~~~~~~~~~~~~
 
 # Vertex buffer {#renderAPI_d}
-@ref BansheeEngine::VertexBufferCore "Vertex buffer" is a buffer that contains all vertices of the object we wish to render. When drawing the vertices will be interpreted as primitives (either points, lines or triangles) and rendered. Each vertex can have one or multiple properties associated with it.
+@ref bs::VertexBufferCore "Vertex buffer" is a buffer that contains all vertices of the object we wish to render. When drawing the vertices will be interpreted as primitives (either points, lines or triangles) and rendered. Each vertex can have one or multiple properties associated with it.
 
-To create a vertex buffer call @ref BansheeEngine::VertexBufferCore::create "VertexBufferCore::create". You need to know the size of an individual vertex (determined by the properties each vertex requires) and the number of vertices. Optionally if your vertex buffer is used for output from the geometry GPU program you can toggle on the `streamOut` parameter.
+To create a vertex buffer call @ref bs::VertexBufferCore::create "VertexBufferCore::create". You need to know the size of an individual vertex (determined by the properties each vertex requires) and the number of vertices. Optionally if your vertex buffer is used for output from the geometry GPU program you can toggle on the `streamOut` parameter.
 
-Once the vertex buffer is created you will want to populate it with some data (detailed below) and then bind it to the pipeline using @ref BansheeEngine::RenderAPICore::setVertexBuffers "RenderAPICore::setVertexBuffers". You can bind one or multiple vertex buffers at once. They all must have the same vertex counts but can have different properties, which will all be fed to the pipeline when rendering.
+Once the vertex buffer is created you will want to populate it with some data (detailed below) and then bind it to the pipeline using @ref bs::RenderAPICore::setVertexBuffers "RenderAPICore::setVertexBuffers". You can bind one or multiple vertex buffers at once. They all must have the same vertex counts but can have different properties, which will all be fed to the pipeline when rendering.
 
 Creation of an example vertex buffer:
 ~~~~~~~~~~~~~{.cpp}
@@ -175,10 +175,10 @@ rapi.setVertexBuffers(0, { vb });
 ~~~~~~~~~~~~~
 
 ## Reading/writing {#renderAPI_d_a}
-@ref BansheeEngine::VertexBufferCore "VertexBuffer" provides a couple of way to read and write data from/to it:
- - @ref BansheeEngine::VertexBufferCore::lock "VertexBufferCore::lock" locks a specific region of the vertex buffer and returns a pointer you can then use for reading and writing. Make sure to specify valid @ref BansheeEngine::GpuLockOptions "GpuLockOptions" signaling whether you are planning on read or writing from the buffer. Once done call @ref BansheeEngine::VertexBufferCore::unlock "VertexBufferCore::unlock" to make the locked region accessible to the GPU again.
- - @ref BansheeEngine::VertexBufferCore::readData "VertexBufferCore::readData" and @ref BansheeEngine::VertexBufferCore::writeData "VertexBufferCore::writeData" to write or read entire blocks at once, but are more or less similar to the previous method.
- - @ref BansheeEngine::VertexBufferCore::copyData "VertexBufferCore::copyData" can be used to efficiently copy data between two vertex buffers.
+@ref bs::VertexBufferCore "VertexBuffer" provides a couple of way to read and write data from/to it:
+ - @ref bs::VertexBufferCore::lock "VertexBufferCore::lock" locks a specific region of the vertex buffer and returns a pointer you can then use for reading and writing. Make sure to specify valid @ref bs::GpuLockOptions "GpuLockOptions" signaling whether you are planning on read or writing from the buffer. Once done call @ref bs::VertexBufferCore::unlock "VertexBufferCore::unlock" to make the locked region accessible to the GPU again.
+ - @ref bs::VertexBufferCore::readData "VertexBufferCore::readData" and @ref bs::VertexBufferCore::writeData "VertexBufferCore::writeData" to write or read entire blocks at once, but are more or less similar to the previous method.
+ - @ref bs::VertexBufferCore::copyData "VertexBufferCore::copyData" can be used to efficiently copy data between two vertex buffers.
 
 An example of writing to the vertex buffer:
 ~~~~~~~~~~~~~{.cpp}
@@ -190,7 +190,7 @@ Vector3* positions = (Vector3)vb->lock(0, sizeof(Vector3) * 8, GBL_WRITE_ONLY_DI
 vb->unlock();
 ~~~~~~~~~~~~~
 
-When your vertices contain multiple properties it can be difficult to keep track of which offset to write which property, or determine the stride between two vertices. For this purpose you can use @ref BansheeEngine::VertexDataDesc "VertexDataDesc" which allows you to easily set up vertex properties like so:
+When your vertices contain multiple properties it can be difficult to keep track of which offset to write which property, or determine the stride between two vertices. For this purpose you can use @ref bs::VertexDataDesc "VertexDataDesc" which allows you to easily set up vertex properties like so:
 ~~~~~~~~~~~~~{.cpp}
 // Create a vertex with a position, normal and UV coordinates
 SPtr<VertexDataDesc> vertexDesc = VertexDataDesc::create();
@@ -199,12 +199,12 @@ vertexDesc->addVertElem(VET_FLOAT3, VES_NORMAL);
 vertexDesc->addVertElem(VET_FLOAT2, VES_TEXCOORD);
 ~~~~~~~~~~~~~
 
-You can then use methods like @ref BansheeEngine::VertexDataDesc::getElementSize "VertexDataDesc::getElementSize" to learn the size of a particular element, @ref BansheeEngine::VertexDataDesc::getVertexStride "VertexDataDesc::getVertexStride" to learn the stride between elements. You can also retrieve detailed per-property information by iterating over all properties with @ref BansheeEngine::VertexDataDesc::getNumElements "VertexDataDesc::getNumElements" and @ref BansheeEngine::VertexDataDesc::getElement "VertexDataDesc::getElement". These methods return a @ref BansheeEngine::VertexElement "VertexElement" which can be used for finding out the offset of the individual element.
+You can then use methods like @ref bs::VertexDataDesc::getElementSize "VertexDataDesc::getElementSize" to learn the size of a particular element, @ref bs::VertexDataDesc::getVertexStride "VertexDataDesc::getVertexStride" to learn the stride between elements. You can also retrieve detailed per-property information by iterating over all properties with @ref bs::VertexDataDesc::getNumElements "VertexDataDesc::getNumElements" and @ref bs::VertexDataDesc::getElement "VertexDataDesc::getElement". These methods return a @ref bs::VertexElement "VertexElement" which can be used for finding out the offset of the individual element.
 
 To learn more about vertex descriptors read the [mesh](@ref meshes) manual.
 
 ## Vertex declaration {#renderAPI_d_b}
-Before a vertex buffer can be used for rendering, you need to tell the pipeline in what format are its vertices structured in. You do that by creating a @ref BansheeEngine::VertexDeclarationCore "VertexDeclarationCore" object using the @ref BansheeEngine::VertexDataDesc "VertexDataDesc" we described in the previous section. This object can then be passed to @ref BansheeEngine::RenderAPICore::setVertexDeclaration "RenderAPICore::setVertexDeclaration" to bind it to the pipeline.
+Before a vertex buffer can be used for rendering, you need to tell the pipeline in what format are its vertices structured in. You do that by creating a @ref bs::VertexDeclarationCore "VertexDeclarationCore" object using the @ref bs::VertexDataDesc "VertexDataDesc" we described in the previous section. This object can then be passed to @ref bs::RenderAPICore::setVertexDeclaration "RenderAPICore::setVertexDeclaration" to bind it to the pipeline.
 
 For example:
 ~~~~~~~~~~~~~{.cpp}
@@ -218,27 +218,27 @@ rapi.setVertexDeclaration(vertexDecl);
 It is important that the vertex declaration contains properties needed by the bound vertex GPU program, as well as that it matches the vertex layout in the vertex buffer. See the [gpu program](@ref gpuPrograms) manual to learn how to retrieve vertex properties expected by a GPU program.
 
 # Index buffer {#renderAPI_e}
-Normally when you draw data from a vertex buffer, the vertices are assumed to form primitives sequentially (e.g. every three vertices is a triangle). By using an @ref BansheeEngine::IndexBufferCore "index buffer" you an provide an additional layer of abstraction. Index buffer is fully optional, but when bound it will be used for forming primitives instead of the vertex buffer (i.e. every three indices will form a triangle). Each entry in an index buffer points to a vertex in the vertex buffer. This level of abstraction allows you to re-use the same vertex in multiple primitives, as well as create more optimal vertex order for GPU processing.
+Normally when you draw data from a vertex buffer, the vertices are assumed to form primitives sequentially (e.g. every three vertices is a triangle). By using an @ref bs::IndexBufferCore "index buffer" you an provide an additional layer of abstraction. Index buffer is fully optional, but when bound it will be used for forming primitives instead of the vertex buffer (i.e. every three indices will form a triangle). Each entry in an index buffer points to a vertex in the vertex buffer. This level of abstraction allows you to re-use the same vertex in multiple primitives, as well as create more optimal vertex order for GPU processing.
 
-To create an index buffer call @ref BansheeEngine::IndexBufferCore::create "IndexBufferCore::create". It expects a number of indices, and the type of indices. Index type can be either 16- or 32-bit. To bind an index buffer to the pipeline call @ref BansheeEngine::RenderAPICore::setIndexBuffer "RenderAPICore::setIndexBuffer".
+To create an index buffer call @ref bs::IndexBufferCore::create "IndexBufferCore::create". It expects a number of indices, and the type of indices. Index type can be either 16- or 32-bit. To bind an index buffer to the pipeline call @ref bs::RenderAPICore::setIndexBuffer "RenderAPICore::setIndexBuffer".
 
 Reading and writing from/to the index buffer has the identical interface to the vertex buffer, so we won't show it again.
 
 # Drawing {#renderAPI_f}
-Once all the previous states, programs and buffers have been set up, we can finally render our object. First of we must set up the type of primitives we wish to render by calling @ref BansheeEngine::RenderAPICore::setDrawOperation "RenderAPICore::setDrawOperation" with a @ref BansheeEngine::DrawOperationType "DrawOperationType" specifying the primitive type. This determines how the the vertices (or indices) in our buffers interpreted.
+Once all the previous states, programs and buffers have been set up, we can finally render our object. First of we must set up the type of primitives we wish to render by calling @ref bs::RenderAPICore::setDrawOperation "RenderAPICore::setDrawOperation" with a @ref bs::DrawOperationType "DrawOperationType" specifying the primitive type. This determines how the the vertices (or indices) in our buffers interpreted.
 
-After that you can issue a @ref BansheeEngine::RenderAPICore::draw "RenderAPICore::draw" call if rendering without an index buffer. It expects the vertex index to start rendering from, and the number of vertices to render. The number of vertices must be divisible by the number of vertices expected by the @ref BansheeEngine::DrawOperationType "DrawOperationType" you're using (e.g. three for triangles, two for lines, one for points). The vertices will then be pulled from the vertex buffers, processed by the fixed pipeline controlled by the states, and by the programmable pipeline controlled by the GPU programs and the output image will be rendered to the bound render target.
+After that you can issue a @ref bs::RenderAPICore::draw "RenderAPICore::draw" call if rendering without an index buffer. It expects the vertex index to start rendering from, and the number of vertices to render. The number of vertices must be divisible by the number of vertices expected by the @ref bs::DrawOperationType "DrawOperationType" you're using (e.g. three for triangles, two for lines, one for points). The vertices will then be pulled from the vertex buffers, processed by the fixed pipeline controlled by the states, and by the programmable pipeline controlled by the GPU programs and the output image will be rendered to the bound render target.
 
-If using an index buffer you should issue a @ref BansheeEngine::RenderAPICore::drawIndexed "RenderAPICore::drawIndexed" call. Aside from vertex offset/count, it also expects an offset into the index buffer to start rendering from, and number of indices to render from. In this case the vertex offset will be added to every read index, allowing you to re-use the index buffer for potentially different geometry. 
+If using an index buffer you should issue a @ref bs::RenderAPICore::drawIndexed "RenderAPICore::drawIndexed" call. Aside from vertex offset/count, it also expects an offset into the index buffer to start rendering from, and number of indices to render from. In this case the vertex offset will be added to every read index, allowing you to re-use the index buffer for potentially different geometry. 
  
 And this wraps up the rendering pipeline. After this step your object should be rendered to your render target and ready to display. 
  
 # Compute {#renderAPI_g}
 The compute pipeline is a very simple pipeline that can be used for general purpose calculations. It is separate from the graphics pipeline we have been describing so far, but uses the same functionality, just in a more limited way. You don't have to set fixed states, render targets, vertex/index buffers and only one GPU program type is supported (compute GPU program).
 
-The pipeline is represented with the @ref BansheeEngine::ComputePipelineStateCore "ComputePipelineStateCore" object, which must be initialized with the compute GPU program to use.
+The pipeline is represented with the @ref bs::ComputePipelineStateCore "ComputePipelineStateCore" object, which must be initialized with the compute GPU program to use.
 
-After creation use @ref BansheeEngine::RenderAPICore::setComputePipeline "RenderAPICore::setComputePipeline" to bind the pipeline for further operations. When the pipeline is set up you can execute it by calling @ref BansheeEngine::RenderAPICore::dispatchCompute "RenderAPICore::dispatchCompute". You should provide it a three dimensional number that determines how many instances of the currently bound GPU program to execute. The total number of executions will be X * Y * Z.
+After creation use @ref bs::RenderAPICore::setComputePipeline "RenderAPICore::setComputePipeline" to bind the pipeline for further operations. When the pipeline is set up you can execute it by calling @ref bs::RenderAPICore::dispatchCompute "RenderAPICore::dispatchCompute". You should provide it a three dimensional number that determines how many instances of the currently bound GPU program to execute. The total number of executions will be X * Y * Z.
 
 Since compute pipeline doesn't support render targets, you will want to use load-store textures for output. An example of a simple compute pipeline:
 ~~~~~~~~~~~~~{.cpp}
@@ -260,16 +260,16 @@ rapi.dispatchCompute(512, 512);
 We won't go any deeper about the details of the compute pipeline as this information can be found by learning about the GPU pipeline in general from other sources.
 
 # API specifics {#renderAPI_h}
-@ref BansheeEngine::RenderAPI "RenderAPI" can be internally implemented by a variety of actual rendering API's like DirectX or OpenGL. Most of the functionality is shared, but there are always some differences between them to be noted (for example DirectX uses a depth range of [0, 1] while OpenGL uses [-1, 1]). Often those differences can be important for various rendering algorithms.
+@ref bs::RenderAPI "RenderAPI" can be internally implemented by a variety of actual rendering API's like DirectX or OpenGL. Most of the functionality is shared, but there are always some differences between them to be noted (for example DirectX uses a depth range of [0, 1] while OpenGL uses [-1, 1]). Often those differences can be important for various rendering algorithms.
 
-Use @ref BansheeEngine::RenderAPI::getAPIInfo "RenderAPI::getAPIInfo" to receive the @ref BansheeEngine::RenderAPIInfo "RenderAPIInfo" containing such information, so you may modify your rendering accordingly. 
+Use @ref bs::RenderAPI::getAPIInfo "RenderAPI::getAPIInfo" to receive the @ref bs::RenderAPIInfo "RenderAPIInfo" containing such information, so you may modify your rendering accordingly. 
 
-For convenience a specialized @ref BansheeEngine::RenderAPI::convertProjectionMatrix "RenderAPI::convertProjectionMatrix" method is also provided, which converts a generic engine projection matrix, into a render API specific one.
+For convenience a specialized @ref bs::RenderAPI::convertProjectionMatrix "RenderAPI::convertProjectionMatrix" method is also provided, which converts a generic engine projection matrix, into a render API specific one.
 
 # Command buffers {#renderAPI_i}
-Almost all @ref BansheeEngine::RenderAPICore "RenderAPICore" commands we talked about so far support @ref BansheeEngine::CommandBuffer "CommandBuffer"s. Command buffers are optional, but they allow the rendering commands to be generated from threads other than the core thread.
+Almost all @ref bs::RenderAPICore "RenderAPICore" commands we talked about so far support @ref bs::CommandBuffer "CommandBuffer"s. Command buffers are optional, but they allow the rendering commands to be generated from threads other than the core thread.
 
-To create a command buffer call @ref BansheeEngine::CommandBuffer::create "CommandBuffer::create" after which provide it to the relevant @ref BansheeEngine::RenderAPICore "RenderAPICore" calls. Those commands will get recorded in the command buffer, but not executed. To actually execute the commands call @ref BansheeEngine::RenderAPICore::executeCommands "RenderAPICore::executeCommands".
+To create a command buffer call @ref bs::CommandBuffer::create "CommandBuffer::create" after which provide it to the relevant @ref bs::RenderAPICore "RenderAPICore" calls. Those commands will get recorded in the command buffer, but not executed. To actually execute the commands call @ref bs::RenderAPICore::executeCommands "RenderAPICore::executeCommands".
 
 This allows rendering to be faster since work can be distributed over multiple CPU cores. Note that only command queuing can happen on a separate thread, command buffer creation and execution must still happen on the core thread.
 

Documentation/Manuals/Native/renderTargets.md

@@ -5,8 +5,8 @@ Render targets				{#renderTargets}
 Render targets represent destination surfaces onto which objects are rendered. They can be textures or windows.
 
 In Banshee render targets are represented with:
- - Windows - @ref BansheeEngine::RenderWindow "RenderWindow" and @ref BansheeEngine::RenderWindowCore "RenderWindowCore"
- - Textures - @ref BansheeEngine::RenderTexture "RenderTexture" and @ref BansheeEngine::RenderTextureCore "RenderTextureCore"
+ - Windows - @ref bs::RenderWindow "RenderWindow" and @ref bs::RenderWindowCore "RenderWindowCore"
+ - Textures - @ref bs::RenderTexture "RenderTexture" and @ref bs::RenderTextureCore "RenderTextureCore"
  
 Each type comes in two variants, both of which provide almost equivalent functionality, but the former is for use on the simulation thread, and the latter is for use on the core thread. If you are confused by the dual nature of the objects, read the [core thread](@ref coreThread) manual. 
 
@@ -15,26 +15,26 @@ We're going to focus on the simulation thread implementation in this manual, and
 # Render windows {#renderTargets_a}
 Render windows are render targets that are backed up by OS-specific windows. Each application must have at least one render window in order to display its contents to the user. All created windows are double or triple buffered, meaning they internally have multiple render surfaces that are swapped between during rendering (see the section about rendering later). This makes them useful for displaying final rendering results in the screen, while render textures are used for intermediary processing.
 
-Creating a @ref BansheeEngine::RenderWindow "RenderWindow" involves filling out the @ref BansheeEngine::RENDER_WINDOW_DESC "RENDER_WINDOW_DESC" and calling @ref BansheeEngine::RenderWindow::create "RenderWindow::create". This method also accepts a parent render window, in case your window is meant to be a child of another window. @ref BansheeEngine::RENDER_WINDOW_DESC "RENDER_WINDOW_DESC" contains many properties, and you should read its reference for information about what all of them do. In this manual we'll just cover the most important settings:
+Creating a @ref bs::RenderWindow "RenderWindow" involves filling out the @ref bs::RENDER_WINDOW_DESC "RENDER_WINDOW_DESC" and calling @ref bs::RenderWindow::create "RenderWindow::create". This method also accepts a parent render window, in case your window is meant to be a child of another window. @ref bs::RENDER_WINDOW_DESC "RENDER_WINDOW_DESC" contains many properties, and you should read its reference for information about what all of them do. In this manual we'll just cover the most important settings:
 
-@ref BansheeEngine::RENDER_WINDOW_DESC::videoMode "RENDER_WINDOW_DESC::videoMode"
+@ref bs::RENDER_WINDOW_DESC::videoMode "RENDER_WINDOW_DESC::videoMode"
  - This is the only field that is required, all others are optional. It controls the resolution of the render target, and output monitor and its refresh rate. 
 
-You can create a @ref BansheeEngine::VideoMode "VideoMode" manually by providing a custom resolution and a refresh rate, or you can query @ref BansheeEngine::RenderAPI::getVideoModeInfo "RenderAPI::getVideoModeInfo" to retrieve all available video modes for all available monitors. The latter is the suggested method as it guarantees the video mode will be compatible with the hardware.
+You can create a @ref bs::VideoMode "VideoMode" manually by providing a custom resolution and a refresh rate, or you can query @ref bs::RenderAPI::getVideoModeInfo "RenderAPI::getVideoModeInfo" to retrieve all available video modes for all available monitors. The latter is the suggested method as it guarantees the video mode will be compatible with the hardware.
 
-@ref BansheeEngine::RENDER_WINDOW_DESC::fullscreen "RENDER_WINDOW_DESC::fullscreen"
+@ref bs::RENDER_WINDOW_DESC::fullscreen "RENDER_WINDOW_DESC::fullscreen"
  - Controlls whether or not to create the window in fullscreen mode. Fullscreen mode gives your application the exclusive access for rendering device. Without it refresh rate and vsync options are ignored.
 
-@ref BansheeEngine::RENDER_WINDOW_DESC::vsync "RENDER_WINDOW_DESC::vsync"
+@ref bs::RENDER_WINDOW_DESC::vsync "RENDER_WINDOW_DESC::vsync"
  - Controls whether the GPU should wait for the vertical sync before presenting the rendered image. This prevents screen tearing. 
 
-@ref BansheeEngine::RENDER_WINDOW_DESC::multisampleCount "RENDER_WINDOW_DESC::multisampleCount"
+@ref bs::RENDER_WINDOW_DESC::multisampleCount "RENDER_WINDOW_DESC::multisampleCount"
  - Controls whether you want the render window target to be a multisampled surface. This allows you to perform MSAA antialiasing and similar effects. Most applications will set this to false and instead use multi-sampled render textures, and use the render window for displaying the final resolved (antialiased) image.
 
-@ref BansheeEngine::RENDER_WINDOW_DESC::depthBuffer "RENDER_WINDOW_DESC::depthBuffer"
+@ref bs::RENDER_WINDOW_DESC::depthBuffer "RENDER_WINDOW_DESC::depthBuffer"
  - Controls whether the render window should also contain a depth/stencil buffer. This is useful if you are not using intermediary render textures and are rendering directly to the render window. Most applications will set this to false and create the depth/stencil buffer manually as a render texture (see below).
 
-@ref BansheeEngine::RENDER_WINDOW_DESC::gamma "RENDER_WINDOW_DESC::gamma"
+@ref bs::RENDER_WINDOW_DESC::gamma "RENDER_WINDOW_DESC::gamma"
  - Controls whether or not should pixels written to be render target be automatically gamma corrected (multiplied by inverse sRGB gamma). If your rendering calculations are in linear space and you aren't performing gamma correction manually you should set this to true.
 
 An example that creates a 1280x720 window:
@@ -48,23 +48,23 @@ SPtr<RenderWindow> window = RenderWindow::create(desc);
 
 ## Manipulating the window {#renderTargets_a_a}
 Once the window is created you can perform the following actions:
- - @ref BansheeEngine::RenderWindow::resize "RenderWindow::resize"
- - @ref BansheeEngine::RenderWindow::move "RenderWindow::move"
- - @ref BansheeEngine::RenderWindow::setFullscreen "RenderWindow::setFullscreen"
- - @ref BansheeEngine::RenderWindow::setWindowed "RenderWindow::setWindowed"
+ - @ref bs::RenderWindow::resize "RenderWindow::resize"
+ - @ref bs::RenderWindow::move "RenderWindow::move"
+ - @ref bs::RenderWindow::setFullscreen "RenderWindow::setFullscreen"
+ - @ref bs::RenderWindow::setWindowed "RenderWindow::setWindowed"
  
-And more. Read the @ref BansheeEngine::RenderWindow "RenderWindow" reference for the rest.
+And more. Read the @ref bs::RenderWindow "RenderWindow" reference for the rest.
 
 You can also use the window to convert between screen and window coordinates by calling:
- - @ref BansheeEngine::RenderWindow::screenToWindowPos "RenderWindow::screenToWindowPos"
- - @ref BansheeEngine::RenderWindow::windowToScreenPos "RenderWindow::windowToScreenPos"
+ - @ref bs::RenderWindow::screenToWindowPos "RenderWindow::screenToWindowPos"
+ - @ref bs::RenderWindow::windowToScreenPos "RenderWindow::windowToScreenPos"
  
 # Render textures {#renderTargets_b}
-Render textures are simpler than windows, but you are given more control over their format. Internally a render texture is just a @ref BansheeEngine::Texture "Texture" created with the @ref BansheeEngine::TU_RENDERTARGET "TU_RENDERTARGET" flag. Read the [texture](@ref textures) manual to learn how to create such textures.
+Render textures are simpler than windows, but you are given more control over their format. Internally a render texture is just a @ref bs::Texture "Texture" created with the @ref bs::TU_RENDERTARGET "TU_RENDERTARGET" flag. Read the [texture](@ref textures) manual to learn how to create such textures.
 
-Render texture must contain at least one texture (color surface), but may optionally also contain a depth-stencil surface. Depth-stencil surface is also a @ref BansheeEngine::Texture "Texture", but one created with the @ref BansheeEngine::TU_DEPTHSTENCIL "TU_DEPTHSTENCIL" flag. Depth stencil surfaces only accept specific pixel formats starting with "D" prefix in @ref BansheeEngine::PixelFormat "PixelFormat". Dimensions of the depth stencil surface must match the color surface.
+Render texture must contain at least one texture (color surface), but may optionally also contain a depth-stencil surface. Depth-stencil surface is also a @ref bs::Texture "Texture", but one created with the @ref bs::TU_DEPTHSTENCIL "TU_DEPTHSTENCIL" flag. Depth stencil surfaces only accept specific pixel formats starting with "D" prefix in @ref bs::PixelFormat "PixelFormat". Dimensions of the depth stencil surface must match the color surface.
 
-To create a render texture call @ref BansheeEngine::RenderTexture::create(const RENDER_TEXTURE_DESC&) "RenderTexture::create" with a populated @ref BansheeEngine::RENDER_TEXTURE_DESC "RENDER_TEXTURE_DESC" structure. This structure expects a reference to one or more color surface textures, and an optional depth-stencil surface texture. For each of those you must also specify the face and mip level onto which to render, in case your texture has multiple.
+To create a render texture call @ref bs::RenderTexture::create(const RENDER_TEXTURE_DESC&) "RenderTexture::create" with a populated @ref bs::RENDER_TEXTURE_DESC "RENDER_TEXTURE_DESC" structure. This structure expects a reference to one or more color surface textures, and an optional depth-stencil surface texture. For each of those you must also specify the face and mip level onto which to render, in case your texture has multiple.
 
 For example:
 ~~~~~~~~~~~~~{.cpp}
@@ -100,7 +100,7 @@ desc.depthStencilSurface.mipLevel = 0;
 SPtr<RenderTexture> renderTexture = RenderTexture::create(desc);
 ~~~~~~~~~~~~~
 
-Optionally you can also use the overloaded @ref BansheeEngine::RenderTexture::create(const TEXTURE_DESC&, bool, PixelFormat) "RenderTexture::create" to create the texture surfaces and the render texture in one go:
+Optionally you can also use the overloaded @ref bs::RenderTexture::create(const TEXTURE_DESC&, bool, PixelFormat) "RenderTexture::create" to create the texture surfaces and the render texture in one go:
 ~~~~~~~~~~~~~{.cpp}
 // Has the same result as above:
 TEXTURE_DESC colorDesc;
@@ -113,39 +113,39 @@ SPtr<RenderTexture> renderTexture = RenderTexture::create(colorDesc, true, PF_D2
 ~~~~~~~~~~~~~
 
 ## Multiple surfaces {#renderTargets_b_a}
-Render textures can also contain multiple color surfaces (up to 8). Such targets simply allow you to write more data at once, improving performance as you do not need to execute multiple draw calls. To create a texture with multiple color surfaces simply fill out other entries of @ref BansheeEngine::RENDER_TEXTURE_DESC "RENDER_TEXTURE_DESC::colorSurfaces" array and proceed the same as in the above example.
+Render textures can also contain multiple color surfaces (up to 8). Such targets simply allow you to write more data at once, improving performance as you do not need to execute multiple draw calls. To create a texture with multiple color surfaces simply fill out other entries of @ref bs::RENDER_TEXTURE_DESC "RENDER_TEXTURE_DESC::colorSurfaces" array and proceed the same as in the above example.
 
 Use `BS_MAX_MULTIPLE_RENDER_TARGETS` to learn what is the maximum supported number of color surfaces per target (usually 8). All color surfaces (and the depth/stencil surface) must have the same dimensions and sample count.
 
 ## Multi-sampled surfaces {#renderTargets_b_c}
-Same as windows, render textures can be created with support for multiple samples per pixel. This allows affects such as multi-sampled antialiasing and similar. To create a multi-sampled render texture simply create a @ref BansheeEngine::Texture "Texture" with its `multisampleCount` parameter larger than one, which you then use to initialize a render texture. Make sure that all surfaces (including depth-stencil) in a render texture have the same number of samples.
+Same as windows, render textures can be created with support for multiple samples per pixel. This allows affects such as multi-sampled antialiasing and similar. To create a multi-sampled render texture simply create a @ref bs::Texture "Texture" with its `multisampleCount` parameter larger than one, which you then use to initialize a render texture. Make sure that all surfaces (including depth-stencil) in a render texture have the same number of samples.
 
-In order to display a multi-sampled render texture on the screen you need to resolve the texture into a non-multi-sampled one. For windows this is done automatically for you, but for textures you must do it manually. You can do it from the GPU program (render API dependant), or by calling @ref BansheeEngine::TextureCore::copy "TextureCore::copy". 
+In order to display a multi-sampled render texture on the screen you need to resolve the texture into a non-multi-sampled one. For windows this is done automatically for you, but for textures you must do it manually. You can do it from the GPU program (render API dependant), or by calling @ref bs::TextureCore::copy "TextureCore::copy". 
 
-@ref BansheeEngine::TextureCore::copy "TextureCore::copy" works only on the core thread, and it will copy contents of one texture to another texture. If you ensure that the source texture is multi-sampled but the destination is not, it will automatically resolve the multi-sampled texture.
+@ref bs::TextureCore::copy "TextureCore::copy" works only on the core thread, and it will copy contents of one texture to another texture. If you ensure that the source texture is multi-sampled but the destination is not, it will automatically resolve the multi-sampled texture.
 
 # Priority {#renderTargets_c}
-All render targets have a priority that can be set by calling @ref BansheeEngine::RenderTarget::setPriority "RenderTarget::setPriority". This priority can be used as a hint to the renderer in which order should the targets be rendered to. Targets with higher priority will be rendered to before targets with lower priority. If you are rendering manually using the @ref BansheeEngine::RenderAPI "RenderAPI" then this value is not used.
+All render targets have a priority that can be set by calling @ref bs::RenderTarget::setPriority "RenderTarget::setPriority". This priority can be used as a hint to the renderer in which order should the targets be rendered to. Targets with higher priority will be rendered to before targets with lower priority. If you are rendering manually using the @ref bs::RenderAPI "RenderAPI" then this value is not used.
 
 # Using render targets {#renderTargets_d}
 Now that we know how to create a render target we can use it in one of various ways: render to it, read from it, clear it, or use its contents to render something else.
 
 ## Rendering to targets {#renderTargets_d_a}
-Use @ref BansheeEngine::RenderAPI::setRenderTarget "RenderAPI::setRenderTarget" to bind a render target for rendering. After binding you may issue draw calls, after which you should follow it with a call to @ref BansheeEngine::RenderAPI::swapBuffers "RenderAPI::swapBuffers" if the target has multiple buffers (like a window). Read the [render API](@ref renderAPI) manual for more information.
+Use @ref bs::RenderAPI::setRenderTarget "RenderAPI::setRenderTarget" to bind a render target for rendering. After binding you may issue draw calls, after which you should follow it with a call to @ref bs::RenderAPI::swapBuffers "RenderAPI::swapBuffers" if the target has multiple buffers (like a window). Read the [render API](@ref renderAPI) manual for more information.
 
 ## Clearing targets {#renderTargets_d_b}
-Call @ref BansheeEngine::RenderAPI::clearRenderTarget "RenderAPI::clearRenderTarget" to clear all or portions of a render target to a specific color/value. Read the [render API](@ref renderAPI) manual for more information.
+Call @ref bs::RenderAPI::clearRenderTarget "RenderAPI::clearRenderTarget" to clear all or portions of a render target to a specific color/value. Read the [render API](@ref renderAPI) manual for more information.
 
 ## Reading from targets {#renderTargets_d_c}
-If you wish to read render target pixels from the CPU, you can use the normal @ref BansheeEngine::Texture "Texture" read functionality as described in the [texture](@ref textures) manual. To retrieve a @ref BansheeEngine::Texture "Texture" from a @ref BansheeEngine::RenderTexture "RenderTexture" call the following methods:
- - @ref BansheeEngine::RenderTexture::getColorTexture "RenderTexture::getColorTexture"
- - @ref BansheeEngine::RenderTexture::getDepthStencilTexture "RenderTexture::getDepthStencilTexture"
+If you wish to read render target pixels from the CPU, you can use the normal @ref bs::Texture "Texture" read functionality as described in the [texture](@ref textures) manual. To retrieve a @ref bs::Texture "Texture" from a @ref bs::RenderTexture "RenderTexture" call the following methods:
+ - @ref bs::RenderTexture::getColorTexture "RenderTexture::getColorTexture"
+ - @ref bs::RenderTexture::getDepthStencilTexture "RenderTexture::getDepthStencilTexture"
  
-Before reading you must make sure the render target is not currently bound for rendering otherwise this will fail. You cannot read from a @ref BansheeEngine::RenderWindow "RenderWindow".
+Before reading you must make sure the render target is not currently bound for rendering otherwise this will fail. You cannot read from a @ref bs::RenderWindow "RenderWindow".
 
 ## Rendering using the targets {#renderTargets_c_d}
-Sometimes you render to a render texture only to use it as input in another rendering operation. In such case the render texture is first used for writing, and then for reading. This case is similar to above, first you make sure that the render texture is not currently bound for writing, and then you call one of the above listed methods to retrieve the required @ref BansheeEngine::Texture "Texture".
+Sometimes you render to a render texture only to use it as input in another rendering operation. In such case the render texture is first used for writing, and then for reading. This case is similar to above, first you make sure that the render texture is not currently bound for writing, and then you call one of the above listed methods to retrieve the required @ref bs::Texture "Texture".
 
 Then you can bind the texture for rendering as normal (described in the [render API](@ref renderAPI) manual).
 
-For depth/stencil surfaces there is a special case where you might need to leave them bound as a render target to be used for depth/stencil testing (not writing), but also for reading within a GPU program. In such a case you can call @ref BansheeEngine::RenderAPI::setRenderTarget "RenderAPI::setRenderTarget" with `readOnlyDepthStencil` parameter set to true.
+For depth/stencil surfaces there is a special case where you might need to leave them bound as a render target to be used for depth/stencil testing (not writing), but also for reading within a GPU program. In such a case you can call @ref bs::RenderAPI::setRenderTarget "RenderAPI::setRenderTarget" with `readOnlyDepthStencil` parameter set to true.

Documentation/Manuals/Native/renderer.md

@@ -7,15 +7,15 @@ Renderer is a system that processes all renderable objects in the scene, renders
 In this manual we'll explain how to use a renderer to render objects in the scene, as well as how to implement your own renderer.
 
 # Rendering scene objects {#renderer_a}
-To render objects in the scene create a @ref BansheeEngine::SceneObject "SceneObject" onto which you then attach relevant @ref BansheeEngine::Component "Components". These @ref BansheeEngine::Component "Components" then register themselves with the renderer, which takes care of everything else. See the [game object](@ref gameObjects) manual for more information about scene objects and components.
+To render objects in the scene create a @ref bs::SceneObject "SceneObject" onto which you then attach relevant @ref bs::Component "Components". These @ref bs::Component "Components" then register themselves with the renderer, which takes care of everything else. See the [game object](@ref gameObjects) manual for more information about scene objects and components.
 
 There are three primary types of components used for rendering:
- - @ref BansheeEngine::CCamera "CCamera" - A camera used for viewing the scene.
- - @ref BansheeEngine::CRenderable "CRenderable" - An object to render.
- - @ref BansheeEngine::CLight "CLight" - A light to illuminate the objects with.
+ - @ref bs::CCamera "CCamera" - A camera used for viewing the scene.
+ - @ref bs::CRenderable "CRenderable" - An object to render.
+ - @ref bs::CLight "CLight" - A light to illuminate the objects with.
  
 ## Camera {#renderer_a_a}
-@ref BansheeEngine::CCamera "Camera" component determines which portion of the scene is being rendered, onto which surface, and how. Before you create a camera you must first create a @ref BansheeEngine::RenderTarget "RenderTarget" onto which the camera will output the rendered image. See the [render targets](@ref renderTargets) manual for information on how to create render targets.
+@ref bs::CCamera "Camera" component determines which portion of the scene is being rendered, onto which surface, and how. Before you create a camera you must first create a @ref bs::RenderTarget "RenderTarget" onto which the camera will output the rendered image. See the [render targets](@ref renderTargets) manual for information on how to create render targets.
 
 See the following example to create a camera:
 ~~~~~~~~~~~~~{.cpp}
@@ -25,24 +25,24 @@ HSceneObject cameraSO = SceneObject::create("Camera");
 HCamera camera = cameraSO->addComponent<CCamera>(rt);
 ~~~~~~~~~~~~~
 
-The transform of the camera's parent scene object determines which portion of the scene does the camera see. You can position and rotate the camera using the standard @ref BansheeEngine::SceneObject "SceneObject" transform methods:
+The transform of the camera's parent scene object determines which portion of the scene does the camera see. You can position and rotate the camera using the standard @ref bs::SceneObject "SceneObject" transform methods:
 ~~~~~~~~~~~~~{.cpp}
 cameraSO->setPosition(Vector3(0, 0, 50)); // Move camera to (0, 0, 50)
 cameraSO->lookAt(Vector3(0, 0, 0)); // Look towards origin
 ~~~~~~~~~~~~~
 
-You may also adjust various other properties of the camera, including @ref BansheeEngine::ProjectionType "projection type", field of view, aspect ratio and similar using methods like @ref BansheeEngine::CCamera::setProjectionType "CCamera::setProjectionType", @ref BansheeEngine::CCamera::setHorzFOV "CCamera::setHorzFOV" and @ref BansheeEngine::CCamera::setAspectRatio "CCamera::setAspectRatio". See the @ref BansheeEngine::CCamera "Camera" API documentation for a full list of methods.
+You may also adjust various other properties of the camera, including @ref bs::ProjectionType "projection type", field of view, aspect ratio and similar using methods like @ref bs::CCamera::setProjectionType "CCamera::setProjectionType", @ref bs::CCamera::setHorzFOV "CCamera::setHorzFOV" and @ref bs::CCamera::setAspectRatio "CCamera::setAspectRatio". See the @ref bs::CCamera "Camera" API documentation for a full list of methods.
 
-Each camera be assigned a priority via @ref BansheeEngine::CCamera::setPriority "CCamera::setPriority". The priority determines in which order are multiple cameras rendered. Higher priority means the camera will be rendered sooner. Be aware that render targets also have priority, and their priority takes precedance over camera's priority. Camera priority only matters if multiple cameras are rendering to the same render target.
+Each camera be assigned a priority via @ref bs::CCamera::setPriority "CCamera::setPriority". The priority determines in which order are multiple cameras rendered. Higher priority means the camera will be rendered sooner. Be aware that render targets also have priority, and their priority takes precedance over camera's priority. Camera priority only matters if multiple cameras are rendering to the same render target.
 
-Camera can also be assigned a layer via @ref BansheeEngine::CCamera::setLayers "CCamera::setLayers". The layer is a bitmask that can be used for filtering which objects does the camera render. As we'll see later, each renderable object can also be assigned a layer. Any object whose layer ORed with the camera's layer bitmask is non-zero will be rendered to the camera.
+Camera can also be assigned a layer via @ref bs::CCamera::setLayers "CCamera::setLayers". The layer is a bitmask that can be used for filtering which objects does the camera render. As we'll see later, each renderable object can also be assigned a layer. Any object whose layer ORed with the camera's layer bitmask is non-zero will be rendered to the camera.
 
-A variety of methods for converting between world, view, projection, clip and NDC spaces are also provided by the camera. For example see @ref BansheeEngine::CCamera::screenPointToRay "CCamera::screenPointToRay".
+A variety of methods for converting between world, view, projection, clip and NDC spaces are also provided by the camera. For example see @ref bs::CCamera::screenPointToRay "CCamera::screenPointToRay".
 
-You may also retrieve the camera's projection and view matrices by calling @ref BansheeEngine::CCamera::getProjectionMatrix "CCamera::getProjectionMatrix" and @ref BansheeEngine::CCamera::getViewMatrix "CCamera::getViewMatrix" respectively.
+You may also retrieve the camera's projection and view matrices by calling @ref bs::CCamera::getProjectionMatrix "CCamera::getProjectionMatrix" and @ref bs::CCamera::getViewMatrix "CCamera::getViewMatrix" respectively.
 
 ## Renderable {#renderer_a_b}
-Once the camera in the scene is set up, you can start adding object you wish to render. All such objects are represented with the @ref BansheeEngine::CRenderable "CRenderable" component. This is a fairly simple components that expects only a @ref BansheeEngine::Mesh "Mesh" and one or multiple @ref BansheeEngine::Material "Material(s)". Read the [mesh](@ref meshes) and [material](@ref materials) manual for more information how to create them.
+Once the camera in the scene is set up, you can start adding object you wish to render. All such objects are represented with the @ref bs::CRenderable "CRenderable" component. This is a fairly simple components that expects only a @ref bs::Mesh "Mesh" and one or multiple @ref bs::Material "Material(s)". Read the [mesh](@ref meshes) and [material](@ref materials) manual for more information how to create them.
 
 See the following example to create a renderable object:
 ~~~~~~~~~~~~~{.cpp}
@@ -57,15 +57,15 @@ renderable->setMaterial(material);
 
 You can also optionally set multiple materials in case your mesh has multiple sub-meshes. In such case each material will be used for rendering one sub-mesh.
 
-And as we have mentioned in the previous section, each renderable can also be assigned a layer by calling @ref BansheeEngine::CRenderable::setLayer "CRenderable::setLayer", which in combination with camera's layer can be used for filtering on which camera(s) should the object be visible.
+And as we have mentioned in the previous section, each renderable can also be assigned a layer by calling @ref bs::CRenderable::setLayer "CRenderable::setLayer", which in combination with camera's layer can be used for filtering on which camera(s) should the object be visible.
 
 ## Light {#renderer_a_c}
-Finally we can choose to add a light to the scene. A light will influence the lighting and shadows of renderable objects in its radius. Use the @ref BansheeEngine::CLight "CLight" component to set up a light. Light comes in three variants:
+Finally we can choose to add a light to the scene. A light will influence the lighting and shadows of renderable objects in its radius. Use the @ref bs::CLight "CLight" component to set up a light. Light comes in three variants:
  - Point light that illuminates everything in a certain radius.
  - Spot light that illuminates everything within a certain angle and radius.
  - Directional light that illuminates everything at an infinite distance from a particular direction.
  
-You can choose between light variants by calling @ref BansheeEngine::CLight::setType "CLight::setType". You can also set parameters like light color, intensity, range and others. See the @ref BansheeEngine::CLight "CLight" API documentation for a full list.
+You can choose between light variants by calling @ref bs::CLight::setType "CLight::setType". You can also set parameters like light color, intensity, range and others. See the @ref bs::CLight "CLight" API documentation for a full list.
 
 An example creating a point light:
 ~~~~~~~~~~~~~{.cpp}
@@ -77,31 +77,31 @@ light->setIntensity(1000.0f);
 ~~~~~~~~~~~~~
 
 # Creating your own renderer {#renderer_b}
-Renderer is the system that makes use of all the components we listed so far. Renderer isn't actually aware of scene objects and components, and instead operates on @ref BansheeEngine::Camera "Camera", @ref BansheeEngine::Renderable "Renderable" and @ref BansheeEngine::Light "Light" types directly. These are the internal objects that are managed by @ref BansheeEngine::CCamera "CCamera", @ref BansheeEngine::CRenderable "CRenderable" and @ref BansheeEngine::CLight "CLight", respectively. They provide the same interface as their component versions. They are also @ref BansheeEngine::CoreObject "core objects", meaning they have both a simulation and a core thread counterparts.
-
-To create your own renderer you must implement the @ref BansheeEngine::Renderer "Renderer" interface. The implementation should iterate over all renderable objects, cameras and lights and perform rendering according to your own rules. At the end of rendering, every render target in every active camera should be filled with an image of the rendered scene. During rendering you must consider mesh and material provided by the renderable objects, and apply lighting according to light objects. You should use the low level @ref BansheeEngine::RenderAPI "RenderAPI" to render individual objects.
-
-The renderer is mostly a core-thread system as then it has a more direct access to the @ref BansheeEngine::RenderAPI "RenderAPI", as well as various utility functionality we'll describe later. Read the [core thread](@ref coreThread) manual for more information about the core thread and core objects, and the [render API](@ref renderAPI) manual on how to use the low level rendering functionality.
-
-The @ref BansheeEngine::Renderer "Renderer" interface requires you to implement the following methods:
- - @ref BansheeEngine::CoreRenderer::getName "Renderer::getName" - Returns a unique name of the renderer. This can be used by shader techniques to identify which renderer is active and when they should run, as described in the [material](@ref materials) manual.
- - @ref BansheeEngine::CoreRenderer::renderAll "Renderer::renderAll" - This is a method called from the simulation thread that executes the rendering. It is called once per frame. In this method you should queue your actual rendering method for execution on the core thread.
- - @ref BansheeEngine::CoreRenderer::notifyCameraAdded "Renderer::notifyCameraAdded" - Called on the core thread whenever a new @ref BansheeEngine::Camera "Camera" is created (i.e. when a @ref BansheeEngine::CCamera "CCamera" component is added to the scene). Also called when camera's properties change (camera is removed, then re-added).
- - @ref BansheeEngine::CoreRenderer::notifyCameraUpdated "Renderer::notifyCameraUpdated" - Called on the core thread whenever a @ref BansheeEngine::Camera "Camera's" position or rotation changes.
- - @ref BansheeEngine::CoreRenderer::notifyCameraRemoved "Renderer::notifyCameraRemoved" - Called on the core thread whenever a @ref BansheeEngine::Camera "Camera" is destroyed. Also called when camera's properties change (camera is removed, then re-added).
- - @ref BansheeEngine::Renderer::notifyRenderableAdded "Renderer::notifyRenderableAdded" - Called on the core thread whenever a new @ref BansheeEngine::Renderable "Renderable" is created (e.g. when a @ref BansheeEngine::CRenderable "CRenderable" component is added to the scene).
- - @ref BansheeEngine::Renderer::notifyRenderableUpdated "Renderer::notifyRenderableUpdated" - Called whenever @ref BansheeEngine::Renderable "Renderable" properties change, e.g. when a scene object a renderable is attached to moves.
- - @ref BansheeEngine::Renderer::notifyRenderableRemoved "Renderer::notifyRenderableRemoved" - Called whenever a @ref BansheeEngine::Renderable "Renderable" is destroyed.
- - @ref BansheeEngine::Renderer::notifyLightAdded "Renderer::notifyLightAdded" - Called whenever a new @ref BansheeEngine::Light "Light" is created (e.g. when a @ref BansheeEngine::CLight "CLight" component is added to the scene).
- - @ref BansheeEngine::Renderer::notifyLightUpdated "Renderer::notifyLightUpdated" - Called whenever @ref BansheeEngine::Light "Light" properties change, e.g. when a scene object a light is attached to moves.
- - @ref BansheeEngine::Renderer::notifyLightRemoved "Renderer::notifyLightRemoved" - Called whenever @ref BansheeEngine::Light "Light" is destroyed.
+Renderer is the system that makes use of all the components we listed so far. Renderer isn't actually aware of scene objects and components, and instead operates on @ref bs::Camera "Camera", @ref bs::Renderable "Renderable" and @ref bs::Light "Light" types directly. These are the internal objects that are managed by @ref bs::CCamera "CCamera", @ref bs::CRenderable "CRenderable" and @ref bs::CLight "CLight", respectively. They provide the same interface as their component versions. They are also @ref bs::CoreObject "core objects", meaning they have both a simulation and a core thread counterparts.
+
+To create your own renderer you must implement the @ref bs::Renderer "Renderer" interface. The implementation should iterate over all renderable objects, cameras and lights and perform rendering according to your own rules. At the end of rendering, every render target in every active camera should be filled with an image of the rendered scene. During rendering you must consider mesh and material provided by the renderable objects, and apply lighting according to light objects. You should use the low level @ref bs::RenderAPI "RenderAPI" to render individual objects.
+
+The renderer is mostly a core-thread system as then it has a more direct access to the @ref bs::RenderAPI "RenderAPI", as well as various utility functionality we'll describe later. Read the [core thread](@ref coreThread) manual for more information about the core thread and core objects, and the [render API](@ref renderAPI) manual on how to use the low level rendering functionality.
+
+The @ref bs::Renderer "Renderer" interface requires you to implement the following methods:
+ - @ref bs::CoreRenderer::getName "Renderer::getName" - Returns a unique name of the renderer. This can be used by shader techniques to identify which renderer is active and when they should run, as described in the [material](@ref materials) manual.
+ - @ref bs::CoreRenderer::renderAll "Renderer::renderAll" - This is a method called from the simulation thread that executes the rendering. It is called once per frame. In this method you should queue your actual rendering method for execution on the core thread.
+ - @ref bs::CoreRenderer::notifyCameraAdded "Renderer::notifyCameraAdded" - Called on the core thread whenever a new @ref bs::Camera "Camera" is created (i.e. when a @ref bs::CCamera "CCamera" component is added to the scene). Also called when camera's properties change (camera is removed, then re-added).
+ - @ref bs::CoreRenderer::notifyCameraUpdated "Renderer::notifyCameraUpdated" - Called on the core thread whenever a @ref bs::Camera "Camera's" position or rotation changes.
+ - @ref bs::CoreRenderer::notifyCameraRemoved "Renderer::notifyCameraRemoved" - Called on the core thread whenever a @ref bs::Camera "Camera" is destroyed. Also called when camera's properties change (camera is removed, then re-added).
+ - @ref bs::Renderer::notifyRenderableAdded "Renderer::notifyRenderableAdded" - Called on the core thread whenever a new @ref bs::Renderable "Renderable" is created (e.g. when a @ref bs::CRenderable "CRenderable" component is added to the scene).
+ - @ref bs::Renderer::notifyRenderableUpdated "Renderer::notifyRenderableUpdated" - Called whenever @ref bs::Renderable "Renderable" properties change, e.g. when a scene object a renderable is attached to moves.
+ - @ref bs::Renderer::notifyRenderableRemoved "Renderer::notifyRenderableRemoved" - Called whenever a @ref bs::Renderable "Renderable" is destroyed.
+ - @ref bs::Renderer::notifyLightAdded "Renderer::notifyLightAdded" - Called whenever a new @ref bs::Light "Light" is created (e.g. when a @ref bs::CLight "CLight" component is added to the scene).
+ - @ref bs::Renderer::notifyLightUpdated "Renderer::notifyLightUpdated" - Called whenever @ref bs::Light "Light" properties change, e.g. when a scene object a light is attached to moves.
+ - @ref bs::Renderer::notifyLightRemoved "Renderer::notifyLightRemoved" - Called whenever @ref bs::Light "Light" is destroyed.
  
-Implementing these methods should give you all the information you need to render your scene. You will have the required render target and projection/view matrices from the @ref BansheeEngine::Camera "Camera", mesh/material/world transform from @ref BansheeEngine::Renderable "Renderable" objects, and lighting information from @ref BansheeEngine::Light "Light". Use the information provided in the [render API](@ref renderAPI) manual to learn how to render using those objects.
+Implementing these methods should give you all the information you need to render your scene. You will have the required render target and projection/view matrices from the @ref bs::Camera "Camera", mesh/material/world transform from @ref bs::Renderable "Renderable" objects, and lighting information from @ref bs::Light "Light". Use the information provided in the [render API](@ref renderAPI) manual to learn how to render using those objects.
 
-Aside from rendering scene objects, the renderer should also take care of rendering everything else, like GUI, debug information and similar. This is handled in a general manner via callbacks. Every external system (like GUI) can register itself with the renderer by calling @ref BansheeEngine::CoreRenderer::registerRenderCallback "Renderer::registerRenderCallback". This method accepts a few parameters:
- - Pointer to a @ref BansheeEngine::Camera "Camera" for which the callback is valid. The renderer should call the callback when rendering onto that camera.
+Aside from rendering scene objects, the renderer should also take care of rendering everything else, like GUI, debug information and similar. This is handled in a general manner via callbacks. Every external system (like GUI) can register itself with the renderer by calling @ref bs::CoreRenderer::registerRenderCallback "Renderer::registerRenderCallback". This method accepts a few parameters:
+ - Pointer to a @ref bs::Camera "Camera" for which the callback is valid. The renderer should call the callback when rendering onto that camera.
  - Index that indicated the priority. Callbacks with indices lower than zero should be executed before scene object rendering, and indices equal to or higher than zero should be executed after scene object rendering.
- - Callback to execute. Other systems will usually call @ref BansheeEngine::RenderAPI "RenderAPI" methods in such callback to perform rendering manually.
+ - Callback to execute. Other systems will usually call @ref bs::RenderAPI "RenderAPI" methods in such callback to perform rendering manually.
  - Overlay toggle. Overlay elements are rendered after all other objects (and non-overlay callbacks). They don't require a depth buffer, nor a multi-sampled render target for rendering (e.g. like GUI), which makes them cheaper to render.
 
 Once a callback is registered, the renderer can access it via the `mRenderCallbacks` protected field.
@@ -112,16 +112,16 @@ While this is enough to create a custom renderer, a variety of useful utilities
 These systems aren't critical for renderer creation, but instead provide an easier way to perform commonly required functions.
 
 ### Render queue {#renderer_b_a_a}
-@ref BansheeEngine::RenderQueue "RenderQueue" allows you to sort and group scene objects for rendering. For example transparent objects might need to be sorted back to front based on their distance from the camera. It is also often useful to group objects if they share the same material, to reduce state switching which can improve performance.
+@ref bs::RenderQueue "RenderQueue" allows you to sort and group scene objects for rendering. For example transparent objects might need to be sorted back to front based on their distance from the camera. It is also often useful to group objects if they share the same material, to reduce state switching which can improve performance.
 
-Use @ref BansheeEngine::RenderQueue::add "RenderQueue::add" to add new objects to the queue. It expects a @ref BansheeEngine::RenderableElement "RenderableElement" which you can create from information provided by @ref BansheeEngine::Renderable "Renderable" when @ref BansheeEngine::Renderer::notifyRenderableAdded "Renderer::notifyRenderableAdded" is called. Normally you wish to have a single @ref BansheeEngine::RenderableElement "RenderableElement" for each sub-mesh present in the renderable object's mesh.
+Use @ref bs::RenderQueue::add "RenderQueue::add" to add new objects to the queue. It expects a @ref bs::RenderableElement "RenderableElement" which you can create from information provided by @ref bs::Renderable "Renderable" when @ref bs::Renderer::notifyRenderableAdded "Renderer::notifyRenderableAdded" is called. Normally you wish to have a single @ref bs::RenderableElement "RenderableElement" for each sub-mesh present in the renderable object's mesh.
 
-Once all elements are in the queue, you can call @ref BansheeEngine::RenderQueue::setStateReduction "RenderQueue::setStateReduction" to select how to sort the objects:
- - @ref BansheeEngine::StateReduction::None "StateReduction::None" - There will be no sorting, based either by distance or material.
- - @ref BansheeEngine::StateReduction::Material "StateReduction::Material" - Elements will be sorted by material first, then by distance.
- - @ref BansheeEngine::StateReduction::Distance "StateReduction::Distance" - Elements will be sorted by distance first, then by material.
+Once all elements are in the queue, you can call @ref bs::RenderQueue::setStateReduction "RenderQueue::setStateReduction" to select how to sort the objects:
+ - @ref bs::StateReduction::None "StateReduction::None" - There will be no sorting, based either by distance or material.
+ - @ref bs::StateReduction::Material "StateReduction::Material" - Elements will be sorted by material first, then by distance.
+ - @ref bs::StateReduction::Distance "StateReduction::Distance" - Elements will be sorted by distance first, then by material.
  
-Once the state reduction mode is set call @ref BansheeEngine::RenderQueue::sort "RenderQueue::sort", and then @ref BansheeEngine::RenderQueue::getSortedElements "RenderQueue::getSortedElements" to retrieve a sorted list of render elements. The returned list contains a list of @ref BansheeEngine::RenderQueueElement "RenderQueueElement" which lets you know exactly which render element to render using which pass, and also tells you when a new pass needs to be applied (if multiple elements in a row use the same pass, it doesn't need to be re-applied).
+Once the state reduction mode is set call @ref bs::RenderQueue::sort "RenderQueue::sort", and then @ref bs::RenderQueue::getSortedElements "RenderQueue::getSortedElements" to retrieve a sorted list of render elements. The returned list contains a list of @ref bs::RenderQueueElement "RenderQueueElement" which lets you know exactly which render element to render using which pass, and also tells you when a new pass needs to be applied (if multiple elements in a row use the same pass, it doesn't need to be re-applied).
 
 For example:
 ~~~~~~~~~~~~~{.cpp}
@@ -140,7 +140,7 @@ const Vector<RenderQueueElement>& sortedElements = queue->getSortedElements();
 ~~~~~~~~~~~~~
 
 ### Renderer material {#renderer_b_a_b}
-Often the renderer needs to use special shaders for various effects (e.g. post-processing effects like FXAA). Unlike shaders and materials used by users, these shaders are built-in into the engine. Since we know they'll always be there we can make it easier for the renderer to load and use them by implementing the @ref BansheeEngine::RendererMaterial "RendererMaterial" interface:
+Often the renderer needs to use special shaders for various effects (e.g. post-processing effects like FXAA). Unlike shaders and materials used by users, these shaders are built-in into the engine. Since we know they'll always be there we can make it easier for the renderer to load and use them by implementing the @ref bs::RendererMaterial "RendererMaterial" interface:
 ~~~~~~~~~~~~~{.cpp}
 // Set up a post-processing material
 class DownsampleMat : public RendererMaterial<DownsampleMat>
@@ -184,11 +184,11 @@ void DirectionalLightMat::_initDefines(ShaderDefines& defines)
 
 ~~~~~~~~~~~~~
 
-Renderer material implementation starts by deriving from @ref BansheeEngine::RendererMaterial<T> "RendererMaterial<T>". This is followed by a declaration of the @ref RMAT_DEF macro, which contains a path to the shader file. The shader file should be located in "Data/Raw/Engine/Shaders/" folder.
+Renderer material implementation starts by deriving from @ref bs::RendererMaterial<T> "RendererMaterial<T>". This is followed by a declaration of the @ref RMAT_DEF macro, which contains a path to the shader file. The shader file should be located in "Data/Raw/Engine/Shaders/" folder.
 
-You must also implement `_initDefines` method, which allows you to modify the compilation environment. It can be empty if not required, but it is useful if your shader has different settings in the form of \#ifdef blocks, in which case different renderer materials can reference the same file, but yield different results depending on what is set in this method. Be aware that all built-in shaders are pre-processed by the @ref BansheeEngine::BuiltinResources "BuiltinResources" manager. If you are changing define options you should delete the "Data/Engine/Timestamp.asset" file, which will force the manager to rebuild all shaders (and actually apply the new defines).
+You must also implement `_initDefines` method, which allows you to modify the compilation environment. It can be empty if not required, but it is useful if your shader has different settings in the form of \#ifdef blocks, in which case different renderer materials can reference the same file, but yield different results depending on what is set in this method. Be aware that all built-in shaders are pre-processed by the @ref bs::BuiltinResources "BuiltinResources" manager. If you are changing define options you should delete the "Data/Engine/Timestamp.asset" file, which will force the manager to rebuild all shaders (and actually apply the new defines).
 
-Once these methods/macros are implemented, you can then instantiate your renderer material and access the @ref BansheeEngine::Material "Material" using the `mMaterial` field. Normally your material will have some parameters, which you'll want to retrieve in the constructor, and then set before rendering. 
+Once these methods/macros are implemented, you can then instantiate your renderer material and access the @ref bs::Material "Material" using the `mMaterial` field. Normally your material will have some parameters, which you'll want to retrieve in the constructor, and then set before rendering. 
 
 @see @ref materials to learn how to work with materials in general.
 @see @ref renderTargets to learn how to create and render to a render target.
@@ -233,7 +233,7 @@ BS_PARAM_BLOCK_BEGIN(PerCameraParamBlock)
 BS_PARAM_BLOCK_END
 ~~~~~~~~~~~~~
 
-By using this approach you lose all the error checking normally performed by @ref BansheeEngine::Material "Material". You must make sure that the layout in C++ matches the layout in the GPU program. In case of GLSL you must also specify `layout(std140)` keyword to ensure its layout is compatible with C++ struct layout. You must also make sure that variable names match the names in the GPU program.
+By using this approach you lose all the error checking normally performed by @ref bs::Material "Material". You must make sure that the layout in C++ matches the layout in the GPU program. In case of GLSL you must also specify `layout(std140)` keyword to ensure its layout is compatible with C++ struct layout. You must also make sure that variable names match the names in the GPU program.
 
 Once your parameter block is created, you can instantiate it, assign values to it, and assign the blocks to materials, like so:
 ~~~~~~~~~~~~~{.cpp}
@@ -276,16 +276,16 @@ You can choose to implement semantics in your renderer, but they aren't required
 
 ### RendererUtility {#renderer_b_a_e}
 
-@ref BansheeEngine::RendererUtility "RendererUtility" provides some commonly required functionality for rendering. For the most part these are just wrappers around @ref BansheeEngine::RenderAPI "RenderAPI" methods, so you don't have to set things like vertex/index buffers manually, as described in [render API](@ref renderAPI) manual.
- - @ref BansheeEngine::RendererUtility::setPass "RendererUtility::setPass" - Binds a pass from a specific @ref BansheeEngine::Material "Material" for rendering. Any further draw calls will be rendered using this pass.
- - @ref BansheeEngine::RendererUtility::setPassParams "RendererUtility::setPassParams" - Binds parameters (textures, samplers, etc.) from a @ref BansheeEngine::Material "Material". Any further draw calls will be rendered using these parameters.
- - @ref BansheeEngine::RendererUtility::draw "RendererUtility::draw" - Draws a specific sub-mesh of the provided @ref BansheeEngine::MeshCore "Mesh", using the currently bound pass.
- - @ref BansheeEngine::RendererUtility::blit "RendererUtility::blit" - Copies the contents of the provided texture into the currently bound render target.
- - @ref BansheeEngine::RendererUtility::drawScreenQuad "RendererUtility::drawScreenQuad" - Draws a quad using the currently bound pass.
+@ref bs::RendererUtility "RendererUtility" provides some commonly required functionality for rendering. For the most part these are just wrappers around @ref bs::RenderAPI "RenderAPI" methods, so you don't have to set things like vertex/index buffers manually, as described in [render API](@ref renderAPI) manual.
+ - @ref bs::RendererUtility::setPass "RendererUtility::setPass" - Binds a pass from a specific @ref bs::Material "Material" for rendering. Any further draw calls will be rendered using this pass.
+ - @ref bs::RendererUtility::setPassParams "RendererUtility::setPassParams" - Binds parameters (textures, samplers, etc.) from a @ref bs::Material "Material". Any further draw calls will be rendered using these parameters.
+ - @ref bs::RendererUtility::draw "RendererUtility::draw" - Draws a specific sub-mesh of the provided @ref bs::MeshCore "Mesh", using the currently bound pass.
+ - @ref bs::RendererUtility::blit "RendererUtility::blit" - Copies the contents of the provided texture into the currently bound render target.
+ - @ref bs::RendererUtility::drawScreenQuad "RendererUtility::drawScreenQuad" - Draws a quad using the currently bound pass.
  
-Use @ref BansheeEngine::gRendererUtility "gRendererUtility" to access the @ref BansheeEngine::RendererUtility "RendererUtility" more easily.
+Use @ref bs::gRendererUtility "gRendererUtility" to access the @ref bs::RendererUtility "RendererUtility" more easily.
  
-Binding a material and rendering using @ref BansheeEngine::RendererUtility "RendererUtility":
+Binding a material and rendering using @ref bs::RendererUtility "RendererUtility":
 ~~~~~~~~~~~~~{.cpp}
 SPtr<MaterialCore> material = ...;
 SPtr<MeshCore> mesh = ...;
@@ -297,13 +297,13 @@ gRendererUtility().draw(mesh, mesh->getProperties().getSubMesh(0));
 ~~~~~~~~~~~~~
  
 ### RenderTexturePool {#renderer_b_a_f}
-Although you can create render textures manually as described in the [render target](@ref renderTargets) manual, @ref BansheeEngine::RenderTexturePool "RenderTexturePool" provides a simpler and more efficient way of doing it. It will keep alive any referenced render textures, so that other systems may re-use them if their size/formats match. This can improve performance when using many temporary/intermediary render textures (like in post-processing).
+Although you can create render textures manually as described in the [render target](@ref renderTargets) manual, @ref bs::RenderTexturePool "RenderTexturePool" provides a simpler and more efficient way of doing it. It will keep alive any referenced render textures, so that other systems may re-use them if their size/formats match. This can improve performance when using many temporary/intermediary render textures (like in post-processing).
 
-To request a render texture, first populate the @ref BansheeEngine::POOLED_RENDER_TEXTURE_DESC "POOLED_RENDER_TEXTURE_DESC" descriptor, by calling either @ref BansheeEngine::POOLED_RENDER_TEXTURE_DESC::create2D "POOLED_RENDER_TEXTURE_DESC::create2D", @ref BansheeEngine::POOLED_RENDER_TEXTURE_DESC::create3D "POOLED_RENDER_TEXTURE_DESC::create3D" or @ref BansheeEngine::POOLED_RENDER_TEXTURE_DESC::createCube "POOLED_RENDER_TEXTURE_DESC::createCube".
+To request a render texture, first populate the @ref bs::POOLED_RENDER_TEXTURE_DESC "POOLED_RENDER_TEXTURE_DESC" descriptor, by calling either @ref bs::POOLED_RENDER_TEXTURE_DESC::create2D "POOLED_RENDER_TEXTURE_DESC::create2D", @ref bs::POOLED_RENDER_TEXTURE_DESC::create3D "POOLED_RENDER_TEXTURE_DESC::create3D" or @ref bs::POOLED_RENDER_TEXTURE_DESC::createCube "POOLED_RENDER_TEXTURE_DESC::createCube".
 
-Then call @ref BansheeEngine::RenderTexturePool::get "RenderTexturePool::get" which will either create a new render texture, or return one from the pool. The returned object is @ref BansheeEngine::PooledRenderTexture "PooledRenderTexture" from which you can access the actual render texture.
+Then call @ref bs::RenderTexturePool::get "RenderTexturePool::get" which will either create a new render texture, or return one from the pool. The returned object is @ref bs::PooledRenderTexture "PooledRenderTexture" from which you can access the actual render texture.
 
-Once you are done using the texture, call @ref BansheeEngine::RenderTexturePool::release "RenderTexturePool::release" to return the texture to the pool, and make it available for other systems. If you plan on using this texture again, make sure to keep a reference to the @ref BansheeEngine::PooledRenderTexture "PooledRenderTexture". This will prevent the pool from fully destroying the texture so it may be reused.
+Once you are done using the texture, call @ref bs::RenderTexturePool::release "RenderTexturePool::release" to return the texture to the pool, and make it available for other systems. If you plan on using this texture again, make sure to keep a reference to the @ref bs::PooledRenderTexture "PooledRenderTexture". This will prevent the pool from fully destroying the texture so it may be reused.
 
 For example:
 ~~~~~~~~~~~~~{.cpp}
@@ -317,6 +317,6 @@ RenderTexturePool::instance().release(pooledRT);
 ~~~~~~~~~~~~~
 
 ### Renderer options {#renderer_b_a_g}
-You can customize your rendering at runtime by implementing the @ref BansheeEngine::CoreRendererOptions "RendererOptions" class. Your @ref BansheeEngine::CoreRendererOptions "RendererOptions" implementation can then be assigned to the renderer by calling @ref BansheeEngine::CoreRenderer::setOptions "Renderer::setOptions", and accessed within the renderer via the `mOptions` field. No default options are provided and it's up to your renderer to decide what it requires.
+You can customize your rendering at runtime by implementing the @ref bs::CoreRendererOptions "RendererOptions" class. Your @ref bs::CoreRendererOptions "RendererOptions" implementation can then be assigned to the renderer by calling @ref bs::CoreRenderer::setOptions "Renderer::setOptions", and accessed within the renderer via the `mOptions` field. No default options are provided and it's up to your renderer to decide what it requires.
 
 Be aware that options are set from the simulation thread, and if you want to use them on the core thread to either properly synchronize the access, or send a copy of the options to the core thread.

Documentation/Manuals/Native/resources.md

@@ -2,16 +2,16 @@ Resources						{#resources}
 ===============
 [TOC]
 
-Resources are objects that can be saved and loaded to/from a disk, can be referenced in a unique manner, and have their lifetime managed by the resources manager. Objects like @ref BansheeEngine::Texture "Texture", @ref BansheeEngine::Mesh "Mesh" or @ref BansheeEngine::Shader "Shader" are all resources.
+Resources are objects that can be saved and loaded to/from a disk, can be referenced in a unique manner, and have their lifetime managed by the resources manager. Objects like @ref bs::Texture "Texture", @ref bs::Mesh "Mesh" or @ref bs::Shader "Shader" are all resources.
 
-A resource in Banshee is represented by the @ref BansheeEngine::Resource "Resource" class. A @ref BansheeEngine::Resource "Resource" is a @ref BansheeEngine::CoreObject "CoreObject" and if you're not familiar with core objects you should read the [core object](@ref coreThread) manual.
+A resource in Banshee is represented by the @ref bs::Resource "Resource" class. A @ref bs::Resource "Resource" is a @ref bs::CoreObject "CoreObject" and if you're not familiar with core objects you should read the [core object](@ref coreThread) manual.
 
-All resources in Banshee are managed by the @ref BansheeEngine::Resources "Resources" manager. Use @ref BansheeEngine::gResources "gResources()" to access its instance easily.
+All resources in Banshee are managed by the @ref bs::Resources "Resources" manager. Use @ref bs::gResources "gResources()" to access its instance easily.
 
 # Loading {#resources_a}
-To load a resource call @ref BansheeEngine::Resources::load "Resource::load" with a file path to the resource. If the path is valid a handle to the resource will be returned.
+To load a resource call @ref bs::Resources::load "Resource::load" with a file path to the resource. If the path is valid a handle to the resource will be returned.
 
-You can also call @ref BansheeEngine::Resources::loadAsync "Resource::loadAsync". Unlike the previous method this method will not block the current thread and will instead proceed with loading the resource on a separate thread. You will receive an uninitialized resource handle. You must use @ref BansheeEngine::ResourceHandleBase::isLoaded "HResource::isLoaded" to check if the handle is loaded before using it, or @ref BansheeEngine::ResourceHandleBase::blockUntilLoaded "HResource::blockUntilLoaded" to force the current thread to wait until it is loaded.
+You can also call @ref bs::Resources::loadAsync "Resource::loadAsync". Unlike the previous method this method will not block the current thread and will instead proceed with loading the resource on a separate thread. You will receive an uninitialized resource handle. You must use @ref bs::ResourceHandleBase::isLoaded "HResource::isLoaded" to check if the handle is loaded before using it, or @ref bs::ResourceHandleBase::blockUntilLoaded "HResource::blockUntilLoaded" to force the current thread to wait until it is loaded.
 
 An example of both synchronous and asynchronous loads:
 ~~~~~~~~~~~~~{.cpp}
@@ -30,9 +30,9 @@ while(!textureB.isLoaded())
 The system internally keeps track of all resources, so calling load multiple times in a row will return a previously loaded resource if one exists.
 
 ## Resource handles {#resources_a_a}
-As we saw in the previous example resources are referenced by @ref BansheeEngine::ResourceHandleBase "resource handles". Different handles exist for each resource type, and they always being with a prefix "H" followed by the resource name, e.g. @ref BansheeEngine::ResourceHandleBase "HTexture".
+As we saw in the previous example resources are referenced by @ref bs::ResourceHandleBase "resource handles". Different handles exist for each resource type, and they always being with a prefix "H" followed by the resource name, e.g. @ref bs::ResourceHandleBase "HTexture".
 
-Handles act like pointers, and you can access the resource within the handle by using the pointer member "->" operator. Using this operator is only valid if the handle points to a loaded resource (@ref BansheeEngine::ResourceHandleBase::isLoaded "HResource::isLoaded" returns true). Using the normal member access "." operator works on the handle data directly and is always safe.
+Handles act like pointers, and you can access the resource within the handle by using the pointer member "->" operator. Using this operator is only valid if the handle points to a loaded resource (@ref bs::ResourceHandleBase::isLoaded "HResource::isLoaded" returns true). Using the normal member access "." operator works on the handle data directly and is always safe.
 
 Handles are used instead of pointers because:
  - Lifetime of the resource can be automatically managed
@@ -41,28 +41,28 @@ Handles are used instead of pointers because:
  
 A little more elaboration for the last point. If you have read the [RTTI](@ref rtti) manual you know that objects can reference different field types. And resource handles can be referenced by "Reflectable" field types, allowing you to easily save/load references to resources within your objects with no additional code.
 
-Each handle internally stores an UUID that uniquely identifies the resource. You can access it by calling @ref BansheeEngine::ResourceHandleBase::getUUID() "HResource::getUUID".
+Each handle internally stores an UUID that uniquely identifies the resource. You can access it by calling @ref bs::ResourceHandleBase::getUUID() "HResource::getUUID".
 
 ## Resource dependencies {#resource_a_b}
-We mentioned in the last section that objects (including resources) can reference resources. For example a @ref BansheeEngine::Font "Font" resource will reference @ref BansheeEngine::Texture "Texture" resources which store its pre-rendered font glyphs.
+We mentioned in the last section that objects (including resources) can reference resources. For example a @ref bs::Font "Font" resource will reference @ref bs::Texture "Texture" resources which store its pre-rendered font glyphs.
 
-When loading a resource you have a choice to load only that exact resource, or if you wish to load all of its dependencies as well. This is handled by the `loadDependencies` parameter of both @ref BansheeEngine::Resources::load "Resource::load" and @ref BansheeEngine::Resources::loadAsync "Resource::loadAsync". If you load a resource without dependencies, and need them later you can just call @ref BansheeEngine::Resources::load "Resource::load" or @ref BansheeEngine::Resources::loadAsync "Resource::loadAsync" on that same resource with `loadDependencies` set to true.
+When loading a resource you have a choice to load only that exact resource, or if you wish to load all of its dependencies as well. This is handled by the `loadDependencies` parameter of both @ref bs::Resources::load "Resource::load" and @ref bs::Resources::loadAsync "Resource::loadAsync". If you load a resource without dependencies, and need them later you can just call @ref bs::Resources::load "Resource::load" or @ref bs::Resources::loadAsync "Resource::loadAsync" on that same resource with `loadDependencies` set to true.
 
 ## Resource lifetime {#resource_a_c}
 Once a resource is loaded it will stay loaded until all references (handles) to it go out of scope. Once the last handle goes out of scope the system will unload the resource.
 
-If you wish to keep a handle to a resource that doesn't keep it loaded, you can use @ref BansheeEngine::TResourceHandle<T, true> "WeakResourceHandle<T>". You retrieve such a handle by calling @ref BansheeEngine::TResourceHandle<T, WeakHandle>::getWeak "HResource::getWeak" method on a normal handle. You can convert a weak handle into a normal handle by calling @ref BansheeEngine::TResourceHandle<T, WeakHandle>::lock "HResource::lock". Before doing so you should verify that the resource is still loaded.
+If you wish to keep a handle to a resource that doesn't keep it loaded, you can use @ref bs::TResourceHandle<T, true> "WeakResourceHandle<T>". You retrieve such a handle by calling @ref bs::TResourceHandle<T, WeakHandle>::getWeak "HResource::getWeak" method on a normal handle. You can convert a weak handle into a normal handle by calling @ref bs::TResourceHandle<T, WeakHandle>::lock "HResource::lock". Before doing so you should verify that the resource is still loaded.
 
-Weak handles can also be used for referencing resources for serialization/deserialization, same as normal handles can. However a weak handle will never force the referenced resource to load, even if `loadDependencies` parameter is set to true when loading. You must call @ref BansheeEngine::Resources::load(const WeakResourceHandle<T>&, ResourceLoadFlags) "Resource::load" to manually load such a resource.
+Weak handles can also be used for referencing resources for serialization/deserialization, same as normal handles can. However a weak handle will never force the referenced resource to load, even if `loadDependencies` parameter is set to true when loading. You must call @ref bs::Resources::load(const WeakResourceHandle<T>&, ResourceLoadFlags) "Resource::load" to manually load such a resource.
 
-You can also force a resource to stay loaded, even after all the handles go out of scope. You do it by setting `keepInternalReference` of @ref BansheeEngine::Resources::load "Resource::load" or @ref BansheeEngine::Resources::loadAsync "Resource::loadAsync" to true. In order to free such a resource you should call @ref BansheeEngine::Resources::release "Resources::release". Be aware that each call to @ref BansheeEngine::Resources::load "Resource::load" or @ref BansheeEngine::Resources::loadAsync "Resource::loadAsync" with this parameter enabled will require a separate @ref BansheeEngine::Resources::release "Resources::release" call. @ref BansheeEngine::Resources::release "Resources::release" will not release the resource immediately if there are still active handles to it, it will merely remove the internal reference so the resource can be freed when the handles go out of scope.
+You can also force a resource to stay loaded, even after all the handles go out of scope. You do it by setting `keepInternalReference` of @ref bs::Resources::load "Resource::load" or @ref bs::Resources::loadAsync "Resource::loadAsync" to true. In order to free such a resource you should call @ref bs::Resources::release "Resources::release". Be aware that each call to @ref bs::Resources::load "Resource::load" or @ref bs::Resources::loadAsync "Resource::loadAsync" with this parameter enabled will require a separate @ref bs::Resources::release "Resources::release" call. @ref bs::Resources::release "Resources::release" will not release the resource immediately if there are still active handles to it, it will merely remove the internal reference so the resource can be freed when the handles go out of scope.
 
-You can also use @ref BansheeEngine::Resources::unloadAllUnused "Resources::unloadAllUnused" which will unload any resource that has no handles referencing it.
+You can also use @ref bs::Resources::unloadAllUnused "Resources::unloadAllUnused" which will unload any resource that has no handles referencing it.
 
 # Saving {#resources_b}
-To save a resource to the disk call @ref BansheeEngine::Resources::save(const HResource&, const Path&, bool) "Resources::save". You need to provide a handle to the resource, and a path to save the resource to.
+To save a resource to the disk call @ref bs::Resources::save(const HResource&, const Path&, bool) "Resources::save". You need to provide a handle to the resource, and a path to save the resource to.
 
-If a resource already exists on the disk (i.e. it was created by @ref BansheeEngine::Resources::load "Resource::load" instead of manually), you can instead call @ref BansheeEngine::Resources::save(const HResource&) "Resources::save" to overwrite the existing file.
+If a resource already exists on the disk (i.e. it was created by @ref bs::Resources::load "Resource::load" instead of manually), you can instead call @ref bs::Resources::save(const HResource&) "Resources::save" to overwrite the existing file.
 
 An example:
 ~~~~~~~~~~~~~{.cpp}
@@ -79,67 +79,67 @@ gResources().save(texture, "myTexture.asset");
 ~~~~~~~~~~~~~
 
 # Creating your own resource {#resources_c}
-To create your own resource, derive a class from @ref BansheeEngine::Resource "Resource" and:
- - Implement the @ref BansheeEngine::CoreObject "CoreObject" interface as described in the [core thread](@ref coreThread) manual
+To create your own resource, derive a class from @ref bs::Resource "Resource" and:
+ - Implement the @ref bs::CoreObject "CoreObject" interface as described in the [core thread](@ref coreThread) manual
  - Implement a RTTI object as described in the [RTTI](@ref rtti) manual
  
-Every resource is also a @ref BansheeEngine::CoreObject "CoreObject", but not every resource actually needs a core thread representation (for example a @ref BansheeEngine::Font "Font" is not relevant on the core thread). In such a case you can provide false to the `requiresGpuInitialization` parameter of the @ref BansheeEngine::CoreObject "CoreObject" constructor. This also means you can ignore implementing most of the @ref BansheeEngine::CoreObject "CoreObject" interface.
+Every resource is also a @ref bs::CoreObject "CoreObject", but not every resource actually needs a core thread representation (for example a @ref bs::Font "Font" is not relevant on the core thread). In such a case you can provide false to the `requiresGpuInitialization` parameter of the @ref bs::CoreObject "CoreObject" constructor. This also means you can ignore implementing most of the @ref bs::CoreObject "CoreObject" interface.
 
-When creating resources, aside from the normal @ref BansheeEngine::CoreObject "CoreObject" creation requirements, you must also call @ref BansheeEngine::Resources::_createResourceHandle "Resources::_createResourceHandle". This method accepts a resource pointer and returns a resource handle. Similar to @ref BansheeEngine::CoreObject "CoreObject" initialization, this should probably be wrapped as a part of a static `create` method and hidden from the user.
+When creating resources, aside from the normal @ref bs::CoreObject "CoreObject" creation requirements, you must also call @ref bs::Resources::_createResourceHandle "Resources::_createResourceHandle". This method accepts a resource pointer and returns a resource handle. Similar to @ref bs::CoreObject "CoreObject" initialization, this should probably be wrapped as a part of a static `create` method and hidden from the user.
 
-See @ref BansheeEngine::Font "Font" implementation in `BsFont.cpp` for an example of a simple resource implementation.
+See @ref bs::Font "Font" implementation in `BsFont.cpp` for an example of a simple resource implementation.
 
 ## Exposing resources to scripting {#resources_c_a}
 Once you have a custom resource you might want to expose it to the scripting API. Take a look at the [scripting interop guide](@ref scripting) to learn how to create scripting API objects. 
 
-Every resource scripting interop object must implement @ref BansheeEngine::TScriptResource "TScriptResource", but other than that creating GUI interop objects is the same as the general case described in the guide above. See @ref BansheeEngine::ScriptFont "ScriptFont" in `BsScriptFont.cpp` for an example.
+Every resource scripting interop object must implement @ref bs::TScriptResource "TScriptResource", but other than that creating GUI interop objects is the same as the general case described in the guide above. See @ref bs::ScriptFont "ScriptFont" in `BsScriptFont.cpp` for an example.
 
 Creating managed GUI objects is again the same as the general case. Take a look at the managed `Font` implementation in `Font.cs` for an example.
 
 Resources are unlike most other scripting objects because they can be created in the native code and then used in the managed code, or vice versa. Resources are also serialized by reference, which requires some specialized code for managed serialization to properly recognize the resource. 
 
 ### Native <-> managed resource conversion {#resources_c_a_a}
-When a resource is created in native code, but needs to be passed to scripting code, the system creates a script interop object and a managed object, which wrap the native resource. The system also needs to be aware if such managed representation of an object already exists, and return an existing one if so. This is the job of the @ref BansheeEngine::ScriptResourceManager "ScriptResourceManager".
+When a resource is created in native code, but needs to be passed to scripting code, the system creates a script interop object and a managed object, which wrap the native resource. The system also needs to be aware if such managed representation of an object already exists, and return an existing one if so. This is the job of the @ref bs::ScriptResourceManager "ScriptResourceManager".
 
 You will need to update this manager with your custom resource type. Relevant methods are:
- - @ref BansheeEngine::ScriptResourceManager::createScriptResource "ScriptResourceManager::createScriptResource" - Creates a new managed object instance from a native resource (only valid if one doesn't already exist). This method has two overloads, and is specialized for specific resource types. Make sure to add a specialization for both overloads, with your custom resource type. And also update the specialization that accepts a generic @ref BansheeEngine::ResourceHandleBase "HResource" with an entry of your own resource. You can use existing resources as an example of how it should be done, only the type names need changing.
- - @ref BansheeEngine::ScriptResourceManager::getScriptResource<RetType, InType> "ScriptResourceManager::getScriptResource" - Retrieves an existing managed object instance from a native resource handle. Optionally creates the managed object if one doesn't already exist. Add a specialization for your own resource type similar to methods above.
+ - @ref bs::ScriptResourceManager::createScriptResource "ScriptResourceManager::createScriptResource" - Creates a new managed object instance from a native resource (only valid if one doesn't already exist). This method has two overloads, and is specialized for specific resource types. Make sure to add a specialization for both overloads, with your custom resource type. And also update the specialization that accepts a generic @ref bs::ResourceHandleBase "HResource" with an entry of your own resource. You can use existing resources as an example of how it should be done, only the type names need changing.
+ - @ref bs::ScriptResourceManager::getScriptResource<RetType, InType> "ScriptResourceManager::getScriptResource" - Retrieves an existing managed object instance from a native resource handle. Optionally creates the managed object if one doesn't already exist. Add a specialization for your own resource type similar to methods above.
 
 ### Managed resource serialization {#resources_c_a_b}
 In order for your new resource type to be properly referenced by serialized managed objects you need to make a few more additions:
- - First of append a new resource type to the @ref BansheeEngine::ScriptReferenceType "ScriptReferenceType" enum.
- - Append a new entry to @ref BansheeEngine::ManagedSerializableTypeInfoRef::getMonoClass "ManagedSerializableTypeInfoRef::getMonoClass" which maps the enum entry above to your resource script interop object type
- - Append a new entry to @ref BansheeEngine::ManagedSerializableTypeInfoRef::isTypeLoaded "ManagedSerializableTypeInfoRef::isTypeLoaded" so it always returns true if your resource is encountered (since it's built-in, it's always loaded)
- - Append a new entry in the @ref BansheeEngine::ScriptAssemblyManager::getTypeInfo "ScriptAssemblyManager::getTypeInfo" which maps the managed resource object type to the enum above
+ - First of append a new resource type to the @ref bs::ScriptReferenceType "ScriptReferenceType" enum.
+ - Append a new entry to @ref bs::ManagedSerializableTypeInfoRef::getMonoClass "ManagedSerializableTypeInfoRef::getMonoClass" which maps the enum entry above to your resource script interop object type
+ - Append a new entry to @ref bs::ManagedSerializableTypeInfoRef::isTypeLoaded "ManagedSerializableTypeInfoRef::isTypeLoaded" so it always returns true if your resource is encountered (since it's built-in, it's always loaded)
+ - Append a new entry in the @ref bs::ScriptAssemblyManager::getTypeInfo "ScriptAssemblyManager::getTypeInfo" which maps the managed resource object type to the enum above
  - Append a new entry to the `getResourceFieldLookup` method in `BsManagedSerializableField.cpp` which uses the native <-> managed conversion methods to map between a native and a managed instance of a resource during serialization/deserialization
  
 For all of these you can use examples of existing resources which already exist within the mentioned methods, it is just a matter of changing the type/enum names for your own resource. 
  
 ### Other {#resources_c_a_c}
-In order for your resources to be properly recognized by GUI drop fields, as well as the project library append new entries to @ref BansheeEngine::ScriptResource::getClassFromTypeId "ScriptResource::getClassFromTypeId" and @ref BansheeEngine::ScriptResource::getTypeFromTypeId "ScriptResource::getTypeFromTypeId" which map between the enum above and the RTTI type ID of the resource.
+In order for your resources to be properly recognized by GUI drop fields, as well as the project library append new entries to @ref bs::ScriptResource::getClassFromTypeId "ScriptResource::getClassFromTypeId" and @ref bs::ScriptResource::getTypeFromTypeId "ScriptResource::getTypeFromTypeId" which map between the enum above and the RTTI type ID of the resource.
 
 # Advanced {#resources_d}
 This section lists some more advanced (and optional) features when dealing with resources.
 
 ## Dependencies {#resources_d_a}
-When creating a custom resource that is dependant on some other resource(s), make sure to implement @ref BansheeEngine::Resource::getResourceDependencies "Resource::getResourceDependencies" which returns a list of all resources it is dependant upon. These resources will be checked when @ref BansheeEngine::ResourceHandleBase::isLoaded "HResource::isLoaded" or @ref BansheeEngine::ResourceHandleBase::blockUntilLoaded "HResource::blockUntilLoaded" is called with `checkDependencies` parameter enabled.
+When creating a custom resource that is dependant on some other resource(s), make sure to implement @ref bs::Resource::getResourceDependencies "Resource::getResourceDependencies" which returns a list of all resources it is dependant upon. These resources will be checked when @ref bs::ResourceHandleBase::isLoaded "HResource::isLoaded" or @ref bs::ResourceHandleBase::blockUntilLoaded "HResource::blockUntilLoaded" is called with `checkDependencies` parameter enabled.
 
-This does not impact the dependencies that are loaded with @ref BansheeEngine::Resources::load "Resources::load". ALL referenced non-weak resource handles will be loaded regardless of @ref BansheeEngine::Resource::getResourceDependencies "Resource::getResourceDependencies" implementation.
+This does not impact the dependencies that are loaded with @ref bs::Resources::load "Resources::load". ALL referenced non-weak resource handles will be loaded regardless of @ref bs::Resource::getResourceDependencies "Resource::getResourceDependencies" implementation.
 
 ## Resource listener {#resources_d_b}
-If an object is interested in learning when a certain resource has been loaded, or updated you can implement the @ref BansheeEngine::IResourceListener "IResourceListener" interface. For example this can be used for refreshing a @ref BansheeEngine::Material "Material" if the @ref BansheeEngine::Shader "Shader" it is dependant upon changes. This also allows you to wait when initializing an object dependant on other resources, in case those resources are being loaded asynchronously.
+If an object is interested in learning when a certain resource has been loaded, or updated you can implement the @ref bs::IResourceListener "IResourceListener" interface. For example this can be used for refreshing a @ref bs::Material "Material" if the @ref bs::Shader "Shader" it is dependant upon changes. This also allows you to wait when initializing an object dependant on other resources, in case those resources are being loaded asynchronously.
 
-To implement it you must return a list of resource handles you are interested in tracking by implementing the @ref BansheeEngine::IResourceListener::getListenerResources "IResourceListener::getListenerResources" method. Whenever the dependant resource list changes you should call @ref BansheeEngine::IResourceListener::markListenerResourcesDirty "IResourceListener::markListenerResourcesDirty".
+To implement it you must return a list of resource handles you are interested in tracking by implementing the @ref bs::IResourceListener::getListenerResources "IResourceListener::getListenerResources" method. Whenever the dependant resource list changes you should call @ref bs::IResourceListener::markListenerResourcesDirty "IResourceListener::markListenerResourcesDirty".
 
-After you have set up the listener resources, whenever such a resource is loaded @ref BansheeEngine::IResourceListener::notifyResourceLoaded "IResourceListener::notifyResourceLoaded" will be called, and when it is updated (via @ref BansheeEngine::Resources::update "Resources::update") @ref BansheeEngine::IResourceListener::notifyResourceChanged "IResourceListener::notifyResourceChanged" will be called.
+After you have set up the listener resources, whenever such a resource is loaded @ref bs::IResourceListener::notifyResourceLoaded "IResourceListener::notifyResourceLoaded" will be called, and when it is updated (via @ref bs::Resources::update "Resources::update") @ref bs::IResourceListener::notifyResourceChanged "IResourceListener::notifyResourceChanged" will be called.
  
-@ref BansheeEngine::Resources "Resources" also provides @ref BansheeEngine::Resources::onResourceLoaded "Resources::onResourceLoaded", @ref BansheeEngine::Resources::onResourceDestroyed "Resources::onResourceDestroyed" and @ref BansheeEngine::Resources::onResourceModified "Resources::onResourceModified" events which may be used for similar purpose, but @ref BansheeEngine::IResourceListener "IResourceListener" is more efficient since it only tracks specific resources.
+@ref bs::Resources "Resources" also provides @ref bs::Resources::onResourceLoaded "Resources::onResourceLoaded", @ref bs::Resources::onResourceDestroyed "Resources::onResourceDestroyed" and @ref bs::Resources::onResourceModified "Resources::onResourceModified" events which may be used for similar purpose, but @ref bs::IResourceListener "IResourceListener" is more efficient since it only tracks specific resources.
 
 ## Resource manifest {#resources_d_c}
-Every time a resource is saved via @ref BansheeEngine::Resources::save "Resources::save", its UUID and file path is stored in a @ref BansheeEngine::ResourceManifest "ResourceManifest". This manifest is used primarily by the deserialization process, so it knows to find resource file paths from the resource handle UUIDs that were serialized.
+Every time a resource is saved via @ref bs::Resources::save "Resources::save", its UUID and file path is stored in a @ref bs::ResourceManifest "ResourceManifest". This manifest is used primarily by the deserialization process, so it knows to find resource file paths from the resource handle UUIDs that were serialized.
 
 Without this manifest every time a user saved an object referencing a resource (like a scene), then restarted the application the system would no longer know where to locate the referenced resources. When using the editor or the scripting API the manifest is managed for you, but if you are building an application on a lower level, you must manage it yourself.
 
-Use @ref BansheeEngine::Resources::getResourceManifest "Resources::getResourceManifest" to retrieve a manifest. By default only one manifest with the name "Default" is registered. You will need to save this manifest before application shut-down and restore it upon application start-up. To restore a manifest call @ref BansheeEngine::Resources::registerResourceManifest "Resources::registerResourceManifest".
+Use @ref bs::Resources::getResourceManifest "Resources::getResourceManifest" to retrieve a manifest. By default only one manifest with the name "Default" is registered. You will need to save this manifest before application shut-down and restore it upon application start-up. To restore a manifest call @ref bs::Resources::registerResourceManifest "Resources::registerResourceManifest".
 
-You can register multiple manifests and the system will scan all of them to find resource paths. If a resource exists in multiple ones, then the latest registered one takes priority. You can unregister a manifest by calling @ref BansheeEngine::Resources::unregisterResourceManifest "Resources::unregisterResourceManifest"
+You can register multiple manifests and the system will scan all of them to find resource paths. If a resource exists in multiple ones, then the latest registered one takes priority. You can unregister a manifest by calling @ref bs::Resources::unregisterResourceManifest "Resources::unregisterResourceManifest"

Documentation/Manuals/Native/rtti.md

@@ -13,8 +13,8 @@ This manual describes how is run-time type information (RTTI) used to provide me
 It is primarily used for saving/loading of objects (e.g. serialization/deserialization of a level), searching for objects (e.g. finding all resources used by a level) and generating "diffs" (Prefabs use diffs to persist/apply instance specific changes when the original changes).
 
 RTTI doesn't automatically work on all classes. You must manually specify the information required by the RTTI system. This involves two things:
- - Making sure your class derives from @ref BansheeEngine::IReflectable "IReflectable" and implements the required methods
- - Implement the @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType> "RTTIType" interface
+ - Making sure your class derives from @ref bs::IReflectable "IReflectable" and implements the required methods
+ - Implement the @ref bs::RTTIType<Type, BaseType, MyRTTIType> "RTTIType" interface
  
 # Adding RTTI to your own objects {#rtti_a}
 Assume you have a simple object you want to serialize:
@@ -25,7 +25,7 @@ class Texture
 };
 ~~~~~~~~~~~~~
 
-First off ensure it implements @ref BansheeEngine::IReflectable "IReflectable" and `getRTTIStatic` and `getRTTI` methods:
+First off ensure it implements @ref bs::IReflectable "IReflectable" and `getRTTIStatic` and `getRTTI` methods:
 ~~~~~~~~~~~~~{.cpp}
 class Texture : public IReflectable
 {
@@ -39,9 +39,9 @@ class Texture : public IReflectable
 };
 ~~~~~~~~~~~~~
 	
-This interface and its methods only serve to return an instance of `TextureRTTI`, which derives from @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType> "RTTIType" and contains all the necessary RTTI information. You will also usually want to make the RTTI type a `friend` of the type so it can easily access its private and protected fields.
+This interface and its methods only serve to return an instance of `TextureRTTI`, which derives from @ref bs::RTTIType<Type, BaseType, MyRTTIType> "RTTIType" and contains all the necessary RTTI information. You will also usually want to make the RTTI type a `friend` of the type so it can easily access its private and protected fields.
 
-A basic implementation of @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType> "RTTIType" must provide information about the type name, unique ID of the type, its base class (@ref BansheeEngine::IReflectable "IReflectable" if it doesn't derive from anything else), a way to create a new instance of the type and a list of fields with their getter/setter methods. A simple one for our example `Texture` class might look like so:
+A basic implementation of @ref bs::RTTIType<Type, BaseType, MyRTTIType> "RTTIType" must provide information about the type name, unique ID of the type, its base class (@ref bs::IReflectable "IReflectable" if it doesn't derive from anything else), a way to create a new instance of the type and a list of fields with their getter/setter methods. A simple one for our example `Texture` class might look like so:
 ~~~~~~~~~~~~~{.cpp}
 class TextureRTTI : public RTTIType<Texture, IReflectable, TextureRTTI> // Specify type the RTTI is for, its base type, and RTTI type itself
 {
@@ -89,10 +89,10 @@ When registering fields with the RTTI type, the systems supports a several sets
 ## Plain fields  {#rtti_b_a}
 In the example above we have shown how to provide getter/setter methods for fields of `int` type. These fields are considered "plain" fields by the engine, and fields for types like `float`, `bool` and any other built-in language type also falls into this category.
 
-You register plain fields by calling @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::addPlainField "RTTIType::addPlainField". The getter/setter methods must return/accept a reference to the value of the field.
+You register plain fields by calling @ref bs::RTTIType<Type, BaseType, MyRTTIType>::addPlainField "RTTIType::addPlainField". The getter/setter methods must return/accept a reference to the value of the field.
 
 ## Reflectable fields  {#rtti_b_b}
-Reflectable fields contain types deriving from @ref BansheeEngine::IReflectable "IReflectable", meaning they're complex objects that contain their own RTTI types. For example if we were to add a `Material` class to our example, it might contain a texture. In such case we would provide getter/setter methods like so:
+Reflectable fields contain types deriving from @ref bs::IReflectable "IReflectable", meaning they're complex objects that contain their own RTTI types. For example if we were to add a `Material` class to our example, it might contain a texture. In such case we would provide getter/setter methods like so:
 ~~~~~~~~~~~~~{.cpp}
 class Material : public IReflectable
 { 
@@ -115,14 +115,14 @@ class MaterialRTTI : public RTTIType<Material, IReflectable, MaterialRTTI>
 };
 ~~~~~~~~~~~~~
 
-As you can see the reflectable field is similar to a plain field, only the @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::addReflectableField "RTTIType::addReflectableField" method is used instead. 
+As you can see the reflectable field is similar to a plain field, only the @ref bs::RTTIType<Type, BaseType, MyRTTIType>::addReflectableField "RTTIType::addReflectableField" method is used instead. 
 
 The problem with this approach is that during serialization whenever a material references a texture, that entire texture will end up being serialized with it. This is something you normally want to avoid since multiple materials will usually be referencing the same texture. For that purpose "Reflectable pointer" fields exist.
 
 ## Reflectable pointer fields  {#rtti_b_c}
-This type of field is similar to the reflectable field, as it also contains types deriving from @ref BansheeEngine::IReflectable "IReflectable". However they only return a pointer to the owned object, instead of copying the object by value. This is relevant for serialization as the system will be smart enough to detect multiple fields pointing to the same instance of an @ref BansheeEngine::IReflectable "IReflectable" object, and only serialize it once (instead of every time it is encountered). When deserializing the system will also properly restore the pointers, so that all fields keep pointing to the same instance.
+This type of field is similar to the reflectable field, as it also contains types deriving from @ref bs::IReflectable "IReflectable". However they only return a pointer to the owned object, instead of copying the object by value. This is relevant for serialization as the system will be smart enough to detect multiple fields pointing to the same instance of an @ref bs::IReflectable "IReflectable" object, and only serialize it once (instead of every time it is encountered). When deserializing the system will also properly restore the pointers, so that all fields keep pointing to the same instance.
 
-Reflectable pointer getter/setter methods must return shared pointers to the instance, and they're registered with @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::addReflectablePtrField "RTTIType::addReflectablePtrField". For example if we modified our `Material` class like so:
+Reflectable pointer getter/setter methods must return shared pointers to the instance, and they're registered with @ref bs::RTTIType<Type, BaseType, MyRTTIType>::addReflectablePtrField "RTTIType::addReflectablePtrField". For example if we modified our `Material` class like so:
 ~~~~~~~~~~~~~{.cpp}
 class Material : public IReflectable
 { 
@@ -174,14 +174,14 @@ class MaterialRTTI : public RTTIType<Material, IReflectable, MaterialRTTI>
 ~~~~~~~~~~~~~
 
 Methods for registering array fields are:
- - @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::addPlainArrayField "RTTIType::addPlainArrayField"
- - @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::addReflectableArrayField "RTTIType::addReflectableArrayField"
- - @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::addReflectablePtrArrayField "RTTIType::addReflectablePtrArrayField"
+ - @ref bs::RTTIType<Type, BaseType, MyRTTIType>::addPlainArrayField "RTTIType::addPlainArrayField"
+ - @ref bs::RTTIType<Type, BaseType, MyRTTIType>::addReflectableArrayField "RTTIType::addReflectableArrayField"
+ - @ref bs::RTTIType<Type, BaseType, MyRTTIType>::addReflectablePtrArrayField "RTTIType::addReflectablePtrArrayField"
 
 They all follow the same syntax as in the example above.
  
 ## Advanced plain fields  {#rtti_b_e}
-Although plain fields are primarily intended for simple built-in types, sometimes they also needs to be used on complex types. For example a `std::string` is often used as a field type, but it is not a simple built-in type, nor can we make it derive from @ref BansheeEngine::IReflectable "IReflectable" so we can't use reflectable fields either. For these purposes you can use @ref BansheeEngine::RTTIPlainType<T> "RTTIPlainType". This is a templated class you can specialize for your specific type. 
+Although plain fields are primarily intended for simple built-in types, sometimes they also needs to be used on complex types. For example a `std::string` is often used as a field type, but it is not a simple built-in type, nor can we make it derive from @ref bs::IReflectable "IReflectable" so we can't use reflectable fields either. For these purposes you can use @ref bs::RTTIPlainType<T> "RTTIPlainType". This is a templated class you can specialize for your specific type. 
 
 It provides methods for serializing/deserializing and retrieving object size. It has no advanced functionality like versioning (so if the structure of the type changes, it will break any previously serialized data), or keeping references to other objects.
 
@@ -223,14 +223,14 @@ template<> struct RTTIPlainType<std::string>
 
 Each specialization must implement all three (`toMemory/fromMemory/getDynamicSize`) methods. It must also provide a flag `hasDynamicSize` which determines whether or not it has dynamic size. Any structure whose size varies with each instance must set this flag to true. You must also set it to true if the size is static but larger than 255 bytes.
 
-After you implement this class you will be able to use the type in getters/setters for plain fields as you would `int` or `float`. You can also use the @ref BS_ALLOW_MEMCPY_SERIALIZATION macro for simple structures. It will create a basic @ref BansheeEngine::RTTIPlainType<T> "RTTIPlainType" specialization which uses `memcpy()`/`sizeof()` to implement the necessary methods.
+After you implement this class you will be able to use the type in getters/setters for plain fields as you would `int` or `float`. You can also use the @ref BS_ALLOW_MEMCPY_SERIALIZATION macro for simple structures. It will create a basic @ref bs::RTTIPlainType<T> "RTTIPlainType" specialization which uses `memcpy()`/`sizeof()` to implement the necessary methods.
 
-If possible you should prefer implementing an @ref BansheeEngine::IReflectable "IReflectable" for complex objects instead of this approach. But it can be useful for types where no other option is available (like third party or standard library types) or types you are sure won't change or require other advanced functionality.
+If possible you should prefer implementing an @ref bs::IReflectable "IReflectable" for complex objects instead of this approach. But it can be useful for types where no other option is available (like third party or standard library types) or types you are sure won't change or require other advanced functionality.
 
-@ref BansheeEngine::RTTIPlainType<T> "RTTIPlainType" specializations can also be used as a more traditional form of serialization in case you find the RTTI system an overkill. For example if you needed to transfer data over a network. The system provides helper methods that allow you to easily work with plain types in such a case:
- - @ref BansheeEngine::rttiReadElem "rttiReadElem" - Deserializes an object from the provided buffer and returns offset into the buffer after the read data
- - @ref BansheeEngine::rttiWriteElem "rttiWriteElem" - Serializes an object into the provided buffer and returns offset into the buffer after the written data
- - @ref BansheeEngine::rttiGetElemSize "rttiGetElemSize" - Returns a size an object
+@ref bs::RTTIPlainType<T> "RTTIPlainType" specializations can also be used as a more traditional form of serialization in case you find the RTTI system an overkill. For example if you needed to transfer data over a network. The system provides helper methods that allow you to easily work with plain types in such a case:
+ - @ref bs::rttiReadElem "rttiReadElem" - Deserializes an object from the provided buffer and returns offset into the buffer after the read data
+ - @ref bs::rttiWriteElem "rttiWriteElem" - Serializes an object into the provided buffer and returns offset into the buffer after the written data
+ - @ref bs::rttiGetElemSize "rttiGetElemSize" - Returns a size an object
 
 ## RTTI field macros  {#rtti_b_f} 
 In order to make definitions for fields in an RTTI type simpler, Banshee provides a set of macros you can use. These macros will automatically create getter/setter methods, and register the field. The macros are:
@@ -244,7 +244,7 @@ In order to make definitions for fields in an RTTI type simpler, Banshee provide
  - BS_RTTI_MEMBER_REFLPTR_NAMED(name, field, id) - Same as BS_RTTI_MEMBER_PLAIN_NAMED but for reflectable pointer fields.
  - BS_RTTI_MEMBER_REFLPTR_ARRAY(name, id) - Same as BS_RTTI_MEMBER_PLAIN_ARRAY but for reflectable pointer fields.
  
-Before you use any of those macros you must first call @ref BS_BEGIN_RTTI_MEMBERS() "BS_BEGIN_RTTI_MEMBERS" macro, and follow it with @ref BS_END_RTTI_MEMBERS() "BS_END_RTTI_MEMBERS" macro. These macros will define a new field `mInitMembers` in the @ref BansheeEngine::RTTITypeBase "RTTIType", which you need to initialize in the constructor with the `this` pointer.
+Before you use any of those macros you must first call @ref BS_BEGIN_RTTI_MEMBERS() "BS_BEGIN_RTTI_MEMBERS" macro, and follow it with @ref BS_END_RTTI_MEMBERS() "BS_END_RTTI_MEMBERS" macro. These macros will define a new field `mInitMembers` in the @ref bs::RTTITypeBase "RTTIType", which you need to initialize in the constructor with the `this` pointer.
 
 If we refactor our `TextureRTTI` example from above to use macros, it would look like so:
 ~~~~~~~~~~~~~{.cpp}
@@ -278,9 +278,9 @@ class TextureRTTI : public RTTIType<Texture, IReflectable, TextureRTTI>
 ~~~~~~~~~~~~~
  
 # Advanced serialization  {#rtti_c}
-Implementations of @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType> "RTTIType" can optionally override @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::onSerializationStarted "RTTIType::onSerializationStarted", @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::onSerializationEnded "RTTIType::onSerializationEnded", @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::onDeserializationStarted "RTTIType::onDeserializationStarted" and @ref BansheeEngine::RTTIType<Type, BaseType, MyRTTIType>::onDeserializationEnded "RTTIType::onDeserializationEnded" methods. As their names imply they will get called during serialization/deserialization and allow you to do any pre- or post-processing of the data. Most other systems (other than serialization) that access field data will also call these functions before reading, and after writing field data.
+Implementations of @ref bs::RTTIType<Type, BaseType, MyRTTIType> "RTTIType" can optionally override @ref bs::RTTIType<Type, BaseType, MyRTTIType>::onSerializationStarted "RTTIType::onSerializationStarted", @ref bs::RTTIType<Type, BaseType, MyRTTIType>::onSerializationEnded "RTTIType::onSerializationEnded", @ref bs::RTTIType<Type, BaseType, MyRTTIType>::onDeserializationStarted "RTTIType::onDeserializationStarted" and @ref bs::RTTIType<Type, BaseType, MyRTTIType>::onDeserializationEnded "RTTIType::onDeserializationEnded" methods. As their names imply they will get called during serialization/deserialization and allow you to do any pre- or post-processing of the data. Most other systems (other than serialization) that access field data will also call these functions before reading, and after writing field data.
 
-Each of those methods accepts an @ref BansheeEngine::IReflectable "IReflectable" pointer to the object currently being processed. Each type that implements @ref BansheeEngine::IReflectable "IReflectable" also comes with a `mRTTIData` field which is of @ref BansheeEngine::Any "Any" type, and can be used for storing temporary data during serialization/deserialization (primarily when using the methods above).
+Each of those methods accepts an @ref bs::IReflectable "IReflectable" pointer to the object currently being processed. Each type that implements @ref bs::IReflectable "IReflectable" also comes with a `mRTTIData` field which is of @ref bs::Any "Any" type, and can be used for storing temporary data during serialization/deserialization (primarily when using the methods above).
 
 # Using RTTI  {#rtti_d}
 Once you have an object with a RTTI type fully implemented you can use it for various purposes.
@@ -315,9 +315,9 @@ rttiField->isArray(); // Does the field contain an array
 ~~~~~~~~~~~~~
 
 ## Serialization  {#rtti_d_b}
-Serialization uses all the features shown in the chapter above in order to serialize an @ref BansheeEngine::IReflectable "IReflectable" object into a stream of bytes, and vice versa. By default binary serialization is used, but user can implement textual serialization (like XML or JSON) using the RTTI system, if needed.
+Serialization uses all the features shown in the chapter above in order to serialize an @ref bs::IReflectable "IReflectable" object into a stream of bytes, and vice versa. By default binary serialization is used, but user can implement textual serialization (like XML or JSON) using the RTTI system, if needed.
 
-Binary serialized data can be output to memory, or to a file using: @ref BansheeEngine::MemorySerializer "MemorySerializer", @ref BansheeEngine::FileEncoder "FileEncoder", @ref BansheeEngine::FileDecoder "FileDecoder". Their usage is simple:
+Binary serialized data can be output to memory, or to a file using: @ref bs::MemorySerializer "MemorySerializer", @ref bs::FileEncoder "FileEncoder", @ref bs::FileDecoder "FileDecoder". Their usage is simple:
 ~~~~~~~~~~~~~{.cpp}
 IReflectable* myObject = ...;
 

Documentation/Manuals/Native/scripting.md

@@ -10,54 +10,54 @@ Before we delve into the specifics of Banshee's scripting you should understand
 
 Because using Mono directly is complex (mostly due to its lack of documentation), Banshee provides a set of easy to use wrappers for almost all of Mono related functionality. 
 
-BansheeMono is a plugin that wraps the functionality of the Mono runtime. The main entry point of the scripting system is the @ref BansheeEngine::MonoManager "MonoManager" class which allows you to start the runtime and load managed (script) assemblies. The most important method here is @ref BansheeEngine::MonoManager::loadAssembly "MonoManager::loadAssembly". It loads all the script code from the managed assembly at the provided path, and provides meta-data for the entire assembly through the returned @ref BansheeEngine::MonoAssembly "MonoAssembly" object. 
+BansheeMono is a plugin that wraps the functionality of the Mono runtime. The main entry point of the scripting system is the @ref bs::MonoManager "MonoManager" class which allows you to start the runtime and load managed (script) assemblies. The most important method here is @ref bs::MonoManager::loadAssembly "MonoManager::loadAssembly". It loads all the script code from the managed assembly at the provided path, and provides meta-data for the entire assembly through the returned @ref bs::MonoAssembly "MonoAssembly" object. 
 
 ## MonoAssembly 	{#scripting_a_a}
-@ref BansheeEngine::MonoAssembly "MonoAssembly" gives you access to all the script classes in an assembly. You can retrieve all clases using @ref BansheeEngine::MonoAssembly::getAllClasses "MonoAssembly::getAllClasses", or retrieve a specific one by calling @ref BansheeEngine::MonoAssembly::getClass(const String&, const String&) const "MonoAssembly::getClass(namespace, typename)". Both of these methods return a @ref BansheeEngine::MonoClass "MonoClass" object.
+@ref bs::MonoAssembly "MonoAssembly" gives you access to all the script classes in an assembly. You can retrieve all clases using @ref bs::MonoAssembly::getAllClasses "MonoAssembly::getAllClasses", or retrieve a specific one by calling @ref bs::MonoAssembly::getClass(const String&, const String&) const "MonoAssembly::getClass(namespace, typename)". Both of these methods return a @ref bs::MonoClass "MonoClass" object.
 
 ## MonoClass 	{#scripting_a_b}
-@ref BansheeEngine::MonoClass "MonoClass" gives you access to all methods, fields, properties and attributes of a specific class. It also allows you to register "internal" methods. These methods allow the managed code to call C++ code, and we'll go into them later.
+@ref bs::MonoClass "MonoClass" gives you access to all methods, fields, properties and attributes of a specific class. It also allows you to register "internal" methods. These methods allow the managed code to call C++ code, and we'll go into them later.
 
-Classes also allow you to create object instances of their type. Use @ref BansheeEngine::MonoClass::createInstance "MonoClass::createInstance" to create a new object instance. All managed objects are referenced using a `MonoObject` type (more on that later), which is returned from the @ref BansheeEngine::MonoClass::createInstance "MonoClass:createInstance" call. When creating an instance you may choose whether to construct it or not, and to provide constructor signature if you need a specific one.
+Classes also allow you to create object instances of their type. Use @ref bs::MonoClass::createInstance "MonoClass::createInstance" to create a new object instance. All managed objects are referenced using a `MonoObject` type (more on that later), which is returned from the @ref bs::MonoClass::createInstance "MonoClass:createInstance" call. When creating an instance you may choose whether to construct it or not, and to provide constructor signature if you need a specific one.
 
-To retrieve a method from a class call @ref BansheeEngine::MonoClass::getMethod() "MonoClass::getMethod()", accepting a name (without parameter types) and a number of parameters. If your method is overloaded you can use @ref BansheeEngine::MonoClass::getMethodExact "MonoClass:getMethodExact()" which accepts a method name, and a comma separated list of parameter types. You may also use @ref BansheeEngine::MonoClass::getAllMethods "MonoClass::getAllMethods" to retrieve all methods in a class.
+To retrieve a method from a class call @ref bs::MonoClass::getMethod() "MonoClass::getMethod()", accepting a name (without parameter types) and a number of parameters. If your method is overloaded you can use @ref bs::MonoClass::getMethodExact "MonoClass:getMethodExact()" which accepts a method name, and a comma separated list of parameter types. You may also use @ref bs::MonoClass::getAllMethods "MonoClass::getAllMethods" to retrieve all methods in a class.
 
-All the above methods return a @ref BansheeEngine::MonoMethod "MonoMethod" object.
+All the above methods return a @ref bs::MonoMethod "MonoMethod" object.
 
 ## MonoMethod {#scripting_a_c}
 This class provides information about about a managed method, as well as giving you multiple ways of invoking it (it allows you to call C# methods from C++).
 
 To invoke a method you may use multiple approaches:
- - @ref BansheeEngine::MonoMethod::invoke "MonoMethod::invoke" - Calls the exact method on a specific managed object, with the provided parameters. We'll see how are managed objects referenced in native code later, as well as how passing data between C++ and managed code works.
- - @ref BansheeEngine::MonoMethod::invokeVirtual "MonoMethod::invokeVirtual" - Calls the method polymorphically. Determines the actual type of the provided managed object instance and calls an overriden method if available.
- - @ref BansheeEngine::MonoMethod::getThunk "MonoMethod::getThunk" - Returns a C++ function pointer accepting a managed object, zero or more parameters and an exception object. You can then call the function pointer like you would a C++ function. This is equivalent to @ref BansheeEngine::MonoMethod::invoke "MonoMethod::invoke" but is significantly faster. A helper method @ref BansheeEngine::MonoUtil::invokeThunk<T, Args> "MonoUtil::invokeThunk" is provided - it is suggested you use it instead of calling thunks manually (it handles exceptions internally).
+ - @ref bs::MonoMethod::invoke "MonoMethod::invoke" - Calls the exact method on a specific managed object, with the provided parameters. We'll see how are managed objects referenced in native code later, as well as how passing data between C++ and managed code works.
+ - @ref bs::MonoMethod::invokeVirtual "MonoMethod::invokeVirtual" - Calls the method polymorphically. Determines the actual type of the provided managed object instance and calls an overriden method if available.
+ - @ref bs::MonoMethod::getThunk "MonoMethod::getThunk" - Returns a C++ function pointer accepting a managed object, zero or more parameters and an exception object. You can then call the function pointer like you would a C++ function. This is equivalent to @ref bs::MonoMethod::invoke "MonoMethod::invoke" but is significantly faster. A helper method @ref bs::MonoUtil::invokeThunk<T, Args> "MonoUtil::invokeThunk" is provided - it is suggested you use it instead of calling thunks manually (it handles exceptions internally).
 
 When calling static methods you should provide a null value for the managed object instance.
 
 ## MonoField {#scripting_a_d}
-Similar to methods, field information can be retrieved from a @ref BansheeEngine::MonoClass "MonoClass" object by calling @ref BansheeEngine::MonoClass::getField "MonoClass::getField" or @ref BansheeEngine::MonoClass::getAllFields "MonoClass::getAllFields". The returned value is a @ref BansheeEngine::MonoField "MonoField" which provides information about the field and allows you to retrieve and set values in the field using @ref BansheeEngine::MonoField::getValue "MonoField::getValue" / @ref BansheeEngine::MonoField::setValue "MonoField::setValue". This works similar to how methods are invoked and is explained in more detail later.
+Similar to methods, field information can be retrieved from a @ref bs::MonoClass "MonoClass" object by calling @ref bs::MonoClass::getField "MonoClass::getField" or @ref bs::MonoClass::getAllFields "MonoClass::getAllFields". The returned value is a @ref bs::MonoField "MonoField" which provides information about the field and allows you to retrieve and set values in the field using @ref bs::MonoField::getValue "MonoField::getValue" / @ref bs::MonoField::setValue "MonoField::setValue". This works similar to how methods are invoked and is explained in more detail later.
 
 ## MonoProperty {#scripting_a_e}
-Properties are very similar to fields, retrieved from a @ref BansheeEngine::MonoClass "MonoClass" object by calling @ref BansheeEngine::MonoClass::getProperty "MonoClass::getProperty". The returned value is a @ref BansheeEngine::MonoProperty "MonoProperty" which provides information about the property and allows you to retrieve and set values on it. The main difference is that properties in C# can be indexed (like arrays) and therefore a two set of set/get methods are provided, one accepting an index and other one not. It's up to the user to know which one to call. The methods are @ref BansheeEngine::MonoProperty::get "MonoProperty::get" / @ref BansheeEngine::MonoProperty::set "MonoProperty::set" and @ref BansheeEngine::MonoProperty::getIndexed "MonoProperty::getIndexed" / @ref BansheeEngine::MonoProperty::setIndexed "MonoProperty::setIndexed".
+Properties are very similar to fields, retrieved from a @ref bs::MonoClass "MonoClass" object by calling @ref bs::MonoClass::getProperty "MonoClass::getProperty". The returned value is a @ref bs::MonoProperty "MonoProperty" which provides information about the property and allows you to retrieve and set values on it. The main difference is that properties in C# can be indexed (like arrays) and therefore a two set of set/get methods are provided, one accepting an index and other one not. It's up to the user to know which one to call. The methods are @ref bs::MonoProperty::get "MonoProperty::get" / @ref bs::MonoProperty::set "MonoProperty::set" and @ref bs::MonoProperty::getIndexed "MonoProperty::getIndexed" / @ref bs::MonoProperty::setIndexed "MonoProperty::setIndexed".
 
 ## Attributes {#scripting_a_f}
 Attributes provide data about a class, method or field provided at runtime, which usually allows such objects to be specialized in some regard. Attributes don't have their own wrapper, because they are esentially normal managed objects and you can work with them as such.
 
-To retrieve a list of attributes from a class use @ref BansheeEngine::MonoClass::getAllAttributes() "MonoClass::getAllAttributes", which returns a list of @ref BansheeEngine::MonoClass "MonoClass" objects that identify the attribute types. To get the actual object instance of the attribute you may call @ref BansheeEngine::MonoClass::getAttribute "MonoClass::getAttribute" with the wanted attribute's @ref BansheeEngine::MonoClass "MonoClass". After that you can call methods, work with field values and other, same as you would with a normal managed object (described below).
+To retrieve a list of attributes from a class use @ref bs::MonoClass::getAllAttributes() "MonoClass::getAllAttributes", which returns a list of @ref bs::MonoClass "MonoClass" objects that identify the attribute types. To get the actual object instance of the attribute you may call @ref bs::MonoClass::getAttribute "MonoClass::getAttribute" with the wanted attribute's @ref bs::MonoClass "MonoClass". After that you can call methods, work with field values and other, same as you would with a normal managed object (described below).
 
-Attributes can also be retrieved from a @ref BansheeEngine::MonoMethod "MonoMethod" using @ref BansheeEngine::MonoMethod::getAttribute "MonoMethod::getAttribute", or from @ref BansheeEngine::MonoField "MonoField" using @ref BansheeEngine::MonoField::getAttribute "MonoField::getAttribute".
+Attributes can also be retrieved from a @ref bs::MonoMethod "MonoMethod" using @ref bs::MonoMethod::getAttribute "MonoMethod::getAttribute", or from @ref bs::MonoField "MonoField" using @ref bs::MonoField::getAttribute "MonoField::getAttribute".
 
 ## Managed objects {#scripting_a_g}
 So far we have talked about invoking methods and retrieving field values, but we haven't yet explained how to access managed object instances in C++ code. All managed objects in Mono are represented by a `MonoObject`.
 
-For example, when calling a non-static method the first parameter provided to @ref BansheeEngine::MonoMethod::invoke "MonoMethod::invoke" is a `MonoObject` pointer. Same goes for retrieving or setting values on fields, properties. Attributes are also a `MonoObject`.
+For example, when calling a non-static method the first parameter provided to @ref bs::MonoMethod::invoke "MonoMethod::invoke" is a `MonoObject` pointer. Same goes for retrieving or setting values on fields, properties. Attributes are also a `MonoObject`.
 
 Mono also provides two more specialized types of managed objects: `MonoArray` for managed arrays, and `MonoString` for managed strings, but they are both still a `MonoObject`.
 
 Be aware that all managed objects are garbage collected. This means you should not keep a reference to them unless you are sure they are alive. Just having a pointer to a `MonoObject` will not keep the object alive and it may go out of scope as soon as the control returns to managed code. A good way to deal with this issue is:
  - Call a native method in the object's finalizer (`~MyObject()`) which will notify you when the object is no longer valid. Be aware that finalizer may be called after the object is unusable.
  - Require the user to manually destroy the object by calling a custom `Destroy` method or similar.
- - Force the garbage collector to keep the object alive by calling @ref BansheeEngine::MonoUtil::newGCHandle "MonoUtil::newGCHandle" which will return a handle to the object. The handle will keep the object alive until you release it by calling @ref BansheeEngine::MonoUtil::freeGCHandle "MonoUtil::freeGCHandle". Be aware if an assembly the object belongs to is unloaded all objects will be destroyed regardless of kept handles.
+ - Force the garbage collector to keep the object alive by calling @ref bs::MonoUtil::newGCHandle "MonoUtil::newGCHandle" which will return a handle to the object. The handle will keep the object alive until you release it by calling @ref bs::MonoUtil::freeGCHandle "MonoUtil::freeGCHandle". Be aware if an assembly the object belongs to is unloaded all objects will be destroyed regardless of kept handles.
  
 ## Marshalling data {#scripting_a_h}
 Mono does not perform automatic marshalling of data when calling managed code from C++ (or vice versa). This is important when calling methods, retrieving/setting field/property values, and responding to calls from managed code, because you need to know in what format to expect the data.
@@ -68,18 +68,18 @@ The rules are:
    - If a reference type parameter in a method in managed code is prefixed with an `out` modifier, then the received parameters are `MonoObject**`, `MonoString**`, `MonoArray**` and your method is expected to populate those values.
  - Structs (non-primitive value types, `struct` in C#) are provided as raw memory. Make sure that all structs in C# that require marshalling have a `[StructLayout(LayoutKind.Sequential)]` attribute, which ensures they have the same memory layout as C++ structs. This way you can just accept the raw C++ structure and read it with no additional conversion.
   - It is suggested you never pass structures by value, it is known to cause problems in Mono. Instead pass all structures by prefixing them with `ref` which will give you a pointer to the structure (e.g. `MyStruct*`). If you need to output a struct use the `out` modifier which you will give you a double pointer (e.g. `MyStruct**`).
-  - In cases where it is not possible to avoid passing structures by value (e.g. when retrieving them from a field, use the @ref BansheeEngine::MonoField::getValueBoxed "MonoField::getValueBoxed" method instead @ref BansheeEngine::MonoField::getValue "MonoField::getValue", which will return a struct in the form of a `MonoObject`. You can then retrieve the raw struct value by calling @ref BansheeEngine::MonoUtil::unbox "MonoUtil::unbox".
-  - Everything above applies only when managed code is calling C++. When calling into managed code from C++, all structs need to be boxed (i.e. converted to `MonoObject`). Use @ref BansheeEngine::MonoUtil::box "MonoUtil::box" to convert a C++ struct into a `MonoObject*`. See @ref BansheeEngine::ScriptVector3 "ScriptVector3" for an example implementation.
+  - In cases where it is not possible to avoid passing structures by value (e.g. when retrieving them from a field, use the @ref bs::MonoField::getValueBoxed "MonoField::getValueBoxed" method instead @ref bs::MonoField::getValue "MonoField::getValue", which will return a struct in the form of a `MonoObject`. You can then retrieve the raw struct value by calling @ref bs::MonoUtil::unbox "MonoUtil::unbox".
+  - Everything above applies only when managed code is calling C++. When calling into managed code from C++, all structs need to be boxed (i.e. converted to `MonoObject`). Use @ref bs::MonoUtil::box "MonoUtil::box" to convert a C++ struct into a `MonoObject*`. See @ref bs::ScriptVector3 "ScriptVector3" for an example implementation.
   
 Banshee provides a helper code to assist with marshalling strings:
- - @ref BansheeEngine::MonoUtil::monoToWString "MonoUtil::monoToWString" / @ref BansheeEngine::MonoUtil::monoToString "MonoUtil::monoToString" - Converts a `MonoString*` to a native string
- - @ref BansheeEngine::MonoUtil::wstringToMono "MonoUtil::wstringToMono" / @ref BansheeEngine::MonoUtil::stringToMono "MonoUtil::stringToMono" - Converts a native string into a `MonoString*`
+ - @ref bs::MonoUtil::monoToWString "MonoUtil::monoToWString" / @ref bs::MonoUtil::monoToString "MonoUtil::monoToString" - Converts a `MonoString*` to a native string
+ - @ref bs::MonoUtil::wstringToMono "MonoUtil::wstringToMono" / @ref bs::MonoUtil::stringToMono "MonoUtil::stringToMono" - Converts a native string into a `MonoString*`
 
-@ref BansheeEngine::ScriptArray "ScriptArray" is a helper class that allows you to construct new arrays and read managed arrays, easily. 
+@ref bs::ScriptArray "ScriptArray" is a helper class that allows you to construct new arrays and read managed arrays, easily. 
 
-To create a new arrays call @ref BansheeEngine::ScriptArray::create "ScriptArray<Type>::create". Type can be a primitive type like `int`, `float`, a native string or a `Script*` object (more about `Script*` objects later). You can then fill the array by calling @ref BansheeEngine::ScriptArray::set "ScriptArray::set" and retrieve the managed `MonoArray*` by calling @ref BansheeEngine::ScriptArray::getInternal "ScriptArray::getInternal".
+To create a new arrays call @ref bs::ScriptArray::create "ScriptArray<Type>::create". Type can be a primitive type like `int`, `float`, a native string or a `Script*` object (more about `Script*` objects later). You can then fill the array by calling @ref bs::ScriptArray::set "ScriptArray::set" and retrieve the managed `MonoArray*` by calling @ref bs::ScriptArray::getInternal "ScriptArray::getInternal".
 
-To more easily read existing arrays create a new @ref BansheeEngine::ScriptArray "ScriptArray" by providing it with a `MonoArray*` in the constructor. Then you can easily retrieve the size of the array using @ref BansheeEngine::ScriptArray::size() "ScriptArray::size()", and the value of its elements by calling @ref BansheeEngine::ScriptArray::get "ScriptArray::get<Type>"". 
+To more easily read existing arrays create a new @ref bs::ScriptArray "ScriptArray" by providing it with a `MonoArray*` in the constructor. Then you can easily retrieve the size of the array using @ref bs::ScriptArray::size() "ScriptArray::size()", and the value of its elements by calling @ref bs::ScriptArray::get "ScriptArray::get<Type>"". 
 
 ## Internal methods {#scripting_a_i}
 So far we have talked about calling managed code, and retrieving information about managed types, but we have yet to show how managed code calls C++ code. This is accomplished using native methods.
@@ -90,14 +90,14 @@ The first step is to define a stub method in managed code, like so:
 private static extern float Internal_GetSomeValue(MyObject obj);
 ~~~~~~~~~~~~~
 	
-You then hook up this method with managed code by calling @ref BansheeEngine::MonoClass::addInternalCall "MonoClass::addInternalCall". In this specific case it would be:
+You then hook up this method with managed code by calling @ref bs::MonoClass::addInternalCall "MonoClass::addInternalCall". In this specific case it would be:
 ~~~~~~~~~~~~~{.cpp}
 myClass->addInternalCall("Internal_GetSomeValue", &myNativeFunction);
 ~~~~~~~~~~~~~
 
-Assuming `myClass` is a @ref BansheeEngine::MonoClass "MonoClass" of the type that contains the stub method. After this call any call to the managed stub method will call the provided native function `myNativeFunction`. You should take care to properly handle parameter passing as described above.
+Assuming `myClass` is a @ref bs::MonoClass "MonoClass" of the type that contains the stub method. After this call any call to the managed stub method will call the provided native function `myNativeFunction`. You should take care to properly handle parameter passing as described above.
 
-Take a look at @ref BansheeEngine::ScriptGUISkin "ScriptGUISkin" implementation for a simple example of how exactly does this work. 
+Take a look at @ref bs::ScriptGUISkin "ScriptGUISkin" implementation for a simple example of how exactly does this work. 
 
 # Script objects {#scripting_b}
 As you can see interaction between the two languages can get a bit cumbersome. For that reason Banshee implements a higher level system built on the functionality shown so far. It provides an universal interface all script objects must implement. It primarily ensures that native and managed code is always linked by keeping a pointer to each other's objects, as well as gracefully handling managed object destruction and handling assembly refresh (due to script hot-swap).
@@ -108,7 +108,7 @@ When exposing a class to the scripting interface you need to add two things:
 
 ## Native interop object ## {#scripting_b_a}
 
-All native interop objects implement the @ref BansheeEngine::ScriptObject "ScriptObject" interface. A basic implementation of such an interface can be:
+All native interop objects implement the @ref bs::ScriptObject "ScriptObject" interface. A basic implementation of such an interface can be:
 ~~~~~~~~~~~~~{.cpp}
 class ScriptMyObject : public ScriptObject <ScriptMyObject>
 {
@@ -123,21 +123,21 @@ private:
 };
 ~~~~~~~~~~~~~	
 	
-All @ref BansheeEngine::ScriptObject "ScriptObjects" must begin with a @ref SCRIPT_OBJ macro. The macro accepts (in order): 
+All @ref bs::ScriptObject "ScriptObjects" must begin with a @ref SCRIPT_OBJ macro. The macro accepts (in order): 
  - the name of the assembly (.dll) the managed script object is in, this is either `ENGINE_ASSEMBLY` or `EDITOR_ASSEMBLY`
  - the namespace the type is in
  - the name of the managed type
 
 @ref SCRIPT_OBJ macro also defines a static `initRuntimeData()` method you need to implement (more on that later).
 
-When constructing a @ref BansheeEngine::ScriptObject "ScriptObject" you must also provide a pointer to the managed object that wraps it (note the constructor). If the @ref BansheeEngine::ScriptObject "ScriptObject" is used for a class that is static then the constructor is of no consequence as the @ref BansheeEngine::ScriptObject "ScriptObject" itself never needs to be instantiated (all of its methods will be static). 
+When constructing a @ref bs::ScriptObject "ScriptObject" you must also provide a pointer to the managed object that wraps it (note the constructor). If the @ref bs::ScriptObject "ScriptObject" is used for a class that is static then the constructor is of no consequence as the @ref bs::ScriptObject "ScriptObject" itself never needs to be instantiated (all of its methods will be static). 
  
 The two last method definitions in the example are called from C# (via an internal call, see the section about internal methods earlier).
 
 ### initRuntimeData ### {#scripting_b_a_a}
-`initRuntimeData` is a static method that every @ref BansheeEngine::ScriptObject "ScriptObject" needs to implement. It takes care of hooking up managed internal methods to C++ functions. It gets called automatically whenever the assembly containing the related managed class is loaded. 
+`initRuntimeData` is a static method that every @ref bs::ScriptObject "ScriptObject" needs to implement. It takes care of hooking up managed internal methods to C++ functions. It gets called automatically whenever the assembly containing the related managed class is loaded. 
 
-Every @ref BansheeEngine::ScriptObject "ScriptObject" provides a static @ref BansheeEngine::ScriptObject<Type, Base>::getMetaData "metaData" structure you can use for retrieving the @ref BansheeEngine::MonoClass "MonoClass" of the related managed class. You can use that @ref BansheeEngine::MonoClass "MonoClass" to register internal methods to it (as described earlier). For example a basic `initRuntimeData()` might look like so:
+Every @ref bs::ScriptObject "ScriptObject" provides a static @ref bs::ScriptObject<Type, Base>::getMetaData "metaData" structure you can use for retrieving the @ref bs::MonoClass "MonoClass" of the related managed class. You can use that @ref bs::MonoClass "MonoClass" to register internal methods to it (as described earlier). For example a basic `initRuntimeData()` might look like so:
 ~~~~~~~~~~~~~{.cpp}
 void ScriptMyObject::initRuntimeData()
 {
@@ -146,10 +146,10 @@ void ScriptMyObject::initRuntimeData()
 }
 ~~~~~~~~~~~~~
 
-`initRuntimeData` is also a good spot to retrieve @ref BansheeEngine::MonoMethod "MonoMethods" (or thunks) for managed methods that needed to be called by the script interop object, if any.
+`initRuntimeData` is also a good spot to retrieve @ref bs::MonoMethod "MonoMethods" (or thunks) for managed methods that needed to be called by the script interop object, if any.
 
 ### Creating script object instances ### {#scripting_b_a_b}	
-If your class is not static you will need to eventually create an instance of the script object. This can be done either from C# or C++, depending on what is needed. For example script interop objects for GUI will be created from managed code because user can add GUI elements himself, but a resource like @ref BansheeEngine::Font "Font" will have its script interop object (and managed instance) created purely from C++ because such an object cannot be created directly in managed code.
+If your class is not static you will need to eventually create an instance of the script object. This can be done either from C# or C++, depending on what is needed. For example script interop objects for GUI will be created from managed code because user can add GUI elements himself, but a resource like @ref bs::Font "Font" will have its script interop object (and managed instance) created purely from C++ because such an object cannot be created directly in managed code.
 
 For the first case you should set up an internal method that accepts the managed object instance, and is called in the managed constructor (`internal_CreateInstance` in the above example). This way the method gets called whenever the managed object gets created and you can create the related script interop object. A simple implementation would look like so:
 ~~~~~~~~~~~~~{.cpp}
@@ -159,7 +159,7 @@ void ScriptMyObject::internal_createInstance(MonoObject* obj)
 }
 ~~~~~~~~~~~~~
 	
-Note that you don't actually need to store the created object anywhere. The @ref BansheeEngine::ScriptObject "ScriptObject" constructor ensures that the pointer to the script interop object is stored in the managed object.
+Note that you don't actually need to store the created object anywhere. The @ref bs::ScriptObject "ScriptObject" constructor ensures that the pointer to the script interop object is stored in the managed object.
 
 For the second case where you want to create the interop object from C++ you can create a static `create()` method like so:
 ~~~~~~~~~~~~~{.cpp}
@@ -174,10 +174,10 @@ MonoObject* ScriptMyObject::create()
 	
 In this case the method calls a parameterless constructor but you may specify parameters as needed.
 
-If you have a `MonoObject*` but need to retrieve its @ref BansheeEngine::ScriptObject "ScriptObject" use @ref BansheeEngine::ScriptObject::toNative(MonoObject*) "toNative(MonoObject*)" static method. Within the interop object instance you can use @ref BansheeEngine::ScriptObjectBase::getManagedInstance() "ScriptObject::getManagedInstance()" to retrieve the managed object.
+If you have a `MonoObject*` but need to retrieve its @ref bs::ScriptObject "ScriptObject" use @ref bs::ScriptObject::toNative(MonoObject*) "toNative(MonoObject*)" static method. Within the interop object instance you can use @ref bs::ScriptObjectBase::getManagedInstance() "ScriptObject::getManagedInstance()" to retrieve the managed object.
 
 ### Destroying script object instances ### {#scripting_b_a_c}
-When the managed object is destroyed (e.g. goes out of scope and gets garbage collected) the system will automatically take care of freeing the related ScriptObject. If you need to add onto or replace that functionality you can override @ref BansheeEngine::ScriptObjectBase::_onManagedInstanceDeleted "ScriptObject::_onManagedInstanceDeleted" method.
+When the managed object is destroyed (e.g. goes out of scope and gets garbage collected) the system will automatically take care of freeing the related ScriptObject. If you need to add onto or replace that functionality you can override @ref bs::ScriptObjectBase::_onManagedInstanceDeleted "ScriptObject::_onManagedInstanceDeleted" method.
 
 ## Managed wrapper object ## {#scripting_b_b}
 Creating the script interop object is one half of the job done. You also need to create the managed counterpart, however that is significantly simpler.
@@ -214,18 +214,18 @@ What has been shown so far is enough to create a class exposed to script, howeve
 
 If you don't care about your object surviving the refresh, you do not need to implement what is described here. For example GUI elements don't persist refresh, because they're just rebuilt from the managed code every time the refresh happens. However objects like resources, scene objects and components are persistent - we don't wish to reload the entire scene and all resources every time assembly refresh happens.
 
-A persistent script object need to inherit a variation of @ref BansheeEngine::ScriptObject "ScriptObject" like so:
+A persistent script object need to inherit a variation of @ref bs::ScriptObject "ScriptObject" like so:
 ~~~~~~~~~~~~~{.cpp}
 class MyScriptObject : public ScriptObject<MyScriptObject, PersistentScriptObjectBase>
 ~~~~~~~~~~~~~	
 	
 This ensures that your object is treated properly during assembly refresh. Persistent object then needs to handle four different actions, represented by overrideable methods. These methods are called in order specified, during assembly refresh.
- - @ref BansheeEngine::ScriptObjectBase::beginRefresh() "ScriptObject::beginRefresh()" - Called just before the refresh starts. The object is still alive here and you can perform needed actions (e.g. saving managed object's contents).
- - @ref BansheeEngine::ScriptObjectBase::_onManagedInstanceDeleted "ScriptObject::_onManagedInstanceDeleted()" - Called after assembly unload happened and the managed object was destroyed. You should override this to prevent the @ref BansheeEngine::ScriptObject "ScriptObject" itself from being deleted if the assembly refresh is in progress. If assembly refresh is not in progress this method should delete the @ref BansheeEngine::ScriptObject "ScriptObject" as normal because it likely got called due to standard reasons (managed object went out of scope).
- - @ref BansheeEngine::ScriptObject::_createManagedInstance "ScriptObject::_createManagedInstance()" - Creates the managed instance after new assemblies are loaded. You should override this if your managed class is constructed using a constructor with parameters. By default this will call @ref BansheeEngine::MonoClass::createInstance "MonoClass::createInstance()" using the parameterless constructor.
- - @ref BansheeEngine::ScriptObjectBase::endRefresh() "ScriptObject::endRefresh()" - Called after all assemblies are loaded, and after all script interop objects were either destroyed (non-persistent) or had their managed instances created (persistent). If you stored any data during @ref BansheeEngine::ScriptObjectBase::beginRefresh() "ScriptObject::beginRefresh()", you should restore it here.
+ - @ref bs::ScriptObjectBase::beginRefresh() "ScriptObject::beginRefresh()" - Called just before the refresh starts. The object is still alive here and you can perform needed actions (e.g. saving managed object's contents).
+ - @ref bs::ScriptObjectBase::_onManagedInstanceDeleted "ScriptObject::_onManagedInstanceDeleted()" - Called after assembly unload happened and the managed object was destroyed. You should override this to prevent the @ref bs::ScriptObject "ScriptObject" itself from being deleted if the assembly refresh is in progress. If assembly refresh is not in progress this method should delete the @ref bs::ScriptObject "ScriptObject" as normal because it likely got called due to standard reasons (managed object went out of scope).
+ - @ref bs::ScriptObject::_createManagedInstance "ScriptObject::_createManagedInstance()" - Creates the managed instance after new assemblies are loaded. You should override this if your managed class is constructed using a constructor with parameters. By default this will call @ref bs::MonoClass::createInstance "MonoClass::createInstance()" using the parameterless constructor.
+ - @ref bs::ScriptObjectBase::endRefresh() "ScriptObject::endRefresh()" - Called after all assemblies are loaded, and after all script interop objects were either destroyed (non-persistent) or had their managed instances created (persistent). If you stored any data during @ref bs::ScriptObjectBase::beginRefresh() "ScriptObject::beginRefresh()", you should restore it here.
  
-See @ref BansheeEngine::ScriptSceneObject "ScriptSceneObject" and its base class @ref BansheeEngine::ScriptGameObjectBase "ScriptGameObjectBase" for example implementations of these methods.
+See @ref bs::ScriptSceneObject "ScriptSceneObject" and its base class @ref bs::ScriptGameObjectBase "ScriptGameObjectBase" for example implementations of these methods.
 
 ## Deriving from ScriptObject ##
 Sometimes script objects are polymorphic. For example a `GUIElement` is derived from `ScriptObject` in managed code, and `GUIButton` is derived from `GUIElement`, however they both have script interop objects of their own.
@@ -240,9 +240,9 @@ public:
 }
 ~~~~~~~~~~~~~	
 	
-But what would it be for `GUIButton`? It also needs to implement @ref BansheeEngine::ScriptObject "ScriptObject" with its own @ref SCRIPT_OBJ macro so we cannot just inherit from `ScriptGUIElement` directly as it would clash.
+But what would it be for `GUIButton`? It also needs to implement @ref bs::ScriptObject "ScriptObject" with its own @ref SCRIPT_OBJ macro so we cannot just inherit from `ScriptGUIElement` directly as it would clash.
 
-The solution is to create a third class that will serve as a base for both. This third class will be a base class for @ref BansheeEngine::ScriptObject "ScriptObject" (its second template parameter allows us to override its default `ScriptObjectBase` base class). The third class will need to inherit @ref BansheeEngine::ScriptObjectBase "ScriptObjectBase" and can implement any functionality common to all GUI elements (e.g. it might store a pointer to a native `GUIElement*`).
+The solution is to create a third class that will serve as a base for both. This third class will be a base class for @ref bs::ScriptObject "ScriptObject" (its second template parameter allows us to override its default `ScriptObjectBase` base class). The third class will need to inherit @ref bs::ScriptObjectBase "ScriptObjectBase" and can implement any functionality common to all GUI elements (e.g. it might store a pointer to a native `GUIElement*`).
 
 Then we can define script interop object for GUI element as:
 ~~~~~~~~~~~~~{.cpp}
@@ -256,4 +256,4 @@ class ScriptGUIButton : public ScriptObject<ScriptGUIButton, ScriptGUIElementBas
 	
 This ensures that all GUI elements can now be accessed through the common `ScriptGUIElementBase` interface. Which is important if `GUIElement` provides some internal method calls shared between all GUI element types, otherwise we wouldn't know what to cast the interop object held by its managed object to.
 
-See @ref BansheeEngine::ScriptGUIElement "ScriptGUIElement" and @ref BansheeEngine::ScriptGUIButton "ScriptGUIButton" for an example.
+See @ref bs::ScriptGUIElement "ScriptGUIElement" and @ref bs::ScriptGUIButton "ScriptGUIButton" for an example.

Documentation/Manuals/Native/textures.md

@@ -2,17 +2,17 @@ Textures									{#textures}
 ===============
 [TOC]
 
-Textures in Banshee are represented with the @ref BansheeEngine::Texture "Texture" and @ref BansheeEngine::TextureCore "TextureCore" classes. Both of these provide almost equivalent functionality, but the former is for use on the simulation thread, and the latter is for use on the core thread. If you are confused by the dual nature of the objects, read the [core thread](@ref coreThread) manual. 
+Textures in Banshee are represented with the @ref bs::Texture "Texture" and @ref bs::TextureCore "TextureCore" classes. Both of these provide almost equivalent functionality, but the former is for use on the simulation thread, and the latter is for use on the core thread. If you are confused by the dual nature of the objects, read the [core thread](@ref coreThread) manual. 
 
 We're going to focus on the simulation thread implementation in this manual, and then note the differences in the core thread version at the end.
 
 # Creating a texture {#textures_a}
-To create a texture call @ref BansheeEngine::Texture::create "Texture::create" or one if its overloads. You'll need to populate the @ref BansheeEngine::TEXTURE_DESC "TEXTURE_DESC" structure and pass it as a parameter. At minimum you need to provide a @ref BansheeEngine::TextureType "texture type", dimensions and @ref BansheeEngine::PixelFormat "pixel format". The dimensions range from one to three dimensional depending on the texture type.
+To create a texture call @ref bs::Texture::create "Texture::create" or one if its overloads. You'll need to populate the @ref bs::TEXTURE_DESC "TEXTURE_DESC" structure and pass it as a parameter. At minimum you need to provide a @ref bs::TextureType "texture type", dimensions and @ref bs::PixelFormat "pixel format". The dimensions range from one to three dimensional depending on the texture type.
 
 Optionally you can also provide the number of mipmaps, number of samples, usage flags and a gamma correction flag:
  - A texture with mip-maps will contain a set of scaled down versions of itself that are used by the GPU for special filtering. 
  - A texture with more than one sample can be used only for rendering (see the [render targets](@ref renderTargets) manual), and is useful for antialiasing.
- - @ref BansheeEngine::TextureUsage "Usage flags" specify how is the texture allowed to be used.
+ - @ref bs::TextureUsage "Usage flags" specify how is the texture allowed to be used.
  - Gamma correction flag specifies if the data in the texture has been gamma corrected. If enabled the GPU will transform the texture data back to linear space when it is accessing it. If the texture is already in linear space, or you do not need it to be in linear space you can leave this off.
  
 For example:
@@ -27,48 +27,48 @@ desc.format = PF_R8G8B8A8;
 HTexture texture = Texture::create(desc);
 ~~~~~~~~~~~~~ 
 
-You can also create a non-empty texture by creating it with a populated @ref BansheeEngine::PixelData "PixelData" object. More about @ref BansheeEngine::PixelData "PixelData" later.
+You can also create a non-empty texture by creating it with a populated @ref bs::PixelData "PixelData" object. More about @ref bs::PixelData "PixelData" later.
  
 # Accessing properties {#textures_b} 
-You can access all relevant information about a texture (e.g. width, height) by calling @ref BansheeEngine::Texture::getProperties() "Texture::getProperties()" which will return an instance of @ref BansheeEngine::TextureProperties "TextureProperties". 
+You can access all relevant information about a texture (e.g. width, height) by calling @ref bs::Texture::getProperties() "Texture::getProperties()" which will return an instance of @ref bs::TextureProperties "TextureProperties". 
  
 # Reading/writing {#textures_c}
-To read and write from/to the texture use the @ref BansheeEngine::Texture::readSubresource "Texture::readSubresource" and @ref BansheeEngine::Texture::writeSubresource "Texture::writeSubresource" methods. These expect an index of a sub-resource to read/write to, and a @ref BansheeEngine::PixelData "PixelData" object.
+To read and write from/to the texture use the @ref bs::Texture::readSubresource "Texture::readSubresource" and @ref bs::Texture::writeSubresource "Texture::writeSubresource" methods. These expect an index of a sub-resource to read/write to, and a @ref bs::PixelData "PixelData" object.
 
-The sub-resource index is simply a sequential index of the surface you want to access. If the texture has only one surface this will always be zero. But if the texture has multiple mipmaps or multiple faces (like for cube textures or texture arrays) you can use @ref BansheeEngine::TextureProperties::mapToSubresourceIdx "TextureProperties::mapToSubresourceIdx" to convert mip/face combination into an subresource index, and @ref BansheeEngine::TextureProperties::mapFromSubresourceIdx "TextureProperties::mapFromSubresourceIdx" for the other way around.
+The sub-resource index is simply a sequential index of the surface you want to access. If the texture has only one surface this will always be zero. But if the texture has multiple mipmaps or multiple faces (like for cube textures or texture arrays) you can use @ref bs::TextureProperties::mapToSubresourceIdx "TextureProperties::mapToSubresourceIdx" to convert mip/face combination into an subresource index, and @ref bs::TextureProperties::mapFromSubresourceIdx "TextureProperties::mapFromSubresourceIdx" for the other way around.
 
-@ref BansheeEngine::PixelData "PixelData" object is just a container for a set of pixels. You can create one manually or use @ref BansheeEngine::TextureProperties::allocateSubresourceBuffer "TextureProperties::allocateSubresourceBuffer" to create the object of valid size and format for the specified sub-resource index. When reading from the texture the buffer will be filled with pixels from the texture, and when writing you are expected to populate the object.
+@ref bs::PixelData "PixelData" object is just a container for a set of pixels. You can create one manually or use @ref bs::TextureProperties::allocateSubresourceBuffer "TextureProperties::allocateSubresourceBuffer" to create the object of valid size and format for the specified sub-resource index. When reading from the texture the buffer will be filled with pixels from the texture, and when writing you are expected to populate the object.
 
 ## PixelData {#textures_c_a}
-You can create @ref BansheeEngine::PixelData "PixelData" manually by calling @ref BansheeEngine::PixelData::create "PixelData::create" and providing it with dimensions and pixel format. When working with textures you must ensure that the dimensions and the format matches the texture sub-resource.
+You can create @ref bs::PixelData "PixelData" manually by calling @ref bs::PixelData::create "PixelData::create" and providing it with dimensions and pixel format. When working with textures you must ensure that the dimensions and the format matches the texture sub-resource.
 
-Once created you can use @ref BansheeEngine::PixelData::getColorAt "PixelData::getColorAt", @ref BansheeEngine::PixelData::setColorAt "PixelData::setColorAt", @ref BansheeEngine::PixelData::getColors "PixelData::getColors" and @ref BansheeEngine::PixelData::setColors "PixelData::setColors" to read/write colors from/to its internal buffer.
+Once created you can use @ref bs::PixelData::getColorAt "PixelData::getColorAt", @ref bs::PixelData::setColorAt "PixelData::setColorAt", @ref bs::PixelData::getColors "PixelData::getColors" and @ref bs::PixelData::setColors "PixelData::setColors" to read/write colors from/to its internal buffer.
 
-You can also use @ref BansheeEngine::PixelUtil "PixelUtil" to perform various operations on the pixels. This includes generating mip maps, converting to different pixel formats, compressing, scaling and other.
+You can also use @ref bs::PixelUtil "PixelUtil" to perform various operations on the pixels. This includes generating mip maps, converting to different pixel formats, compressing, scaling and other.
 
 ## Cached CPU data {#textures_c_b}
-When you read from a texture using the @ref BansheeEngine::Texture::readSubresource "Texture::readSubresource" method the read will be performed from the GPU. This is useful if the GPU has in some way modified the texture, but will also incur a potentially large performance penalty because it will introduce a CPU-GPU synchronization point. In a lot of cases you might just want to read pixels from a texture that was imported or created on the CPU in some other way.
+When you read from a texture using the @ref bs::Texture::readSubresource "Texture::readSubresource" method the read will be performed from the GPU. This is useful if the GPU has in some way modified the texture, but will also incur a potentially large performance penalty because it will introduce a CPU-GPU synchronization point. In a lot of cases you might just want to read pixels from a texture that was imported or created on the CPU in some other way.
 
-For this reason @ref BansheeEngine::Texture::readData "Texture::readData" exists. It will read data quickly with little performance impact. However you must create the texture using the @ref BansheeEngine::TU_CPUCACHED "TU_CPUCACHED" usage. This also means that the texture will keep a copy of its pixels in system memory, so use it sparingly. If the texture is modified from the GPU this method will not reflect such changes.
+For this reason @ref bs::Texture::readData "Texture::readData" exists. It will read data quickly with little performance impact. However you must create the texture using the @ref bs::TU_CPUCACHED "TU_CPUCACHED" usage. This also means that the texture will keep a copy of its pixels in system memory, so use it sparingly. If the texture is modified from the GPU this method will not reflect such changes.
 
 # Rendering using the texture {#textures_d}
 To use a texture for rendering you need to either:
- - (High level) Assign it to a @ref BansheeEngine::Material "Material" which will then automatically get used on a @ref BansheeEngine::Renderable "Renderable" which uses the material. Read the [material manual](@ref materials) for more information.
- - (Low level) Bind the texture to a @ref BansheeEngine::GpuParams "GpuParams" object, which can then be assigned to pipeline for rendering. Read the [render API manual](@ref renderAPI) for more information.
+ - (High level) Assign it to a @ref bs::Material "Material" which will then automatically get used on a @ref bs::Renderable "Renderable" which uses the material. Read the [material manual](@ref materials) for more information.
+ - (Low level) Bind the texture to a @ref bs::GpuParams "GpuParams" object, which can then be assigned to pipeline for rendering. Read the [render API manual](@ref renderAPI) for more information.
 
 # Saving/loading {#textures_e}
-A texture is a @ref BansheeEngine::Resource "Resource" and can be saved/loaded like any other. See the [resource](@ref resources) manual.
+A texture is a @ref bs::Resource "Resource" and can be saved/loaded like any other. See the [resource](@ref resources) manual.
 
 # Core thread textures {#textures_f}
-So far we have only talked about the simulation thread @ref BansheeEngine::Texture "Texture" but have ignored the core thread @ref BansheeEngine::TextureCore "TextureCore". The functionality between the two is mostly the same, with the major difference being that the core thread version doesn't require a @ref BansheeEngine::CoreThreadAccessor "CoreAccessor" for access, and you can instead perform operations on it directly.
+So far we have only talked about the simulation thread @ref bs::Texture "Texture" but have ignored the core thread @ref bs::TextureCore "TextureCore". The functionality between the two is mostly the same, with the major difference being that the core thread version doesn't require a @ref bs::CoreThreadAccessor "CoreAccessor" for access, and you can instead perform operations on it directly.
 
-You can also use @ref BansheeEngine::TextureCore::lock "TextureCore::lock" and @ref BansheeEngine::TextureCore::unlock "TextureCore::unlock" to get access to the texture buffer, which allows you to only read/write from/to portions of it, instead of always writing to the entire buffer.
+You can also use @ref bs::TextureCore::lock "TextureCore::lock" and @ref bs::TextureCore::unlock "TextureCore::unlock" to get access to the texture buffer, which allows you to only read/write from/to portions of it, instead of always writing to the entire buffer.
 
-And finally @ref BansheeEngine::TextureCore::copy "TextureCore::copy" method can be used for quickly copying a contents of one texture to another texture. This method will also resolve multi-sampled surface in the case the source is multi-sampled but the destination is not.
+And finally @ref bs::TextureCore::copy "TextureCore::copy" method can be used for quickly copying a contents of one texture to another texture. This method will also resolve multi-sampled surface in the case the source is multi-sampled but the destination is not.
 
 # Load-store textures {#textures_g}
 Load-store textures are a special type of textures that can be written to by the GPU. This is opposed to normal textures which are read only. They are particularily useful for compute operations which cannot use render targets for output, or for GPU operations that which to write to arbitrary locations rather than just to their own pixel location.
 
-To create a load-store texture just provide the @ref BansheeEngine::TU_LOADSTORE "TU_LOADSTORE" usage flag on creation - the rest of the creation procedure is identical. Load-store textures cannot be multisampled and cannot be used as render or depth-stencil targets. They also cannot have mip-maps nor can they be created with compressed texture formats.
+To create a load-store texture just provide the @ref bs::TU_LOADSTORE "TU_LOADSTORE" usage flag on creation - the rest of the creation procedure is identical. Load-store textures cannot be multisampled and cannot be used as render or depth-stencil targets. They also cannot have mip-maps nor can they be created with compressed texture formats.
 
-Rendering using these textures is similar to normal textures, but when binding them to @ref BansheeEngine::Material "Material" or @ref BansheeEngine::GpuParams "GpuParams" they also require a separate @ref BansheeEngine::TextureSurface "TextureSurface" parameter to determine the surface of the texture to bind, in case it has multiple surfaces or mip levels.
+Rendering using these textures is similar to normal textures, but when binding them to @ref bs::Material "Material" or @ref bs::GpuParams "GpuParams" they also require a separate @ref bs::TextureSurface "TextureSurface" parameter to determine the surface of the texture to bind, in case it has multiple surfaces or mip levels.

Documentation/Manuals/Native/utilities.md

@@ -5,7 +5,7 @@ Utilities									{#utilities}
 This manual will quickly go over all the important utility systems commonly used by Banshee. We won't go into major detail about these features, but will rather point you towards the relevant API documentation.
 
 # Module {#utilities_a}
-A @ref BansheeEngine::Module<T> "Module<T>" is a specialized form of singleton used for many of Banshee's systems. Unlike normal singletons it requires manual startup and shutdown, which solves many of the problems associated with traditional singletons.
+A @ref bs::Module<T> "Module<T>" is a specialized form of singleton used for many of Banshee's systems. Unlike normal singletons it requires manual startup and shutdown, which solves many of the problems associated with traditional singletons.
 
 To use it for your own objects, simply inherit from it:
 ~~~~~~~~~~~~~{.cpp}
@@ -13,7 +13,7 @@ class MyModule : public Module<MyModule>
 { };
 ~~~~~~~~~~~~~
 
-Use @ref BansheeEngine::Module<T>::startUp "Module<T>::startUp" to start it up. Once started use @ref BansheeEngine::Module<T>::instance "Module<T>::instance" to access its instance. Once done with it call @ref BansheeEngine::Module<T>::shutDown "Module<T>::shutDown" to release it. For example:
+Use @ref bs::Module<T>::startUp "Module<T>::startUp" to start it up. Once started use @ref bs::Module<T>::instance "Module<T>::instance" to access its instance. Once done with it call @ref bs::Module<T>::shutDown "Module<T>::shutDown" to release it. For example:
 ~~~~~~~~~~~~~{.cpp}
 MyModule::startUp();
 MyModule::instance().doSomething();
@@ -21,12 +21,12 @@ MyModule::shutDown();
 ~~~~~~~~~~~~~
 
 # Path {#utilities_b}
-Use @ref BansheeEngine::Path "Path" to manipulate file/folder paths. Initialize it with a path string and then call various methods to manipulate it. It is recommended to always store paths using @ref BansheeEngine::Path "Path" instead of raw strings.
+Use @ref bs::Path "Path" to manipulate file/folder paths. Initialize it with a path string and then call various methods to manipulate it. It is recommended to always store paths using @ref bs::Path "Path" instead of raw strings.
 
-Some of the things you can do once a @ref BansheeEngine::Path "Path" is constructed:
- - Retrieve the filename using @ref BansheeEngine::Path::getFilename "Path::getFilename"
- - Retrieve the filename extension using @ref BansheeEngine::Path::getExtension "Path::getExtension"
- - Get last element of path, either file or directory using @ref BansheeEngine::Path::getTail "Path::getTail"
+Some of the things you can do once a @ref bs::Path "Path" is constructed:
+ - Retrieve the filename using @ref bs::Path::getFilename "Path::getFilename"
+ - Retrieve the filename extension using @ref bs::Path::getExtension "Path::getExtension"
+ - Get last element of path, either file or directory using @ref bs::Path::getTail "Path::getTail"
  - Iterate over directories, get drive, combine paths, convert relative to absolute paths and vice versa, and more...
  
 For example:
@@ -42,14 +42,14 @@ Path b("File.txt");
 Path combined = a + b; // // Path is now "C:\Path\To\File.txt"
 ~~~~~~~~~~~~~
  
-All @ref BansheeEngine::Path "Path" methods that return strings come in two variants, one that returns a narrow (8-bit) character string like @ref BansheeEngine::Path::getFilename "Path::getFilename", and one that contains wide character string like @ref BansheeEngine::Path::getWFilename "Path::getWFilename".
+All @ref bs::Path "Path" methods that return strings come in two variants, one that returns a narrow (8-bit) character string like @ref bs::Path::getFilename "Path::getFilename", and one that contains wide character string like @ref bs::Path::getWFilename "Path::getWFilename".
 
 When setting paths be careful with setting backslashes or slashes at the end of the path. Path with a no backslash/slash on the end will be interpreted as a file path, and path with a backslash/slash will be interpreted as a folder path. For example:
- - "C:\MyFolder" - "MyFolder" interpreted as a file, @ref BansheeEngine::Path::getFilename "Path::getFilename" returns "MyFolder"
- - "C:\MyFolder\" - "MyFolder" interpreted as a folder, @ref BansheeEngine::Path::getFilename "Path::getFilename" returns an empty string
+ - "C:\MyFolder" - "MyFolder" interpreted as a file, @ref bs::Path::getFilename "Path::getFilename" returns "MyFolder"
+ - "C:\MyFolder\" - "MyFolder" interpreted as a folder, @ref bs::Path::getFilename "Path::getFilename" returns an empty string
  
 # File system {#utilities_c}
-The @ref BansheeEngine::FileSystem "FileSystem" module allows you to open and create files, create folders, move/copy/remove files and folders, iterate all folder/files in a folder, get file size, check if folder/folder exists, get working path and others.
+The @ref bs::FileSystem "FileSystem" module allows you to open and create files, create folders, move/copy/remove files and folders, iterate all folder/files in a folder, get file size, check if folder/folder exists, get working path and others.
 
 An example creating a folder and a file:
 ~~~~~~~~~~~~~{.cpp}
@@ -58,9 +58,9 @@ SPtr<DataStream> fileStream = FileSystem::createAndOpenFile("C:\\Path\\To\\File.
 ... write to data stream...
 ~~~~~~~~~~~~~
 # Data streams {#utilities_d}
-@ref BansheeEngine::DataStream "Data streams" allow you to easily write/read binary/text data from/to disk/memory/etc. The two primary types of streams are @ref BansheeEngine::MemoryDataStream "MemoryDataStream" for reading/writing directly to memory, and @ref BansheeEngine::FileDataStream "FileDataStream" for reading/writing to a file.
+@ref bs::DataStream "Data streams" allow you to easily write/read binary/text data from/to disk/memory/etc. The two primary types of streams are @ref bs::MemoryDataStream "MemoryDataStream" for reading/writing directly to memory, and @ref bs::FileDataStream "FileDataStream" for reading/writing to a file.
 
-You create memory streams by providing them with a pointer and size of a memory buffer, while you create file streams by calling @ref BansheeEngine::FileSystem::openFile "FileSystem::openFile" or @ref BansheeEngine::FileSystem::createAndOpenFile "FileSystem::createAndOpenFile". Once you are done with a stream make sure to close it by calling @ref BansheeEngine::DataStream::close "DataStream::close". Stream will also be automatically closed when it goes out of scope.
+You create memory streams by providing them with a pointer and size of a memory buffer, while you create file streams by calling @ref bs::FileSystem::openFile "FileSystem::openFile" or @ref bs::FileSystem::createAndOpenFile "FileSystem::createAndOpenFile". Once you are done with a stream make sure to close it by calling @ref bs::DataStream::close "DataStream::close". Stream will also be automatically closed when it goes out of scope.
 
 Once you have a stream you can seek to a position within a stream and read/write to it. For example:
 ~~~~~~~~~~~~~{.cpp}
@@ -76,7 +76,7 @@ fileStream.close();
 ~~~~~~~~~~~~~
  
 # Events {#utilities_e}
-@ref BansheeEngine::TEvent<RetType, Args> "Events" allow your objects to expose events that may trigger during execution. External objects interested in those events can then register callbacks with those events and be notified when they happen. They are useful because they allow two objects to communicate without necessarily knowing about each other's types, which can reduce class coupling and improve design.
+@ref bs::TEvent<RetType, Args> "Events" allow your objects to expose events that may trigger during execution. External objects interested in those events can then register callbacks with those events and be notified when they happen. They are useful because they allow two objects to communicate without necessarily knowing about each other's types, which can reduce class coupling and improve design.
 
 When creating an event, all you need to do it specify a format of the callback it sends out, for example:
 ~~~~~~~~~~~~~{.cpp}
@@ -87,7 +87,7 @@ class MySystem
 };
 ~~~~~~~~~~~~~
 
-Then an external object can register itself with an event by calling @ref BansheeEngine::TEvent<RetType, Args> "Event::connect". This method will return an @ref BansheeEngine::HEvent "HEvent" handle. You can use this handle to manually disconnect from the event by calling @ref BansheeEngine::HEvent::disconnect "HEvent::disconnect". For example:
+Then an external object can register itself with an event by calling @ref bs::TEvent<RetType, Args> "Event::connect". This method will return an @ref bs::HEvent "HEvent" handle. You can use this handle to manually disconnect from the event by calling @ref bs::HEvent::disconnect "HEvent::disconnect". For example:
 ~~~~~~~~~~~~~{.cpp}
 // Subscribe to an event we defined previously
 // Simply pass a function pointer matching the callback
@@ -124,7 +124,7 @@ MySystem::myEvent2(5); // Trigger an event with a single argument
 ~~~~~~~~~~~~~
 
 # Any {#utilities_f}
-Use the @ref BansheeEngine::Any "Any" type to easily store any kind of object in it. For example:
+Use the @ref bs::Any "Any" type to easily store any kind of object in it. For example:
 ~~~~~~~~~~~~~{.cpp}
 Any var1 = Vector<String>();
 
@@ -132,13 +132,13 @@ struct MyStruct { int a; };
 Any var2 = MyStruct();
 ~~~~~~~~~~~~~
 
-Use @ref BansheeEngine::any_cast "any_cast" and @ref BansheeEngine::any_cast_ref "any_cast_ref" to retrieve valid types from an @ref BansheeEngine::Any "Any" variable. For example:
+Use @ref bs::any_cast "any_cast" and @ref bs::any_cast_ref "any_cast_ref" to retrieve valid types from an @ref bs::Any "Any" variable. For example:
 ~~~~~~~~~~~~~{.cpp}
 Vector<String> val1 = any_cast<Vector<String>>(var1);
 MyStruct& val2 = any_cast_ref<MyStruct>(var2);
 ~~~~~~~~~~~~~
 # Flags {#utilities_g}
-@ref BansheeEngine::Flags<Enum, Storage> "Flags" provide a wrapper around an `enum` and allow you to easily perform bitwise operations on them without having to cast to integers. For example when using raw C++ you must do something like this:
+@ref bs::Flags<Enum, Storage> "Flags" provide a wrapper around an `enum` and allow you to easily perform bitwise operations on them without having to cast to integers. For example when using raw C++ you must do something like this:
 ~~~~~~~~~~~~~{.cpp}
 enum class MyFlag
 {
@@ -152,7 +152,7 @@ MyFlag combined = (MyFlag)((UINT32)MyFlag::Flag1 | (UINT32)MyFlag::Flag2);
 
 Which is cumbersome. Flags require an additional step to define the enum, but after that allow you to manipulate values much more nicely. 
 
-To create @ref BansheeEngine::Flags<Enum, Storage> "Flags" for an enum simply define a `typedef` with your enum type provided as the template parameter. You must also follow that definition with a @ref BS_FLAGS_OPERATORS macro in order to ensure all operators are properly defined. For example:
+To create @ref bs::Flags<Enum, Storage> "Flags" for an enum simply define a `typedef` with your enum type provided as the template parameter. You must also follow that definition with a @ref BS_FLAGS_OPERATORS macro in order to ensure all operators are properly defined. For example:
 ~~~~~~~~~~~~~{.cpp}
 typedef Flags<MyFlag> MyFlags;
 BS_FLAGS_OPERATORS(MyFlag)
@@ -163,18 +163,18 @@ Now you can do something like this:
 MyFlags combined = MyFlag::Flag1 | MyFlag::Flag2;
 ~~~~~~~~~~~~~
 # String {#utilities_h}
-Banshee uses @ref BansheeEngine::String "String" for narrow character strings (8-bit) and @ref BansheeEngine::WString "WString" for wide character strings. Wide character strings are different size depending on platform.
+Banshee uses @ref bs::String "String" for narrow character strings (8-bit) and @ref bs::WString "WString" for wide character strings. Wide character strings are different size depending on platform.
 
-A variety of string manipulation functionality is provided in @ref BansheeEngine::StringUtil "StringUtil", like matching, replacing, comparing, formating and similar.
+A variety of string manipulation functionality is provided in @ref bs::StringUtil "StringUtil", like matching, replacing, comparing, formating and similar.
 
-Conversion between various types (like int, float, bool, etc.) and string is provided via overloads of @ref BansheeEngine::toString "toString" and @ref BansheeEngine::toWString "toWString". You can also convert strings into different types by calling methods like @ref BansheeEngine::parseINT32 "parseINT32", @ref BansheeEngine::parseBool "parseBool", and similar for other types.
+Conversion between various types (like int, float, bool, etc.) and string is provided via overloads of @ref bs::toString "toString" and @ref bs::toWString "toWString". You can also convert strings into different types by calling methods like @ref bs::parseINT32 "parseINT32", @ref bs::parseBool "parseBool", and similar for other types.
 
 # Threading {#utilities_i}
 ## Primitives {#utilities_i_a}
 This section describes the most basic primitives you can use to manipulate threads. All threading primitives use the standard C++ library constructs, so for more information you should read their documentation.
 
 ### Thread {#utilities_i_a_a}
-To create a new thread use @ref BansheeEngine::Thread "Thread", like so:
+To create a new thread use @ref bs::Thread "Thread", like so:
 ~~~~~~~~~~~~~{.cpp}
 void workerFunc()
 {
@@ -185,7 +185,7 @@ Thread myThread(&workerFunc);
 ~~~~~~~~~~~~~
 
 ### Mutex {#utilities_i_a_b}
-Use @ref BansheeEngine::Mutex "Mutex" and @ref BansheeEngine::Lock "Lock" to synchronize access between multiple threads, like so:
+Use @ref bs::Mutex "Mutex" and @ref bs::Lock "Lock" to synchronize access between multiple threads, like so:
 ~~~~~~~~~~~~~{.cpp}
 Vector<int> output;
 int startIdx = 0;
@@ -204,10 +204,10 @@ Thread threadA(&workerFunc);
 Thread threadB(&workerFunc);
 ~~~~~~~~~~~~~
 
-If a mutex can be locked recursively, use @ref BansheeEngine::RecursiveMutex "RecursiveMutex" and @ref BansheeEngine::RecursiveLock "RecursiveLock" instead.
+If a mutex can be locked recursively, use @ref bs::RecursiveMutex "RecursiveMutex" and @ref bs::RecursiveLock "RecursiveLock" instead.
 
 ### Signal {#utilities_i_a_c}
-Use @ref BansheeEngine::Signal "Signal" to pause thread execution until another thread reaches a certain point. For example:
+Use @ref bs::Signal "Signal" to pause thread execution until another thread reaches a certain point. For example:
 ~~~~~~~~~~~~~{.cpp}
 bool isReady = false;
 int result = 0;
@@ -242,11 +242,11 @@ if(!isReady)
 ### Other {#utilities_i_a_d}
 The previous sections covered all the primitives, but there is some more useful functionality to be aware of:
  - @ref BS_THREAD_HARDWARE_CONCURRENCY - Returns number of logical CPU cores.
- - @ref BS_THREAD_CURRENT_ID - Returns @ref BansheeEngine::ThreadId "ThreadId" of the current thread.
+ - @ref BS_THREAD_CURRENT_ID - Returns @ref bs::ThreadId "ThreadId" of the current thread.
  - @ref BS_THREAD_SLEEP - Pauses the current thread for a set number of milliseconds.
 
 ## Thread pool {#utilities_i_b}
-Instead of using @ref BansheeEngine::Thread "Thread" as described in the previous section, you should instead use @ref BansheeEngine::ThreadPool "ThreadPool" for running threads. @ref BansheeEngine::ThreadPool "ThreadPool" allows you to re-use threads and avoid paying the cost of thread creation and destruction. It keeps any thread that was retired in idle state, and will re-use it when user requests a new thread.
+Instead of using @ref bs::Thread "Thread" as described in the previous section, you should instead use @ref bs::ThreadPool "ThreadPool" for running threads. @ref bs::ThreadPool "ThreadPool" allows you to re-use threads and avoid paying the cost of thread creation and destruction. It keeps any thread that was retired in idle state, and will re-use it when user requests a new thread.
 
 An example:
 ~~~~~~~~~~~~~{.cpp}
@@ -259,9 +259,9 @@ ThreadPool::instance().run("MyThread", &workerFunc);
 ~~~~~~~~~~~~~
 
 ## Task scheduler {#utilities_i_c}
-@ref BansheeEngine::TaskScheduler "TaskScheduler" allows even more fine grained control over threads. It ensures there are only as many threads as the number of logical CPU cores. This ensures good thread distribution accross the cores, so that multiple threads don't fight for resources on the same core.
+@ref bs::TaskScheduler "TaskScheduler" allows even more fine grained control over threads. It ensures there are only as many threads as the number of logical CPU cores. This ensures good thread distribution accross the cores, so that multiple threads don't fight for resources on the same core.
 
-It accomplishes that by storing each worker function as a @ref BansheeEngine::Task "Task". It then dispatches tasks to threads that are free. In case tasks are dependant on one another you may also provide task dependencies, as well as task priorities.
+It accomplishes that by storing each worker function as a @ref bs::Task "Task". It then dispatches tasks to threads that are free. In case tasks are dependant on one another you may also provide task dependencies, as well as task priorities.
 
 An example:
 ~~~~~~~~~~~~~{.cpp}
@@ -276,50 +276,50 @@ TaskScheduler::instance().addTask(task);
 ~~~~~~~~~~~~~
 
 # Math {#utilities_j}
-Majority of the math related functionality is located in the @ref BansheeEngine::Math "Math" class. 
+Majority of the math related functionality is located in the @ref bs::Math "Math" class. 
 
 Some other useful math classes are:
- - @ref BansheeEngine::Vector2 "Vector2"
- - @ref BansheeEngine::Vector3 "Vector3"
- - @ref BansheeEngine::Vector4 "Vector4"
- - @ref BansheeEngine::Matrix3 "Matrix3"
- - @ref BansheeEngine::Matrix4 "Matrix4"
- - @ref BansheeEngine::Quaternion "Quaternion"
- - @ref BansheeEngine::Radian "Radian"
- - @ref BansheeEngine::Degree "Degree"
- - @ref BansheeEngine::Ray "Ray"
- - @ref BansheeEngine::Plane "Plane"
- - @ref BansheeEngine::Rect2 "Rect2"
- - @ref BansheeEngine::Rect2I "Rect2I"
- - @ref BansheeEngine::Vector2I "Vector2I"
+ - @ref bs::Vector2 "Vector2"
+ - @ref bs::Vector3 "Vector3"
+ - @ref bs::Vector4 "Vector4"
+ - @ref bs::Matrix3 "Matrix3"
+ - @ref bs::Matrix4 "Matrix4"
+ - @ref bs::Quaternion "Quaternion"
+ - @ref bs::Radian "Radian"
+ - @ref bs::Degree "Degree"
+ - @ref bs::Ray "Ray"
+ - @ref bs::Plane "Plane"
+ - @ref bs::Rect2 "Rect2"
+ - @ref bs::Rect2I "Rect2I"
+ - @ref bs::Vector2I "Vector2I"
 
 # Time {#utilities_k}
-To access timing information use the @ref BansheeEngine::Time "Time" module, more easily accessible via @ref BansheeEngine::gTime "gTime" method:
- - @ref BansheeEngine::Time::getTime "Time::getTime" - Returns time since start-up in seconds, updated once per frame.
- - @ref BansheeEngine::Time::getFrameDelta "Time::getFrameDelta" - Returns the time between execution of this and last frame.
- - @ref BansheeEngine::Time::getFrameIdx "Time::getFrameIdx" - Returns a sequential index of the current frame.
- - @ref BansheeEngine::Time::getTimePrecise "Time::getTimePrecise" - Returns time suitable for precision measurements. Returns time at the exact time it was called, instead of being updated once per frame.
+To access timing information use the @ref bs::Time "Time" module, more easily accessible via @ref bs::gTime "gTime" method:
+ - @ref bs::Time::getTime "Time::getTime" - Returns time since start-up in seconds, updated once per frame.
+ - @ref bs::Time::getFrameDelta "Time::getFrameDelta" - Returns the time between execution of this and last frame.
+ - @ref bs::Time::getFrameIdx "Time::getFrameIdx" - Returns a sequential index of the current frame.
+ - @ref bs::Time::getTimePrecise "Time::getTimePrecise" - Returns time suitable for precision measurements. Returns time at the exact time it was called, instead of being updated once per frame.
  
 # Logging {#utilities_l}
-To report warnings and errors use the @ref BansheeEngine::Debug "Debug" module. Call @ref BansheeEngine::Debug::logDebug "Debug::logDebug", @ref BansheeEngine::Debug::logWarning "Debug::logWarning" and @ref BansheeEngine::Debug::logError "Debug::logError" to log messages. 
+To report warnings and errors use the @ref bs::Debug "Debug" module. Call @ref bs::Debug::logDebug "Debug::logDebug", @ref bs::Debug::logWarning "Debug::logWarning" and @ref bs::Debug::logError "Debug::logError" to log messages. 
 
-Use @ref BansheeEngine::Debug::saveLog "Debug::saveLog" to save a log to the disk in HTML format. Use use @ref BansheeEngine::Debug::getLog "Debug::getLog" to get a @ref BansheeEngine::Log "Log" object you can manually parse.
+Use @ref bs::Debug::saveLog "Debug::saveLog" to save a log to the disk in HTML format. Use use @ref bs::Debug::getLog "Debug::getLog" to get a @ref bs::Log "Log" object you can manually parse.
 
 Macros for common log operations are also provided: @ref LOGDBG, @ref LOGWRN and @ref LOGERR. They're equivalent to the methods above.
 
 # Crash handling {#utilities_m}
-Use the @ref BansheeEngine::CrashHandler "CrashHandler" to report fatal errors. Call @ref BansheeEngine::CrashHandler::reportCrash "CrashHandler::reportCrash" to manually trigger such an error. An error will be logged, a message box with relevant information displayed and the application terminated.
+Use the @ref bs::CrashHandler "CrashHandler" to report fatal errors. Call @ref bs::CrashHandler::reportCrash "CrashHandler::reportCrash" to manually trigger such an error. An error will be logged, a message box with relevant information displayed and the application terminated.
 
-You can also use @ref BS_EXCEPT macro, which internally calls @ref BansheeEngine::CrashHandler::reportCrash "CrashHandler::reportCrash" but automatically adds file/line information.
+You can also use @ref BS_EXCEPT macro, which internally calls @ref bs::CrashHandler::reportCrash "CrashHandler::reportCrash" but automatically adds file/line information.
 
-@ref BansheeEngine::CrashHandler "CrashHandler" also provides @ref BansheeEngine::CrashHandler::getStackTrace "CrashHandler::getStackTrace" that allows you to retrieve a stack trace to the current method.
+@ref bs::CrashHandler "CrashHandler" also provides @ref bs::CrashHandler::getStackTrace "CrashHandler::getStackTrace" that allows you to retrieve a stack trace to the current method.
 
 # Dynamic libraries {#utilities_n}
-Use @ref BansheeEngine::DynLibManager "DynLibManager" to load dynamic libraries (.dll, .so). It has two main methods:
- - @ref BansheeEngine::DynLibManager::load "DynLibManager::load" - Accepts a file name to the library, and returns the @ref BansheeEngine::DynLib "DynLib" object if the load is successful or null otherwise. 
- - @ref BansheeEngine::DynLibManager::unload "DynLibManager::unload" - Unloads a previously loaded library.
+Use @ref bs::DynLibManager "DynLibManager" to load dynamic libraries (.dll, .so). It has two main methods:
+ - @ref bs::DynLibManager::load "DynLibManager::load" - Accepts a file name to the library, and returns the @ref bs::DynLib "DynLib" object if the load is successful or null otherwise. 
+ - @ref bs::DynLibManager::unload "DynLibManager::unload" - Unloads a previously loaded library.
  
-Once the library is loaded you can use the @ref BansheeEngine::DynLib "DynLib" object, and its @ref BansheeEngine::DynLib::getSymbol "DynLib::getSymbol" method to retrieve a function pointer within the dynamic library, and call into it. For example if we wanted to retrieve a function pointer for the `loadPlugin` method:
+Once the library is loaded you can use the @ref bs::DynLib "DynLib" object, and its @ref bs::DynLib::getSymbol "DynLib::getSymbol" method to retrieve a function pointer within the dynamic library, and call into it. For example if we wanted to retrieve a function pointer for the `loadPlugin` method:
 ~~~~~~~~~~~~~{.cpp}
 // Load library
 DynLib* myLibrary = DynLibManager::instance().load("myPlugin");
@@ -336,7 +336,7 @@ DynLibManager::instance().unload(myLibrary);
 ~~~~~~~~~~~~~
 
 # Testing {#utilities_o}
-Implement @ref BansheeEngine::TestSuite "TestSuite" to set up unit tests for your application. To register new tests call @ref BS_ADD_TEST. Test is assumed to succeed unless either @ref BS_TEST_ASSERT or @ref BS_TEST_ASSERT_MSG are triggered.
+Implement @ref bs::TestSuite "TestSuite" to set up unit tests for your application. To register new tests call @ref BS_ADD_TEST. Test is assumed to succeed unless either @ref BS_TEST_ASSERT or @ref BS_TEST_ASSERT_MSG are triggered.
 
 ~~~~~~~~~~~~~{.cpp}
 class MyTestSuite : TestSuite
@@ -355,20 +355,20 @@ private:
 };
 ~~~~~~~~~~~~~
 
-To run all tests create a instance of the @ref BansheeEngine::TestSuite "TestSuite" and run it, like so:
+To run all tests create a instance of the @ref bs::TestSuite "TestSuite" and run it, like so:
 ~~~~~~~~~~~~~{.cpp}
 SPtr<TestSuite> tests = MyTestSuite::create<MyTestSuite>();
 tests->run(ExceptionTestOutput());
 ~~~~~~~~~~~~~
 
-When running the test we provide @ref BansheeEngine::ExceptionTestOutput "ExceptionTestOutput" which tells the test runner to terminate the application when a test fails. You can implement your own @ref BansheeEngine::TestOutput "TestOutput" to handle test failure more gracefully.
+When running the test we provide @ref bs::ExceptionTestOutput "ExceptionTestOutput" which tells the test runner to terminate the application when a test fails. You can implement your own @ref bs::TestOutput "TestOutput" to handle test failure more gracefully.
 
 # Allocators {#utilities_p}
 Banshee allows you to allocate memory in various ways, so you can have fast memory allocations for many situations.
 ## General {#utilities_p_a}
-The most common memory allocation operations are `new`/`delete` or `malloc`/`free`. Banshee provides its own wrappers for these methods as @ref BansheeEngine::bs_new "bs_new"/@ref BansheeEngine::bs_delete "bs_delete" and @ref BansheeEngine::bs_alloc "bs_alloc"/@ref BansheeEngine::bs_free "bs_free". They provide the same functionality but make it possible for Banshee to track memory allocations which can be useful for profiling and debugging. You should always use them instead of the standard ones.
+The most common memory allocation operations are `new`/`delete` or `malloc`/`free`. Banshee provides its own wrappers for these methods as @ref bs::bs_new "bs_new"/@ref bs::bs_delete "bs_delete" and @ref bs::bs_alloc "bs_alloc"/@ref bs::bs_free "bs_free". They provide the same functionality but make it possible for Banshee to track memory allocations which can be useful for profiling and debugging. You should always use them instead of the standard ones.
 
-Use @ref BansheeEngine::bs_newN "bs_newN"/@ref BansheeEngine::bs_deleteN "bs_deleteN" to create and delete arrays of objects.
+Use @ref bs::bs_newN "bs_newN"/@ref bs::bs_deleteN "bs_deleteN" to create and delete arrays of objects.
 
 ~~~~~~~~~~~~~{.cpp}
 UINT8* buffer = (UINT8*)bs_alloc(1024); // Allocate a raw buffer of 1024 bytes.
@@ -386,7 +386,7 @@ Stack allocator allows you to allocate memory quickly, usually without a call to
 
 However it comes with a downside that it can only deallocate memory in the opposite order it was allocated. This usually only makes it suitable for temporary allocations within a single method, where you can guarantee the proper order.
 
-Use @ref BansheeEngine::bs_stack_alloc "bs_stack_alloc" / @ref BansheeEngine::bs_stack_free "bs_stack_free" and @ref BansheeEngine::bs_stack_new "bs_stack_new" / @ref BansheeEngine::bs_stack_delete "bs_stack_delete" to allocate/free memory using the stack allocator.
+Use @ref bs::bs_stack_alloc "bs_stack_alloc" / @ref bs::bs_stack_free "bs_stack_free" and @ref bs::bs_stack_new "bs_stack_new" / @ref bs::bs_stack_delete "bs_stack_delete" to allocate/free memory using the stack allocator.
 
 For example:
 ~~~~~~~~~~~~~{.cpp}
@@ -405,9 +405,9 @@ Frame allocator segments all allocated memory into "frames". These frames are st
 
 This releases the restriction that memory must be freed in the order it was allocated, which makes the allocator usable in more situations, but it also means that a lot of memory might be wasted as unused memory will be kept until the entire frame is freed.
 
-Use @ref BansheeEngine::bs_frame_alloc "bs_frame_alloc" / @ref BansheeEngine::bs_frame_free "bs_frame_free" or @ref BansheeEngine::bs_frame_new "bs_frame_new" / @ref BansheeEngine::bs_frame_delete "bs_frame_delete" to allocate/free memory using the frame allocator. Calls to @ref BansheeEngine::bs_frame_free "bs_frame_free" / @ref BansheeEngine::bs_frame_delete "bs_frame_delete" are required even through the frame allocator doesn't process individual deallocations, and this is used primarily for debug purposes.
+Use @ref bs::bs_frame_alloc "bs_frame_alloc" / @ref bs::bs_frame_free "bs_frame_free" or @ref bs::bs_frame_new "bs_frame_new" / @ref bs::bs_frame_delete "bs_frame_delete" to allocate/free memory using the frame allocator. Calls to @ref bs::bs_frame_free "bs_frame_free" / @ref bs::bs_frame_delete "bs_frame_delete" are required even through the frame allocator doesn't process individual deallocations, and this is used primarily for debug purposes.
 
-Use @ref BansheeEngine::bs_frame_mark "bs_frame_mark" to start a new frame. All frame allocations should happen after this call. If you don't call @ref BansheeEngine::bs_frame_mark "bs_frame_mark" a global frame will be used. Once done with your calculations use @ref BansheeEngine::bs_frame_clear "bs_frame_clear" to free all memory in the current frame. The frames have to be released in opposite order they were created.
+Use @ref bs::bs_frame_mark "bs_frame_mark" to start a new frame. All frame allocations should happen after this call. If you don't call @ref bs::bs_frame_mark "bs_frame_mark" a global frame will be used. Once done with your calculations use @ref bs::bs_frame_clear "bs_frame_clear" to free all memory in the current frame. The frames have to be released in opposite order they were created.
 
 For example:
 ~~~~~~~~~~~~~{.cpp}
@@ -422,9 +422,9 @@ bs_frame_free(buffer2); // Only does some checks in debug mode, doesn't actually
 bs_frame_clear(); // Frees memory for both buffers
 ~~~~~~~~~~~~~
 
-You can also create your own frame allocators by constructing a @ref BansheeEngine::FrameAlloc "FrameAlloc" and calling memory management methods on it directly. This can allow you to use a frame allocator on a more global scope. For example if you are running some complex algorithm involving multiple classes you might create a frame allocator to be used throughout the algorithm, and then just free all the memory at once when the algorithm finishes.
+You can also create your own frame allocators by constructing a @ref bs::FrameAlloc "FrameAlloc" and calling memory management methods on it directly. This can allow you to use a frame allocator on a more global scope. For example if you are running some complex algorithm involving multiple classes you might create a frame allocator to be used throughout the algorithm, and then just free all the memory at once when the algorithm finishes.
 
-You may also use frame allocator to allocate containers like @ref BansheeEngine::String "String", @ref BansheeEngine::Vector "Vector" or @ref BansheeEngine::Map "Map". Simply mark the frame as in the above example, and then use the following container alternatives: @ref BansheeEngine::String "FrameString", @ref BansheeEngine::FrameVector "FrameVector" or @ref BansheeEngine::FrameMap "FrameMap" (other container types also available). For example:
+You may also use frame allocator to allocate containers like @ref bs::String "String", @ref bs::Vector "Vector" or @ref bs::Map "Map". Simply mark the frame as in the above example, and then use the following container alternatives: @ref bs::String "FrameString", @ref bs::FrameVector "FrameVector" or @ref bs::FrameMap "FrameMap" (other container types also available). For example:
 
 ~~~~~~~~~~~~~{.cpp}
 // Mark a new frame
@@ -437,7 +437,7 @@ bs_frame_clear(); // Frees memory for the vector
 ~~~~~~~~~~~~~
 
 ## Static {#utilities_p_d}
-@ref BansheeEngine::StaticAlloc<BlockSize, MaxDynamicMemory> "Static allocator" is the only specialized type of allocator that is used for permanent allocations. It allows you to pre-allocate a static buffer on the internal stack. It will then use internal stack memory until it runs out, after which it will use normal dynamic allocations. If you can predict a good static buffer size you can guarantee that most of your objects don't allocate any heap memory, while wasting minimum memory on the stack. This kind of allocator is mostly useful when you have many relatively small objects, each of which requires dynamic allocation of a different size.
+@ref bs::StaticAlloc<BlockSize, MaxDynamicMemory> "Static allocator" is the only specialized type of allocator that is used for permanent allocations. It allows you to pre-allocate a static buffer on the internal stack. It will then use internal stack memory until it runs out, after which it will use normal dynamic allocations. If you can predict a good static buffer size you can guarantee that most of your objects don't allocate any heap memory, while wasting minimum memory on the stack. This kind of allocator is mostly useful when you have many relatively small objects, each of which requires dynamic allocation of a different size.
 
 An example:
 ~~~~~~~~~~~~~{.cpp}
@@ -461,7 +461,7 @@ class MyObj
 ~~~~~~~~~~~~~
 
 ## Shared pointers {#utilities_p_e}
-Shared pointers are smart pointers that will automatically free memory when the last reference to the pointed memory goes out of scope. They're implemented as @ref BansheeEngine::SPtr "SPtr", which is just a wrapper for the standard C++ library `std::shared_ptr`. Use @ref BansheeEngine::bs_shared_ptr_new "bs_shared_ptr_new" to create a new shared pointer, or @ref BansheeEngine::bs_shared_ptr "bs_shared_ptr" to create one from an existing instance. The pointer memory is allocated and freed using the general allocator.
+Shared pointers are smart pointers that will automatically free memory when the last reference to the pointed memory goes out of scope. They're implemented as @ref bs::SPtr "SPtr", which is just a wrapper for the standard C++ library `std::shared_ptr`. Use @ref bs::bs_shared_ptr_new "bs_shared_ptr_new" to create a new shared pointer, or @ref bs::bs_shared_ptr "bs_shared_ptr" to create one from an existing instance. The pointer memory is allocated and freed using the general allocator.
 
 For example:
 ~~~~~~~~~~~~~{.cpp}

Source/BansheeCore/CMakeSources.cmake

@@ -334,6 +334,7 @@ set(BS_BANSHEECORE_INC_RTTI
 	"Include/BsCameraRTTI.h"
 	"Include/BsPostProcessSettingsRTTI.h"
 	"Include/BsMorphShapesRTTI.h"
+	"BsAudioClipImportOptionsRTTI.h"
 )
 
 set(BS_BANSHEECORE_SRC_RENDERER

Source/BansheeCore/Include/BsAnimation.h

@@ -11,7 +11,7 @@
 #include "BsVector2.h"
 #include "BsAABox.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Animation-Internal
 	 *  @{

Source/BansheeCore/Include/BsAnimationClip.h

@@ -8,7 +8,7 @@
 #include "BsQuaternion.h"
 #include "BsAnimationCurve.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Animation
 	 *  @{

Source/BansheeCore/Include/BsAnimationClipRTTI.h

@@ -7,7 +7,7 @@
 #include "BsAnimationClip.h"
 #include "BsAnimationCurveRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsAnimationCurve.h

@@ -5,7 +5,7 @@
 #include "BsCorePrerequisites.h"
 #include "BsCurveCache.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Animation-Internal
 	 *  @{

Source/BansheeCore/Include/BsAnimationCurveRTTI.h

@@ -6,7 +6,7 @@
 #include "BsRTTIType.h"
 #include "BsAnimationCurve.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsAnimationManager.h

@@ -8,7 +8,7 @@
 #include "BsConvexVolume.h"
 #include "BsVertexDataDesc.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	struct AnimationProxy;
 

Source/BansheeCore/Include/BsAnimationUtility.h

@@ -5,7 +5,7 @@
 #include "BsCorePrerequisites.h"
 #include "BsAnimationCurve.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Animation
 	 *  @{

Source/BansheeCore/Include/BsAudio.h

@@ -6,7 +6,7 @@
 #include "BsModule.h"
 #include "BsVector3.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Audio
 	 *  @{

Source/BansheeCore/Include/BsAudioClip.h

@@ -5,7 +5,7 @@
 #include "BsCorePrerequisites.h"
 #include "BsResource.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Audio
 	 *  @{

Source/BansheeCore/Include/BsAudioClipImportOptions.h

@@ -6,7 +6,7 @@
 #include "BsImportOptions.h"
 #include "BsAudioClip.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Importer
 	 *  @{

Source/BansheeCore/Include/BsAudioClipImportOptionsRTTI.h

@@ -6,7 +6,7 @@
 #include "BsRTTIType.h"
 #include "BsAudioClipImportOptions.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsAudioClipRTTI.h

@@ -7,7 +7,7 @@
 #include "BsAudioClip.h"
 #include "BsDataStream.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsAudioListener.h

@@ -5,7 +5,7 @@
 #include "BsCorePrerequisites.h"
 #include "BsVector3.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Audio
 	 *  @{

Source/BansheeCore/Include/BsAudioManager.h

@@ -5,7 +5,7 @@
 #include "BsCorePrerequisites.h"
 #include "BsModule.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Audio-Internal
 	 *  @{

Source/BansheeCore/Include/BsAudioSource.h

@@ -6,7 +6,7 @@
 #include "BsIResourceListener.h"
 #include "BsVector3.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Audio
 	 *  @{

Source/BansheeCore/Include/BsAudioUtility.h

@@ -4,7 +4,7 @@
 
 #include "BsCorePrerequisites.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Audio
 	 *  @{

Source/BansheeCore/Include/BsBlendState.h

@@ -5,7 +5,7 @@
 #include "BsCorePrerequisites.h"
 #include "BsResource.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup RenderAPI
 	 *  @{
@@ -247,11 +247,11 @@ namespace std
 {
 /**	Hash value generator for BLEND_STATE_DESC. */
 template<>
-struct hash<BansheeEngine::BLEND_STATE_DESC>
+struct hash<bs::BLEND_STATE_DESC>
 {
-	size_t operator()(const BansheeEngine::BLEND_STATE_DESC& value) const
+	size_t operator()(const bs::BLEND_STATE_DESC& value) const
 	{
-		return (size_t)BansheeEngine::BlendState::generateHash(value);
+		return (size_t)bs::BlendState::generateHash(value);
 	}
 };
 }

Source/BansheeCore/Include/BsBlendStateRTTI.h

@@ -7,7 +7,7 @@
 #include "BsBlendState.h"
 #include "BsRenderStateManager.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsBoxCollider.h

@@ -7,7 +7,7 @@
 #include "BsVector3.h"
 #include "BsQuaternion.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Physics
 	 *  @{

Source/BansheeCore/Include/BsCAudioListener.h

@@ -6,7 +6,7 @@
 #include "BsAudioListener.h"
 #include "BsComponent.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCAudioListenerRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCAudioListener.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCAudioSource.h

@@ -6,7 +6,7 @@
 #include "BsAudioSource.h"
 #include "BsComponent.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCAudioSourceRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCAudioSource.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCBoxCollider.h

@@ -6,7 +6,7 @@
 #include "BsBoxCollider.h"
 #include "BsCCollider.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCBoxColliderRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCBoxCollider.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCCamera.h

@@ -6,7 +6,7 @@
 #include "BsCamera.h"
 #include "BsComponent.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components
 	 *  @{

Source/BansheeCore/Include/BsCCameraRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCCamera.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Engine

Source/BansheeCore/Include/BsCCapsuleCollider.h

@@ -6,7 +6,7 @@
 #include "BsCapsuleCollider.h"
 #include "BsCCollider.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCCapsuleColliderRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCCapsuleCollider.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCCharacterController.h

@@ -6,7 +6,7 @@
 #include "BsCharacterController.h"
 #include "BsComponent.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCCharacterControllerRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCCharacterController.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCCollider.h

@@ -6,7 +6,7 @@
 #include "BsCollider.h"
 #include "BsComponent.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCColliderRTTI.h

@@ -6,7 +6,7 @@
 #include "BsRTTIType.h"
 #include "BsCCollider.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCD6Joint.h

@@ -6,7 +6,7 @@
 #include "BsD6Joint.h"
 #include "BsCJoint.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCD6JointRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCD6Joint.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCDistanceJoint.h

@@ -6,7 +6,7 @@
 #include "BsDistanceJoint.h"
 #include "BsCJoint.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCDistanceJointRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCDistanceJoint.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCFixedJoint.h

@@ -7,7 +7,7 @@
 #include "BsCJoint.h"
 #include "BsJoint.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCFixedJointRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCFixedJoint.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCHingeJoint.h

@@ -6,7 +6,7 @@
 #include "BsHingeJoint.h"
 #include "BsCJoint.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCHingeJointRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCHingeJoint.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCJoint.h

@@ -6,7 +6,7 @@
 #include "BsJoint.h"
 #include "BsComponent.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCJointRTTI.h

@@ -6,7 +6,7 @@
 #include "BsRTTIType.h"
 #include "BsCJoint.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCMeshCollider.h

@@ -6,7 +6,7 @@
 #include "BsMeshCollider.h"
 #include "BsCCollider.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCMeshColliderRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCMeshCollider.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCPlaneCollider.h

@@ -6,7 +6,7 @@
 #include "BsPlaneCollider.h"
 #include "BsCCollider.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCPlaneColliderRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCPlaneCollider.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCRigidbody.h

@@ -8,7 +8,7 @@
 #include "BsVector3.h"
 #include "BsQuaternion.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCRigidbodyRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCRigidbody.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCSliderJoint.h

@@ -6,7 +6,7 @@
 #include "BsSliderJoint.h"
 #include "BsCJoint.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCSliderJointRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCSliderJoint.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCSphereCollider.h

@@ -6,7 +6,7 @@
 #include "BsSphereCollider.h"
 #include "BsCCollider.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCSphereColliderRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCSphereCollider.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCSphericalJoint.h

@@ -6,7 +6,7 @@
 #include "BsSphericalJoint.h"
 #include "BsCJoint.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Components-Core
 	 *  @{

Source/BansheeCore/Include/BsCSphericalJointRTTI.h

@@ -7,7 +7,7 @@
 #include "BsCSphericalJoint.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCamera.h

@@ -15,7 +15,7 @@
 #include "BsConvexVolume.h"
 #include "BsPostProcessSettings.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Renderer-Internal
 	 *  @{

Source/BansheeCore/Include/BsCameraRTTI.h

@@ -6,7 +6,7 @@
 #include "BsRTTIType.h"
 #include "BsCamera.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Engine

Source/BansheeCore/Include/BsCapsuleCollider.h

@@ -7,7 +7,7 @@
 #include "BsVector3.h"
 #include "BsQuaternion.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Physics
 	 *  @{

Source/BansheeCore/Include/BsCharacterController.h

@@ -6,7 +6,7 @@
 #include "BsPhysicsCommon.h"
 #include "BsVector3.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Physics
 	 *  @{

Source/BansheeCore/Include/BsCollider.h

@@ -9,7 +9,7 @@
 #include "BsVector3.h"
 #include "BsQuaternion.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Physics
 	 *  @{

Source/BansheeCore/Include/BsCommandBuffer.h

@@ -4,7 +4,7 @@
 
 #include "BsCorePrerequisites.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup RenderAPI
 	 *  @{

Source/BansheeCore/Include/BsCommandBufferManager.h

@@ -5,7 +5,7 @@
 #include "BsCorePrerequisites.h"
 #include "BsModule.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup RenderAPI-Internal
 	 *  @{

Source/BansheeCore/Include/BsCommandQueue.h

@@ -6,7 +6,7 @@
 #include "BsAsyncOp.h"
 #include <functional>
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup CoreThread-Internal
 	 *  @{
@@ -331,7 +331,7 @@ namespace BansheeEngine
 		}
 
 		/** @copydoc CommandQueueBase::flush */
-		BansheeEngine::Queue<QueuedCommand>* flush()
+		bs::Queue<QueuedCommand>* flush()
 		{
 #if BS_DEBUG_MODE
 #if BS_THREAD_SUPPORT != 0
@@ -341,7 +341,7 @@ namespace BansheeEngine
 #endif
 
 			this->lock();
-			BansheeEngine::Queue<QueuedCommand>* commands = CommandQueueBase::flush();
+			bs::Queue<QueuedCommand>* commands = CommandQueueBase::flush();
 			this->unlock();
 
 			return commands;

Source/BansheeCore/Include/BsCommonTypes.h

@@ -2,7 +2,7 @@
 //**************** Copyright (c) 2016 Marko Pintera ([email protected]). All rights reserved. **********************//
 #pragma once
 
-namespace BansheeEngine 
+namespace bs 
 {
 	/** @addtogroup Utility-Core
 	 *  @{

Source/BansheeCore/Include/BsComponent.h

@@ -6,7 +6,7 @@
 #include "BsGameObject.h"
 #include "BsBounds.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Scene
 	 *  @{

Source/BansheeCore/Include/BsComponentRTTI.h

@@ -7,7 +7,7 @@
 #include "BsComponent.h"
 #include "BsGameObjectRTTI.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @cond RTTI */
 	/** @addtogroup RTTI-Impl-Core

Source/BansheeCore/Include/BsCoreApplication.h

@@ -8,7 +8,7 @@
 #include "BsRenderWindow.h"
 #include "BsEvent.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Application-Core
 	 *  @{

Source/BansheeCore/Include/BsCoreObject.h

@@ -6,7 +6,7 @@
 #include "BsCoreObjectCore.h"
 #include "BsAsyncOp.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup CoreThread
 	 *  @{

Source/BansheeCore/Include/BsCoreObjectCore.h

@@ -5,7 +5,7 @@
 #include "BsCorePrerequisites.h"
 #include "BsAsyncOp.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup CoreThread
 	 *  @{

Source/BansheeCore/Include/BsCoreObjectManager.h

@@ -6,7 +6,7 @@
 #include "BsCoreObjectCore.h"
 #include "BsModule.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup CoreThread-Internal
 	 *  @{

Source/BansheeCore/Include/BsCorePrerequisites.h

@@ -217,7 +217,7 @@
 
 #include "BsHString.h"
 
-namespace BansheeEngine 
+namespace bs 
 {
 	static const StringID RenderAPIAny = "AnyRenderAPI";
 	static const StringID RendererAny = "AnyRenderer";
@@ -446,7 +446,7 @@ namespace BansheeEngine
 /* 						         Typedefs								*/
 /************************************************************************/
 
-namespace BansheeEngine
+namespace bs
 {
 	typedef CoreThreadAccessor<CommandQueueNoSync> CoreAccessor;
 	typedef CoreThreadAccessor<CommandQueueSync> SyncedCoreAccessor;
@@ -455,7 +455,7 @@ namespace BansheeEngine
 /************************************************************************/
 /* 									RTTI                      			*/
 /************************************************************************/
-namespace BansheeEngine
+namespace bs
 {
 	enum TypeID_Core
 	{
@@ -571,7 +571,7 @@ namespace BansheeEngine
 
 #include "BsResourceHandle.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Resources
 	 *  @{
@@ -596,7 +596,7 @@ namespace BansheeEngine
 
 #include "BsGameObjectHandle.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Scene
 	 *  @{
@@ -625,7 +625,7 @@ namespace BansheeEngine
 	/** @} */
 }
 
-namespace BansheeEngine
+namespace bs
 {
 	/**
 	 * Defers function execution until the next frame. If this function is called within another deferred call, then it will

Source/BansheeCore/Include/BsCoreRenderer.h

@@ -6,7 +6,7 @@
 #include "BsStringID.h"
 #include "BsRendererMeshData.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	struct PostProcessSettings;
 

Source/BansheeCore/Include/BsCoreSceneManager.h

@@ -6,7 +6,7 @@
 #include "BsModule.h"
 #include "BsGameObject.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Scene-Internal
 	 *  @{

Source/BansheeCore/Include/BsCoreThread.h

@@ -8,7 +8,7 @@
 #include "BsCoreThreadAccessor.h"
 #include "BsThreadPool.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup CoreThread-Internal
 	 *  @{

Source/BansheeCore/Include/BsCoreThreadAccessor.h

@@ -6,7 +6,7 @@
 #include "BsCommandQueue.h"
 #include "BsAsyncOp.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup CoreThread
 	 *  @{

Source/BansheeCore/Include/BsCurveCache.h

@@ -4,7 +4,7 @@
 
 #include "BsCorePrerequisites.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Animation-Internal
 	 *  @{

Source/BansheeCore/Include/BsD6Joint.h

@@ -5,7 +5,7 @@
 #include "BsCorePrerequisites.h"
 #include "BsJoint.h"
 
-namespace BansheeEngine
+namespace bs
 {
 	/** @addtogroup Physics
 	 *  @{