Some WIP manuals

Documentation/Manuals/Managed/gui.md

@@ -0,0 +1,11 @@
+Every GUIElement must be attached at one GUILayout to be visible. There are a few different types of GUILayout and they handle how elements are positioned:
+ - GUILayoutX - Child elements are aligned left to right
+ - GUILayoutY - Child elements are aligned top to bottom
+ - GUIPanel - User is allowed to manually position elements.
+
+GUILayout elements can also be parented to each other, e.g. a GUILayoutX can have two GUILayoutY children to create something similar to a two column table. This kind of layout system allows you to easily position GUI elements from within code, and ensures that the result looks good with different resolutions / window sizes.
+
+Every GUI element has a set of properties the user can change:
+ - Its dimensions (these can be fixed, or flexible so they adjust automatically with the size of the parent)
+ - Its position (this is automatically set for elements part of a GUILayoutX/GUILayoutY but can be used for manual positioning in GUIPanel)
+ - Style that controls the look of the element, this includes the graphics, text font, color, margins and similar

Documentation/Manuals/Native/architecture.md

@@ -0,0 +1,106 @@
+Architecture									{#architecture}
+===============
+[TOC]
+
+Banshee is implemented throughout many separate libraries. Spreading the engine implementation over different libraries ensures multiple things:
+ - Portions of the engine can be easily modified or replaced
+ - User can choose which portions of the engine are needed
+ - Internals are easier to understand as libraries form a clear architecture between themselves, while ensuring source code isn't all bulked into one big package
+ - It insures quality design by decoupling code and forcing an order of dependencies.
+ 
+All the libraries can be separated into four main categories:
+ - Layers - These are the core libraries of the engine. Each layer is built on top of the previous layer and provides higher level and more specific functionality than the other.
+ - Plugins - These are separate, independant, and in most cases optional libraries containing various high level systems. They always depend on a specific layer, depending how high level the system they implement is. You will be able to design your own plugins that completely replace certain portion of the engine functionality without having to modify the engine itself (e.g. use OpenGL instead of DirectX)
+ - Scripting - These are libraries used for interop between the C++ core and the scripting language, as well as the managed scripting libraries themselves. Generally these can also be counted as plugins, but they are a bit more tightly coupled with the engine core.
+ - Executable - These are small pieces of code meant to initialize and start up the engine/editor.
+ 
+# Layers #										{#arch_layers}
+The layers contain the core of the engine. All the essentials and all the abstract interfaces for plugins belong here. The engine core was split into multiple layers for two reasons:
+ - To give developers a chance to pick the level of functionality they need. Some people will want just core and utility and start working on their own engine while others might be just interested in game development and will stick with the editor layer.
+ - To decouple code. Lower layers do not know about higher levels and low level code never caters to specialized high level code. This makes the design cleaner and forces a certain direction for dependencies.
+
+Lower levels were designed to be more general purpose than higher levels. They provide very general techniques usually usable in various situations, and they attempt to cater to everyone. On the other hand higher levels provide a lot more focused and specialized techniques. This might mean relying on very specific rendering APIs, platforms or plugins but it also means using newer, fancier and maybe not as widely accepted techniques (e.g. some new rendering algorithm or a shader).
+
+Going from the lowest to highest the layers are:
+## BansheeUtility ##							{#arch_utility}
+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, file path parsing or events. Other things that belong here are the math library, object serialization and RTTI system, threading primitives and managers, among various others.
+
+## BansheeCore ##								{#arch_core}
+It is the second lowest layer and the first layer that starts to take shape of an actual engine. This layer provides some very game-specific modules tied into a coherent whole, but it tries to be very generic and offer something that every engine might need instead of focusing on very specialized techniques. Render API wrappers exist here, but actual render APIs are implemented as plugins so you are not constrained by specific subset. Scene manager, renderer, resource management, audio, animation, physics, importers and others all belong here, and all are implemented in an abstract way that they can be implemented/extended by higher layers or plugins.
+
+## BansheeEngine ##								{#arch_engine}
+Second highest layer and first layer with a more focused goal. It is built upon BansheeCore but relies on a specific sub-set of plugins and implements systems like scene manager and renderer in a specific way. For example DirectX 11 and OpenGL render systems are referenced by name, as well as Mono scripting system among others. Renderer that follows a specific set of techniques and algorithms that determines how are all objects rendered also belongs here.
+
+## BansheeEditor ##								{#arch_editor}
+And finally the top layer is the editor. It provides various editor specific features like the project library, built systems, editor window systems, 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.
+
+# Plugins #										{#arch_plugins}
+Banshee provides a wide variety of plugins out of the box. Some of these are fully optional, but all can be replaced with your own implementations. 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. Render API handles low level rendering, including features like vertex/index buffers, creating rasterizer/depth/blend states, shader programs, render targets, textures, draw calls and similar. Render API interface is defined in the BansheeCore layer.
+
+A few out of the box implementations are provided, the user can choose which one to use upon application startup. At least one must be present during start-up (can be a null renderer (i.e. one that does nothing, like for server purposes) if you choose to add one).
+
+### BansheeD3D11RenderAPI ###					{#arch_dx11rapi}
+Provides implementation of the Render API interface for DirectX 11. 
+
+### BansheeD3D9RenderAPI ###					{#arch_dx9rapi}
+Provides implementation of the RenderAPI interface for DirectX 9. 
+
+### BansheeGLRenderAPI ###						{#arch_GLrapi}
+Provides implementation of the 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), but 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 a single SpecificImporter class. The engine can start with zero importers, or with as many as you need.
+
+See [this link](TODOLINK) on a guide how to add your own importer. Some important importers are provided out of the box:
+
+### BansheeFreeImgImporter ###					{#arch_freeimg}	
+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 Texture format.
+
+### BansheeFBXImporter ###						{#arch_fbx}
+Handles import of FBX mesh files. Uses Autodesk FBX SDK for reading the files and converting them into engine Mesh format.
+
+### BansheeFontImporter ###						{#arch_font}
+Handles import of TTF and OTF font files. Uses FreeType for reading the font files and converting them into engine Font format.
+
+### BansheeSL ###								{#arch_bsl}	
+Provides an implementation of the Banshee's shader language that allows you to easily define an entire pipeline state in a single file.
+
+## Others ##									{#arch_others}
+
+### BansheeOISInput ###							{#arch_ois}		
+Handles raw mouse/keyboard/gamepad input for multiple platforms. Implements the RawInputHandler interface. Uses the OIS library specifically modified for Banshee (source code available with Banshee's dependencies). Be aware that there is also an 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 ###							{#arch_physx}
+Handles physics: rigidbodies, colliders, triggers, joints, character controller and similar. Implements the Physics interface (and all related classes). Uses NVIDIA PhysX as the backend.
+
+### BansheeMono ###								{#arch_mono}
+Provides access to the C# scripting language using the Mono runtime. All the script interop libraries (listed below) depend on this plugin, as well as a specific engine layer.
+
+### RenderBeast ###								{#arch_rbeast}	
+Banshee's default renderer. Implements the 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 having 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 [this link](TODOLINK) for more information on how the renderer works and how to potentially implement your own.
+
+# Scripting #									{#arch_scripting}
+Scripting libraries can be placed into two different categories: 
+ - Interop libraries written in C++. These provide glue code between C++ and C# (e.g. converting types, managing objects and similar). These are prefixed with the letter S.
+ - Managed libraries containing actual managed code. These are prefixed with the letter M.
+ 
+Whenever adding a new type that exists in both script and managed code you will need to access both of these library categories. Read [this guide](TODOLINK) to learn more about adding your own scripting types.
+ 
+## SBansheeEngine ##							{#arch_sengine}
+Interop library that provides glue code between BansheeEngine layer and the scripting code in MBansheeEngine.
+
+## SBansheeEditor ##							{#arch_seditor}	
+Interop library that provides glue code between BansheeEditor layer and the scripting code in MBansheeEditor.
+
+## MBansheeEngine ##							{#arch_mengine}
+Provides most of the high-level C++ engine API available in BansheeEngine layer (e.g. scene object model, resources, GUI, materials, etc.) as a high-level C# scripting API. Certain portions of the API are provided in pure C# (like the math library).
+
+## MBansheeEditor ##							{#arch_meditor}
+Provides all editor specific functionality from the BansheeEditor layer as a C# scripting API (e.g. project library, building, scene view, etc.). Also implements a large number of editor features in pure C# on top of the provided engine and editor APIs (e.g. specific editor windows and tools).

Documentation/Manuals/Native/gui.md

@@ -0,0 +1,93 @@
+Creating custom GUI elements						{#customGUI}
+===============
+[TOC]
+
+Sometimes the built-in GUI elements are just not enough, for example when you need a very specific GUI element for your game (e.g. for displaying graphs, charts), want to use a special material or in general just need some more customization options. While in some cases you could construct such elements from the provided GUI elements, it is often more efficient to create a brand new customized type. New GUI elements can be created relatively easily and allow you to fully customize the look and interaction with your element.
+
+Before staring you should familiarize yourself how Banshee's GUI works from the users perspective. Make sure to read [GUI manual](TODOLINK) 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 GUIElementBase type. The elements can be categorized into two major groups:
+ - GUILayout: They derive from GUILayout and do not have any graphics, but instead they control the placement of all elements attached to them.
+ - GUIElement: These are your 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 GUIElement type. The minimum set of methods you need to implement for your custom elements are:
+ - _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 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.
+ - _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.
+ - _getNumQuads() - Returns the number of quads for the mesh of the render element at the specified index (e.g. one quad if the GUI element displays just one texture). This allows external systems how big of a buffer to allocate for element's mesh.
+ - _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.
+ - _getMaterial() - Here you should return a material that will be applied to the mesh output in the previous method. You can choose from a few pre-built material types and provide a texture and a color. If you wish to add a new custom material, check later in this guide.
+ - 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 ImageSprite and TextSprite classes. ImageSprite can easily generate image geometry of specified size, whether a simple quad or a Scale9grid image. And TextSprite will take a text string, font and additional options as input, and output a set of quads required for text rendering.
+
+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 GUIDimensions::create(). GUIElement will internally use dimensions provided by its style, but providing custom GUIDimensions allows you to override the dimensions in the style. For that reason you should provide the user with a constructor that accepts 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 GUITexture (in BsGUITexture.cpp) for a simple implementation of everything mentioned.
+
+# Style # {#customGUI_b}
+
+Every GUIElement has an access to a specific style (GUIElementStyle). You can access the style by calling _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 & material.
+
+You might also need to override 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() anyway.
+
+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. You should 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).
+
+See the GUIWidget chapter for more information about styles.
+
+# 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:
+ - _mouseEvent - Triggered when the mouse moves and/or is clicked
+ - _textInputEvent - Triggered when the user inputs some text on the keyboard
+ - _virtualButtonEvent - Triggered when a certain virtual button is pressed (see [Input guide](TODOLINK) if you wish to know about virtual buttons)
+ - _commandEvent - Triggers when some kind of a specialized event happens, like losing/gainging focus, deleting text, selecting text, forcing redraw and similar. See GUICommandEventType for an explanation of what each does.
+ 
+Check out _mouseEvent implementation in GUIButtonBase for a simple implementation of a mouse hover on/off and click functionality. Check GUIInputBox for a more complex implementation of input.
+
+If working with text input also take a look at GUIInputCaret and GUIInputSelection, as they help with input caret movement, and text selection. Instances of these classes can be accessed from GUIManager with getInputCaretTool() and getInputSelectionTool(). This is completely optional and you may choose to handle these manually. See GUIInputBox for example usage.
+
+# Updating # {#customGUI_c}
+
+If your element allows the user to update certain contents of it, you need to notify the GUI system so it knows when to rebuild the element. For example if you 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 elements 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 other:
+ - _markMeshDirty() - Causes the batched GUI mesh to be re-assembled, will cause a call to GUIElement::_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.
+ - _markContentDirty() - Has the same effect as _markMeshDirty(), but will also trigger an GUIElement::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.)
+ - _markLayoutDirty() - 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.
+
+When setting GUI contents consider using the provided 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_d}
+ 
+## GUIWidget ## {#customGUI_d_a}
+ 
+Every GUIElement is internally part of a specific GUIWidget. A GUIWidget is a Component (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 widgets 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 contain a 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}
+
+GUIManager is the top level GUI manager that handles almost everything GUI related. It keeps tracks of all GUIWidgets and GUIElements. 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.
+
+And every GUIWidget has a GUISkin which contains a list of all the GUI element styles. The style for a specific element will depend on the GUIWidget it is assigned to, and the GUISkin assigned to the widget. (See below for information on GUIWidgets). 
+
+## Text ##  {#customGUI_d_c}
+
+If you ever require to render text completely manually (perhaps even outside of the GUI system), take a look at 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](TODOLINK) to learn how to create scripting API objects. 
+
+Every GUI scripting interop object must implement TScriptGUIElement, but other than that creating GUI interop objects is the same as the general case described in the guide above. See ScriptGUITexture for an example.
+
+Creating managed GUI objects is again the same as the general case. Take a look at the managed GUITexture.

Documentation/Manuals/Native/index.md

@@ -0,0 +1,34 @@
+Banshee Engine Documentation (Native)						{#mainpage}
+===============
+
+[TOC]
+
+Welcome to the documentation for the native (C++) API of the Banshee Engine.
+
+This documentation contains a set of [manuals](@ref manuals), an <a class="el" href="modules.html">API reference</a> and an alphabetical <a class="el" href="annotated.html">class list</a>.
+
+# Manuals # {#mainpage_a}
+Manuals should be your primary entry point into learning about Banshee. They will provide you with a view of the general architecture of the engine, as well as the architecture of the more important systems. They will also teach you have to extend/modify various parts of the engine, including adding custom GUI types, script objects, resources, importers, renderers and many more.
+ 
+The manuals generally do not cover user-facing functionality, and focus more on explaining the engine internals. To learn about user-facing functionality read the [scripting documentation](@ref TODO_LINK) - the C++ interfaces are very similar and are usually just a direct reflection of their script counterparts.
+ 
+[Visit](@ref manuals) 
+ 
+# API Reference # {#mainpage_b}
+API reference provides a categorized and hierarchical view of all the engine's classes. 
+
+All classes are categorized into three primary groups:
+ - **Layers** - Layers make up the core of the engine. Each layer is built directly on top of the previous one. This is what most people will be interested in.
+ - **Plugins** - Plugins are various interchangeable libraries that contain high level systems built on top of abstractions defined in the layers.
+ - **Implementation** - This contains all the helper types used for implementation. This is included due to a limitation in our documentation system, and the user should generally never need to access types here manually.
+ 
+You should read the [architecture](@ref architecture) manual for a more detailed breakdown of the architecture.
+
+_Be aware that non-public (private, protected, internal) methods/classes are not available in the API reference, but these objects are documented nonetheless. User has to look into the source code for this documentation._
+
+<a class="el" href="modules.html">Visit</a>
+
+# Class list # {#mainpage_c}
+Contains the same information as the API references, but with all clases listed in a flat list, alphabetically.
+
+<a class="el" href="annotated.html">Visit</a>

Documentation/Manuals/Native/scripting.md

@@ -0,0 +1,102 @@
+Scripting									{#scripting}
+===============
+[TOC]
+
+Often when you extend the native portion of the engine in some way you might want to expose that functionality to the managed (i.e. scripting) code. This guide will show you how to create C++ objects that communicate with C# code and vice versa. 
+
+Before we delve into the specifics of Banshee’s scripting you should understand how the scripting system works in general. All C# script code is ran from the C++ part of the engine using the Mono runtime. Mono runtime allows you to communicate with C# code (and for the C# code to communicate with C++), query class/method/field information and pass data between the two languages.
+
+# Scripting system #	{#scripting_a}
+
+Because using Mono directly is complex because 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. Here is where the Mono runtime is started and assemblies are loaded (and unloaded), while also giving you detailed information about all loaded classes and a way to communicate with managed code.
+
+The main entry point is the MonoManager class which allows you to start the runtime and load assemblies. The most important method here is MonoManager::loadAssembly. It takes as assembly path to load and returns a MonoAssembly object. 
+
+## MonoAssembly 	{#scripting_a_a}
+MonoAssembly gives you access to all classes in the assembly. You can retrieve all clases using MonoAssembly::getAllClasses, or retrieve a specific one by calling MonoAssembly::getClass(namespace, typename). Both of these methods return a MonoClass object.
+
+## MonoClass 	{#scripting_a_b}
+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 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 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 MonoClass::getMethod(), accepting a name (without parameter types) and a number of parameters. If your method is overloaded you can use MonoClass::getMethodExact which accepts a method name, and a comma separated list of parameter types. You may also use MonoClass::getAllMethods to retrieve all methods in a class.
+
+All the above methods return a 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.
+
+To invoke a method you may use multiple approaches:
+ - MonoMethod::invoke - Calls the exact method on a specific managed object, with the provided parameters. We’ll take about how managed objects are referenced in native code later, as well as how passing data between C++ and managed code works.
+ - MonoMethod::invokeVirtual - Calls the method polymorphically. Determines the actual type of the provided managed object instance and calls an overriden method if available.
+ - 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 MonoMethod::invoke but is significantly faster. A helper method MonoUtil::invokeThunk is provided - it is suggested you use it instead of calling thunks manually (it handles exceptions without you needing to worry about it).
+
+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 MonoClass by calling MonoClass::getField or MonoClass::getAllFields. The returned value is a MonoField which provides information about the field and allows you to retrieve and set values in the field using MonoField::getValue/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 MonoClass by calling MonoClass::getProperty or MonoClass::getAllProperties. The returned value is a MonoProperty which provides information about the property and allows you to retrieve and set values in 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 MonoPropety::get/MonoProperty::set and MonoProperty::getIndexed/MonoProperty::setIndexed.
+
+## Attributes {#scripting_a_f}
+Attributes provide data about a class, method or field provided at runtime, and allows them to be customized in more detail. 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: MonoClass::getAllAttributes(), which returns a list of MonoClass objects that identify the attribute types. To get the actual object instance of the attribute you may call MonoClass::getAttribute with the wanted attribute MonoClass. After that you can call methods, work with field values and other, same as you would with a normal object.
+
+Attributes can also be retrieved from MonoMethod using MonoMethod::getAttribute, or from MonoField using 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 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: 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 “mono_gchandle_new” which will return a handle to the object. The handle will keep the object alive until you release it by calling “mono_gchandle_free”. Be aware if an assembly the object belongs to is unloaded all objects will be destroyed regardless of the 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.
+
+The rules are:
+ - All primitive types are passed as in. e.g. an int in C# will be a 4 byte integer in C++, a float will be a float, a bool will be a bool.
+ - All reference types (“class” in C#) are passed as a MonoObject*. Strings and arrays are handled specially, where strings are passed as MonoString*, and arrays as MonoArray*.
+   - If a reference type parameter in a method 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) are provided as raw memory. Make sure that all structs in C# 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 in managed code (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 MonoField::getValueBoxed method instead MonoField::getValue, which will return a struct in the form of a MonoObject. You can then retrieve the raw struct value by calling mono_object_unbox.
+  
+Banshee provides a helper code to assist with marshalling string:
+ - MonoUtil::toWString/MonoUtil::toString - Converts a MonoString* to a native string
+ - MonoUtil::fromWString/MonoUtil::fromString - Converts a native string into a MonoString*
+
+ScriptArray allows you to construct new arrays and read managed arrays, easily. 
+
+To create a new arrays call 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 ScriptArray::set and retrieve the managed MonoArray* by calling ScriptArray::getInternal.
+
+To more easily read existing arrays create a new ScriptArray by providing it with a MonoArray* as its parameters. Then you can easily retrieve the size of the array using ScriptArray::size(), and the value of its elements by calling 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.
+
+The first step is to define a stub method in managed code, like so:
+	[MethodImpl(MethodImplOptions.InternalCall)]
+	private static extern float Internal_GetSomeValue(MyObject obj);
+
+You then hook up this method with managed code by calling MonoClass:addInternalMethod. In this specific case it would be myClass->ddInternalMethod(“Internal_GetSomeValue”, &myNativeFunction), assuming myClass is a MonoClass of the type that contains the stub method. After this call any call to the managed stub method will call the provide native function myNativeFunction. You should take care to properly handle parameter passing as described above.
+
+Take a look at 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).
+
+TODO - ScriptObject, SCRIPT_OBJ macro, initRuntimeData, metaData
+TODO - Pointer caching (both on managed and native sides)
+TODO - Assembly refresh, isPersistent, _beginRefresh(), _endRefresh(), _clearManagedInstance(), _restoreManagedInstance, _onManagedInstanceDeleted
+