/Dlls/Delta.Engine.xml

Large files files are truncated, but you can click here to view the full file

<?xml version="1.0" encoding="utf-8"?>

<doc>

  <assembly>

    <name>Delta.Engine</name>

  </assembly>

  <members>

    <member name="T:Delta.Engine.SystemInformation">

      <summary>

            Base system information class that is implemented in each platform

            module. It provides system information that does not change over the

            course of a running application or does not need updates. Some method

            might take some time, for example determining the cpu speed can take

            a few ms, so only call it when really needed. Access is provided through

            Application.Information, which is only initialized when first used. The

            Delta Engine itself very rarely needs this class, mostly only to make

            some cpu speed checks and getting MaxVertexShader and MaxPixelShader.

            </summary>

    </member>

    <member name="M:Delta.Engine.SystemInformation.InvokeLowMemory">

      <summary>

            Helper method to invoke the low memory event for the native

            implementations.

            </summary>

    </member>

    <member name="M:Delta.Engine.SystemInformation.InvokeLowBattery">

      <summary>

            Helper method to invoke the low battery event for the native

            implementations.

            </summary>

    </member>

    <member name="M:Delta.Engine.SystemInformation.InvokeAppPause">

      <summary>

            Helper method to invoke the app pause event for the native

            implementations.

            </summary>

    </member>

    <member name="M:Delta.Engine.SystemInformation.InvokeAppResume">

      <summary>

            Helper method to invoke the app resume event for the native

            implementations.

            </summary>

    </member>

    <member name="E:Delta.Engine.SystemInformation.OnLowMemory">

      <summary>

            Delegate for low memory cases on the current platform.

            Will be raised by the MonoDroidActivity for example.

            </summary>

    </member>

    <member name="E:Delta.Engine.SystemInformation.OnLowBattery">

      <summary>

            Delegate for low battery cases on the current platform.

            Will be raised by the MonoDroidActivity for example.

            </summary>

    </member>

    <member name="E:Delta.Engine.SystemInformation.OnAppPause">

      <summary>

            Delegate which is thrown once the app is paused or sent to the

            background. This can be the home button on Android, the Back button

            on WP7 or iOS.

            <para />

            For example on android this needs to dispose all opengl contents and

            destroy the graphics context, which will be recreated in OnAppResume.

            <para />

            This is also a good place to pause the GameTime and pause the actual

            game if needed.

            </summary>

    </member>

    <member name="E:Delta.Engine.SystemInformation.OnAppResume">

      <summary>

            Delegate which is thrown once the app is resumed after a pause.

            <para />

            For example on android this needs to recreate the graphics context and

            start the Run loop of the GameView once again.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.MachineName">

      <summary>

            Machine name for this system. On windows this is the Netbios name for

            this PC, which is the network computer name. On other platforms this

            will return some details about the platform (device name). In any case

            this property is not used by the engine, but still might be useful to

            link this name up to log or content server client names, which use it!

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.IsMobileDevice">

      <summary>

            Is this device a mobile device? Memory consumption and power usage

            should be optimized. In release builds the framerate will be bound

            to the maximum capabilities (there is no sense wasting more cpu time

            except for profiling and debugging). Mobile devices might also want

            different UI. Make sure to also check the IsTablet property. Common

            resolutions for mobile devices are 480x320, 800x480 and more for newer

            devices, see Application.Window.Size for the actual current resolution.

            </summary>

      <value>

        <c>true</c> if this device is a mobile device (phone or table);

            otherwise, <c>false</c>.

            </value>

    </member>

    <member name="P:Delta.Engine.SystemInformation.IsTablet">

      <summary>

            Is this device a tablet device (like an iPad or Android tablet). If

            this is set the IsMobileDevice setting is also true since tablets are

            also pretty mobile and need to be aware of their power usage. This

            property is most commonly used to check if we need a different UI or

            bigger effects or sometimes different optimizations or shaders. The

            best example is probably to have different in game ui for tablet

            devices just because there is more physical screen space. This means

            even if a mobile phone has the same resolution as a tablet device,

            a UI scene designed for a tablet device with lots of buttons might

            not be a good idea on a small phone with just 3.5 inches instead of

            9.7 inches for a tablet device. Usually the SceneEditor handles all

            this for you and allows designers to target specific device groups.

            </summary>

      <value>

        <c>true</c> if this device is a Tablet; otherwise, <c>false</c>.

            </value>

    </member>

    <member name="P:Delta.Engine.SystemInformation.IsConsole">

      <summary>

            This property is used to mark console devices (Xbox 360, PS3, Wii,

            or even PSP, N3DS or other devices that might be mobile too).

            </summary>

      <value>

        <c>true</c> if this device is a Console; otherwise, <c>false</c>.

            </value>

    </member>

    <member name="P:Delta.Engine.SystemInformation.MaxResolution">

      <summary>

            This property returns for every platform the maximum resolution that

            is possible or makes sense (usually limited by the device display or

            GPU). Normally this should be the full screen resolution, but on some

            systems we might want a lower resolution for better performance or on

            Windows we can use windowed mode with a smaller resolution for testing.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.Language">

      <summary>

            Grab the current language of the running system. Currently only checks

            for the 5 languages: German, Spanish, French, Italian and English

            (which is always the fallback).

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.Username">

      <summary>

            Username of the current platform. E.g. in Windows this is the

            user account that is currently logged in. On other platforms this

            feature might not be supported and then just "Player" is returned.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.CpuName">

      <summary>

            Gets the name of the CPU of the currently used device. Most devices

            only have a certain CPU, but devices that come from many different

            manufacturers have very different CPUs and sometimes it can be useful

            to do some quick compares which CPU is there (e.g. on Windows you

            have many different CPUs from AMD or Intel, on Android there are many

            different manufacturers and CPU/GPU combinations).

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.GpuName">

      <summary>

            Gets the name of the GPU of the currently used device. Most devices

            only have a certain GPU (especially mobile and console devices have

            mostly the same GPU, Xbox 360 is always the same, etc.).

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.CpuSpeed">

      <summary>

            Cpu speed for this device in Mhz. Not really comparable since each

            platform has different characteristics and even on the same platforms

            the same CPU speed in Mhz might be much slower or faster depending

            on the architecture and chip manufacturer (AMD vs intel, recent or

            older generation, etc.). Should also be used together with CoreCount!

            This cpu speed is just the speed of the first core, which is very

            rarely different from the other cores and the first core is usually

            the important one anyway for game logic.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.CpuUsage">

      <summary>

            The usage of the cpu's in percent 0-1 stored as a float.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.CoreCount">

      <summary>

            Returns the number of the cores in the CPU or if there is multiple

            CPUs how many cores are available together. This includes hyperthreaded

            cores as well (so an i7 has 8 hyperthreaded cores). Most mobile devices

            only will have one core, but some already have 2 (iPad 2) or even 4

            (Tegra 3).

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.MaxRam">

      <summary>

            Maximum ram available on this machine in MB. Might be used by other

            processes, but still a useful number to know. On Windows machines

            most of this can usually be used for a big game, on mobile devices it

            is more important to check how much memory is really left as there is

            no virtual memory and memory used by other applications is only freed

            if they are closed down by the OS.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.UsedRam">

      <summary>

            Gets the amount of used ram in MB by this process. We cannot really

            control how much memory is going to be freed, but we can make sure

            to unload content and garbage collect after a game or level is

            finished.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.AvailableRam">

      <summary>

            Available ram in MB, which is especially important on mobile devices.

            If this goes close to 0, we cannot load any more content, especially

            images. Either other content needs to be unloaded or the device OS

            needs to be asked to free up some more memory. Worst case scenario is

            that the OS will close this app because it needs too much memory and

            is still requesting more, which is obviously not good. On some

            platforms (e.g. iOS) this is called UserRam because MaxRam is usually

            way bigger and not usable because much of it is already taken.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.Version">

      <summary>

            Returns the engine version that is currently used. The current engine

            version is v0.9.3 (this will be increased each release).

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.MaxVertexShader">

      <summary>

            Returns the max. supported Vertex Shader version that is supported on

            the current system. The minor shader version is ignored, 1 means

            vertex shader 1.1 is available, 2 (most common on mobile devices)

            means vertex shader 2.0 is available, 3, 4 and 5 is for DirectX 9.0c,

            10 and 11.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.MaxPixelShader">

      <summary>

            Returns the max. supported Pixel Shader version that is supported

            on the current system. The minor shader version is ignored, 1 means

            pixel shader 1.1 is available, 2 (most common on mobile devices)

            means vertex shader 2.0 is available, 3, 4 and 5 is for DirectX 9.0c,

            10 and 11. More detailed information can be requested using the

            concrete graphic framework (e.g. XNA, OpenTK or SharpDX).

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.IsShaderSupported">

      <summary>

            Checks if the current graphics card can use Shaders.

            </summary>

      <returns>Returns 'true' if Shaders are supported.</returns>

    </member>

    <member name="P:Delta.Engine.SystemInformation.SoundCardAvailable">

      <summary>

            Flag determining if a sound card is available for music, sound and

            video playback or if this feature is not available on the current

            platform.

            </summary>

    </member>

    <member name="P:Delta.Engine.SystemInformation.MaxSoundChannels">

      <summary>

            How many sound channels does this device support? If this is 0 no

            sound card is installed or can be used. To disable sound in the app

            use the Settings.Modules.IsSoundEnabled property. Usually this number

            is 4 or much higher (100), but there is obviously also a performance

            impact if using too many sounds at the same time.

            The engine currently allows only the number of this property for

            simultaneously played sounds.

            </summary>

    </member>

    <member name="T:Delta.Engine.SettingsNodes.ModulesSettings">

      <summary>

            Modules settings

            </summary>

    </member>

    <member name="M:Delta.Engine.SettingsNodes.ModulesSettings.#ctor">

      <summary>

            Create modules settings is not allowed, only Settings can do this!

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.GraphicModule">

      <summary>

            Graphic module, can be multiple entries separated by commas.

            The name of this module is the assembly name minus Delta.Graphics.

            This can be whatever assembly can be found in the current directory

            that contains an Graphic class (will be searched by Factory).

            <para />

            On Windows OpenTK works fine and does not need any extra installation.

            For more advanced DirectX 11 features just use SharpDX!

            Most mobile and console platforms will use some form of OpenGL,

            WP7 and Xbox 360 use XNA.

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.EmulatorName">

      <summary>

            Emulator name in case we are trying to use some Emulator on Windows.

            One example is OpenGL ES, which does not exist for windows, but still

            can be tested with an OpenGL ES emulator like the one from PowerVR.

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.AudioModule">

      <summary>

            Audio module, mostly OpenAL, DirectX or XNA as implemented by the

            native platform or OpenTK, SharpDX or XNA.

            The name of this module is the assembly name minus Delta.Multimedia.

            This can be whatever assembly can be found in the current directory

            that contains an Sound or Music class (will be searched by Factory)

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.VideoModule">

      <summary>

            Video module, which is mostly a platform specific implementation that

            only works on the current platform (e.g. MonoTouch for iOS), but for

            Windows, Linux and MacOS Vlc is used, which works on all of those.

            The name of this module is the assembly name minus Delta.Multimedia.

            This can be whatever assembly can be found in the current directory

            that contains an Video class (will be searched by Factory)

            <para />

            This is empty by default, but if video playback is needed just use Vlc.

            OpenTK does not help us for video playback, so try to use the Vlc

            library (open source too) for video playback on Windows.

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.InputModule">

      <summary>

            Input module is just "Windows" by default, but can be changed to any

            other input module to support more features and game controllers.

            The name of this module is the assembly name minus Delta.InputSystem.

            This can be whatever assembly can be found in the current directory

            that contains an Input class (will be searched by Factory)

            <para /> 

            For Input in Windows, it is much better to have the more accurate

            keyboard and mouse event system instead of polling from Xna, if

            you want to support XnaTouch or XnaGamePad, you need to add this

            here. Same goes for WiimoteAccelerometer, WiimoteGamePad and even

            MultiMouse (all advanced features, not enabled by default).

            A complex example might be "Wiimote, MultiMouse, Xna, Windows" to

            use all Wiimote, then MultiMouse, then Xna classes and as a fallback

            the Windows InputSystem (if the others are not available).

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.PhysicsModule">

      <summary>

            Physics module(s) that should be used for this application.

            Default physics module is empty, but Jitter is used by default when

            you enable physics in the Content Manager Settings, because it works

            for 3D and 2D, but for 2D Farseer is usually all you need (which can't

            do 3D however). JigLib is also an option (if Jitter is missing), but

            vanilla JigLibX requires the XNA 4.0 assemblies for testing!

            <para />

            Other options are in the future Apex and PhysX, Ageia, Havoc and

            others, but keep in mind that many of these will NOT work on all

            platforms, JigLib and Farseer do.

            <para />

            By default this is empty, but you can select any physics engine on

            Windows and most of them work on all other platforms as well. Use

            the Content Manager Settings dialog to change.

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.IsSoundEnabled">

      <summary>

            Is true if it's allowed to play any sound effects. Note: That

            doesn't affect playing music. This is sometimes used as a game setting

            to enable/disable sounds, but usually it is a debug setting.

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.IsMusicEnabled">

      <summary>

            Is true if it's allowed to play any music. Note: That doesn't affect

            playing sound effects. This is sometimes used as a game setting

            to enable/disable sounds, but usually it is a debug setting.

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.IsVideoEnabled">

      <summary>

            If this is false, no videos will be played (every call to Play will

            just return and the screen will continue to the next one usually).

            Usually used to skip intro videos to speed up the startup (for testing

            or if users are annoyed by videos ^^)

            </summary>

    </member>

    <member name="P:Delta.Engine.SettingsNodes.ModulesSettings.IsTouchEnabled">

      <summary>

            If this is false, no touch input will be processed. This is useful to

            optimize on platforms where touch input is not available or where it

            might be very iffy (e.g. Windows 7 can do multi touch, but almost

            no one has a multi touch capable screen). By default true.

            </summary>

    </member>

    <member name="T:Delta.Engine.Dynamic.DynamicModule">

      <summary>

            Base class for all modules. Derived classes do need to implement the Run

            method and you need to setup your parent type in the constructor. Each

            Module has a name and provides a link to the parent module (null is only

            used for the application module) and all child modules it contains. We

            also got a method to add child modules via AddModule and SetupParent to

            setup the parents later when we execute the modules (this delayed

            creation has the advantage that we can have much more code in the

            constructors without forcing to create parent modules yet). Most module

            do not really care where stuff is happening, all data must be known),

            all we need is the Run method, which will handle all the work!

            </summary>

    </member>

    <member name="F:Delta.Engine.Dynamic.DynamicModule.isValid">

      <summary>

            Value cache for the property IsValid.

            </summary>

    </member>

    <member name="M:Delta.Engine.Dynamic.DynamicModule.#ctor(System.String,System.Type)">

      <summary>

            Create base module. Only uses a name and parent type to link it up.

            The type can be an interface if we don't know the specific class or

            it can be a specific class to link up with that parent module.

            NOTE: DynamicModules MUST be created via Factory.Create() in order to

            be added to ModuleList. If you want to allow construction via new,

            you must call AddToDynamicModuleList() somewhere in your constructor

            </summary>

    </member>

    <member name="M:Delta.Engine.Dynamic.DynamicModule.ToString">

      <summary>

            Since the normal ToString method is boring, provide some more useful

            information for the debugger and anyone else using this method.

            </summary>

      <returns>

            A <see cref="T:System.String" /> that represents this instance.

            </returns>

    </member>

    <member name="M:Delta.Engine.Dynamic.DynamicModule.Run">

      <summary>

            Run code, implement whatever you want to have executed. Some modules

            have no run code, they are just initialized and don't execute anything

            special. Usually this method has some code however that will be

            executed each tick. If not, then just declare an empty Run method,

            which useful to just make sure capabilities are enabled. Execution is

            triggered via ExecuteRunLoop, which calls all Run methods.

            </summary>

      <remarks>

            Also note that Run calls can be multi-threaded, which are sync-ed up

            at the parent's Run method. This could greatly improve performance,

            especially if we have many children Run methods in parallel.

            Good post about an ideal multi threading solution with messaging:

            http://www.zeromq.org/blog:multithreading-magic

            See RunWithChildrenBefore and RunWithChildrenAfter on how this is

            implemented here, with runs children multi-threaded if

            Settings.Extra.MultithreadedModules is turned on (by default it is on).

            </remarks>

    </member>

    <member name="M:Delta.Engine.Dynamic.DynamicModule.Dispose">

      <summary>

            Dispose

            </summary>

    </member>

    <member name="P:Delta.Engine.Dynamic.DynamicModule.Name">

      <summary>

            Name for this module, only set in the constructor! This is usually

            the name of this class, but do not confuse this with the module type,

            each module can have a different purpose for Name, content for example

            might use it for content loading and unique accessing content!

            </summary>

    </member>

    <member name="P:Delta.Engine.Dynamic.DynamicModule.IsValid">

      <summary>

            Valid flag. Disable if Valid was set to false (something failed or we

            don't want to use this anymore). Default is always enabled.

            </summary>

    </member>

    <member name="P:Delta.Engine.Dynamic.DynamicModule.IsDisposed">

      <summary>

            Is this class instance already disposed again? Useful to check if we

            still can dispose dependant objects (like geometry for graphics).

            </summary>

    </member>

    <member name="T:Delta.Engine.Settings">

      <summary>

            Settings class. Holds general information about an application or game

            using the Delta Engine. Settings.xml will be generated if non-existent.

            <para />

            Use DeltaLauncher to change settings or modify the XML file directly.

            Settings include global application settings like PlayerName, Language

            or Resolution,<para />but also debug settings like which modules are

            used for rendering, sound, video, etc. and also all the input commands

            that are currently hooked up (for movement, hot keys, etc.)

            <para />

            See http://wiki.deltaengine.net/Private.Settings.ashx

            </summary>

    </member>

    <member name="M:Delta.Engine.Settings.AlignResolution">

      <summary>

            Helper method to align resolution to multiple of 8 or 32 depending

            on the platform.

            <para />

            Note: In most cases the target resolution will already be the

            device default resolution, which is fitting into this rule anyway!

            For defaults check out the following link (see Stride), ES 1.1 and

            ES 2.0 have mostly a multiple of 32, ES 3.0 is a multiple of 8.

            http://processors.wiki.ti.com/index.php/Render_to_Texture_with_OpenGL_ES

            <para></para>

            Some examples how fast each resolution is: All are multiples of

            32 except 600, 720 and some other bigger Tegra and PC

            resolutions, these are still multiples of 8 pixels however:

            480*320   = 153600 Pixels (default iPhone and iPod resolution)

            512*320   = 163840 Pixels (custom low resolution for performance)

            640*384   = 245760 Pixels (custom low resolution for performance)

            800*480   = 384000 Pixels (default for WP7, Android Mobiles)

            960*640   = 614400 Pixels (default iPhone 4 Resolution)

            1024*600  = 614400 Pixels (older/smaller Tegra Tablet resolution)

            1024*768  = 786432 Pixels (iPad and older Windows Resolution)

            1280*720  = 921600 Pixels (Medium HD Resolution)

            1366*768  = 1049088 Pixels (bigger Tegra Tablet resolution)

            1680*1050 = 1764000 Pixels (PC resolution 20-22 inch displays)

            1920*1080 = 2073600 Pixels (Full HD Resolution, lots of pixels)

            As you can see going Medium or even Full HD is a lot of pixels!

            Pixel shaders on mobile devices are not very fast, so if you have

            complex shaders, reduce the resolution to still achieve good

            performance or only use simple shaders to render as fast as

            possible!

            </summary>

    </member>

    <member name="M:Delta.Engine.Settings.Equals(System.Object,System.Object)">

      <summary>

            Equals, just to hide the visibility of this method.

            </summary>

      <param name="objA">First object</param>

      <param name="objB">Second object</param>

      <returns>True if both objects are equal</returns>

    </member>

    <member name="M:Delta.Engine.Settings.ReferenceEquals(System.Object,System.Object)">

      <summary>

            Reference equals

            </summary>

      <param name="objA">First object</param>

      <param name="objB">Second object</param>

      <returns>

            True if both objects are the same instance, otherwise false.

            </returns>

    </member>

    <member name="M:Delta.Engine.Settings.Load">

      <summary>

            Loads the settings from file. This will first check if the file

            is locally accessible. If that's true, we load it from there. If not

            we try to load it from the content path. The content settings file is

            only loaded once, after that we always use the local setting file!

            </summary>

    </member>

    <member name="M:Delta.Engine.Settings.Save">

      <summary>

            Save the settings to local file. Xml data is written by hand until

            XmlHelper is useful again.

            </summary>

    </member>

    <member name="M:Delta.Engine.Settings.SetDefaultsFromContent(Delta.Utilities.Xml.XmlNode)">

      <summary>

            Set the defaults from the content DefaultSettings.xml. If the

            Settings.xml already existed and was loaded, only the Modules part

            is replaced, otherwise the whole Settings is replaced and loaded.

            </summary>

      <param name="node">

            The xml node data to load the default settings from. This has most

            likely already be done in the constructor, but if that failed we set

            everything again here.

            </param>

    </member>

    <member name="F:Delta.Engine.Settings.DefaultResolution">

      <summary>

            Default resolution, will return the default resolution on each

            platform, which is often the only resolution supported or a good

            standard value. On Windows it will be 1024x768, which is nice

            for debugging and testing iPad, iPhone, etc. platforms.

            Internal because this is used as a fallback for invalid resolutions

            in ScreenSpace.CalculateAspectRatio.

            </summary>

    </member>

    <member name="F:Delta.Engine.Settings.CommonResolutions">

      <summary>

            List of CommonResolutions used by most devices. Used mostly by tools

            to group common resolutions for most devices together. Also used for

            fonts, each font needs a configuration for all of these resolutions.

            For tools and fonts it works like this: We go up this list until

            we reach a point where our current resolution is bigger than the

            given one. Then we stop and use that resolution. For example 1600x1200

            would go up to 1280x720 because 1920x1080 does not fit anymore.

            </summary>

    </member>

    <member name="F:Delta.Engine.Settings.Extra">

      <summary>

            Extra settings for more detailed settings, initialized in constructor.

            </summary>

    </member>

    <member name="F:Delta.Engine.Settings.Modules">

      <summary>

            Modules settings for all used modules (graphics, sound, physics, etc.)

            Initialized and loaded in constructor. Please note that the

            Settings.xml does not contain any Module settings, only the fallback

            values are set in the ModulesSettings class. Once the DefaultSettings

            from the content have been loaded, the actual used modules are set.

            </summary>

    </member>

    <member name="F:Delta.Engine.Settings.Debug">

      <summary>

            Debug settings, initialized in constructor, can be accessed from

            everywhere (no matter if in debug mode or not) because the default

            settings are useful and sometimes even required (like Content path).

            </summary>

    </member>

    <member name="F:Delta.Engine.Settings.Optional">

      <summary>

            Optional settings that can be saved to the settings file. Getting data

            out is a little bit more cumbersome (via strings), but should work

            fine for any game or application that needs a little extra :)

            </summary>

    </member>

    <member name="P:Delta.Engine.Settings.PlayerName">

      <summary>

            The name of the player. Can be changed by the application.

            </summary>

    </member>

    <member name="P:Delta.Engine.Settings.AvailableLanguages">

      <summary>

            List of available languages for this application. Localization will

            contain text entries for each of these languages and content entries

            like images can be localized in these languages as well. Use Language

            for the currently selected language! Note: This is read-only!

            </summary>

    </member>

    <member name="P:Delta.Engine.Settings.Language">

      <summary>

            Gets or sets the currently selected language of the application.

            You are only allowed to switch to a supported language listed in the

            AvailableLanguages list. Can be changed by the application.

            </summary>

    </member>

    <member name="P:Delta.Engine.Settings.Resolution">

      <summary>

            Returns the current resolution from the settings. This WILL NOT change

            the current running window or viewport, use Application.Window to do

            that (they call this property too and will make sure it is all sync-ed

            up). This are the setting for the next time we load settings. For this

            reason setting the Settings resolution is internal and should not be

            done via game code. Instead change your content project settings or use

            Application.Window.Resize to do dynamic resizing in your application.

            <para></para>

            For best performance, we ensure the render-buffer height and width

            are each a multiple of 8 pixels (32 pixels for iOS and WP7, but

            this limit is not consistent on Android, e.g. the PC or Tegra can

            render 720p or 1024x600 (both not a multiple of 32) totally fine).

            See AlignResolution, which will be called when loading or saving!

            </summary>

    </member>

    <member name="E:Delta.Engine.Settings.LanguageChanged">

      <summary>

            This event occurs every time the language settings will be changed.

            </summary>

    </member>

    <member name="M:Delta.Engine.Settings.SettingsTests.OptionalSettings">

      <summary>

            Optional settings

            </summary>

    </member>

    <member name="T:Delta.Engine.Dynamic.RequireAttribute">

      <summary>

            For types which require a given type to have its implementation

            determined first. This attribute enforces given type to be instantiated

            first. Usually given type should be a singleton type.

            </summary>

    </member>

    <member name="M:Delta.Engine.Dynamic.RequireAttribute.#ctor(System.Type,Delta.Engine.SettingsNodes.ModuleType)">

      <summary>

            Create require attribute.

            </summary>

      <param name="setRequiredType">The type that is required.</param>

      <param name="setSetting">The settings item that should be

            checked for creating an implementation of this type.</param>

    </member>

    <member name="P:Delta.Engine.Dynamic.RequireAttribute.RequiredType">

      <summary>

            Required type.

            </summary>

      <value>

            The type of the required.

            </value>

    </member>

    <member name="P:Delta.Engine.Dynamic.RequireAttribute.Setting">

      <summary>

            Settings item.

            </summary>

    </member>

    <member name="T:Delta.Engine.Application">

      <summary>

            The Application.Start method starts the whole game and engine up. You

            can provide derived a Application class if you need different

            implementations on other platforms and override the methods (e.g.

            IPhoneApplication calls its own Main method, it can't use a while loop).

            Each platform has its own implementation of this class, which is 99%

            the same, just the startup sequence and RunTick is a little different.

            </summary>

    </member>

    <member name="F:Delta.Engine.Application.information">

      <summary>

            System information instance, only initialized when the Information

            property is used (which it not happening often).

            </summary>

    </member>

    <member name="F:Delta.Engine.Application.BackgroundColor">

      <summary>

            Represents the color which that the back buffer will be cleared. Can

            be changed from everywhere. By default is Black which means we will

            clear the back buffer with the black color each frame, in unit tests

            this is changed to DarkBlue by default. You can also set the background

            color to Uused, which speeds up rendering because it results in not

            clearing of the (native) backbuffer. This is useful when we already

            have a "fullscreen background" (2D or 3D scene) rendered.

            </summary>

    </member>

    <member name="M:Delta.Engine.Application.Start">

      <summary>

            Start application. You should do some initialization code before

            calling this as this will immediately quit if you have 0 modules

            (because there is no optionalRunCode or module in this overload).

            </summary>

    </member>

    <member name="M:Delta.Engine.Application.Start(Delta.Engine.Dynamic.DynamicModule)">

      <summary>

            Start application with given main dynamic module (the game or

            application or first module we want to run), which is inserted to the

            Application.Run if it was not done before. Then this method will start

            the execution loop, which will call Run for all modules and block until

            quitting via the Quit() method.

            </summary>

      <param name="initialModule">The main dynamic module to run

            the application with.</param>

    </member>

    <member name="M:Delta.Engine.Application.Start(Delta.Engine.Dynamic.RunDelegate)">

      <summary>

            Start the application and start the execution loop, which will call

            Run for all modules and block until quitting via the Quit() method.

            </summary>

      <param name="setOptionalRunCode">Set optional run code.</param>

    </member>

    <member name="M:Delta.Engine.Application.Quit">

      <summary>

            Quit the currently running application, will close the game loop

            and dispose all content and classes (via Base.Dispose()).

            </summary>

    </member>

    <member name="F:Delta.Engine.Application.ApplicationStarted">

      <summary>

            Delegate event fired when the Application.Instance is created and

            used for post startup code like the Settings Defaults.

            </summary>

    </member>

    <member name="F:Delta.Engine.Application.ApplicationClosing">

      <summary>

            Delegate event fired when the Application is closing and

            used for disposing native instances like the VLC manager when closing

            the application.

            </summary>

    </member>

    <member name="F:Delta.Engine.Application.quit">

      <summary>

            Set this variable to true to quit the application loop. Usually done

            in the Quit method, which can do different things on each platform,

            but should always set this variable to true to quit the game loop.

            We also keep an extra variable hasStartedYet to check if we have

            called the Start method already. All content loading should be delayed

            and if content is loaded before Start a warning will be shown by

            Content.Data, which should be fixed with delayed content loading.

            </summary>

    </member>

    <member name="F:Delta.Engine.Application.hasStartedYet">

      <summary>

            See quit

            </summary>

    </member>

    <member name="F:Delta.Engine.Application.optionalRunCode">

      <summary>

            Optional run code, that will be set in Start and called in Run.

            </summary>

    </member>

    <member name="M:Delta.Engine.Application.#ctor">

      <summary>

            Create base application. The application just provides the run

            loop, which will be started in the Start method (platform specific).

            </summary>

    </member>

    <member name="M:Delta.Engine.Application.StartExecutionLoop">

      <summary>

            Start execution loop, used internally, overwrite this one if you need

            a different way, e.g. on some platforms like iPhone we have to provide

            a different way to start the application without our own while loop,

            but using event based methods to then call the Run method.

            Note: In release mode this also will catch exception in the while

            loop. This way we can continue in the game loop without crashing

            the whole app. In debug mode this makes not so much sense, use the

            attached debugger instead to figure out what is wrong.

            </summary>

    </member>

    <member name="M:Delta.Engine.Application.Run">

      <summary>

            The run method is our main execution loop we call every single frame.

            First the graphic rendering is executed to give work to the GPU, which

            should work parallel to the CPU as much as possible each frame. Then

            we execute Time, Input and Physics because all game logic depends on

            these modules and will use their data. If we have optionalRunCode

            (usually used for unit tests) that is executed next and finally all

            the other modules are executed (scenes, game logic, etc.). Most

            calculation should happen here and all GPU rendering is collected for

            the next frame where we will render it all out at the beginning of the

            frame! The cool thing about DynamicModules is that they are all

            executed automatically for us, we only handle Graphic and Time

            specially because we want them to be executed in this very special

            way, but they are still DynamicModules and work exactly the same as

            the rest of all modules.

            </summary>

    </member>

    <member name="M:Delta.Engine.Application.Dispose">

      <summary>

            After the run loop returns, the we are done executing. Dispose main

            application modules and do some cleanup here. Dispose is based on the

            DynamicModule.Dispose, which does kill all the children modules for

            us automatically in the reverse order they were created and linked up.

            </summary>

    </member>

    <member name="M:Delta.Engine.Application.Error(System.String)">

      <summary>

            Error, will try to output the error in the console, log and as display

            a dialog if possible on this platform and in the current game state.

            See HandleUnhandledException (the usual caller) for more details.

            Note: Only used internally for heavy errors, normal application

            warnings should just be logged and fatal errors should throw an

            exception (which will be caught by HandleUnhandledException if

            nothing else catches it).

            </summary>

      <param name="message">Detailed error message</param>

      <returns>True if the error should be ignored in the future,

            false if not (application might already be aborting or the caller

            can decide to abort in this case).</returns>

    </member>

    <member name="M:Delta.Engine.Application.Error(System.String,System.Object)">

      <summary>

            Error, will try to output the error in the console, log and as display

            a dialog if possible on this platform and in the current game state.

            See HandleUnhandledException (the usual caller) for more details.

            Note: Only used internally for heavy errors, normal application

            warnings should just be logged and fatal errors should throw an

            exception (which will be caught by HandleUnhandledException if

            nothing else catches it).

            </summary>

      <param name="message">Detailed error message</param>

      <param name="exceptionObject">The exception object for more details.

            </param>

      <returns>True if the error should be ignored in the future,

            false if not (application might already be aborting or the caller

            can decide to abort in this case).</returns>

    </member>

    <member name="M:Delta.Engine.Application.ShowNoContentErrorDialog(System.String,System.String,System.Boolean,Delta.Engine.Dynamic.LoginDelegate,Delta.Engine.Dynamic.GetContentProjectsDelegate,Delta.Engine.Dynamic.GetAutocompleteProjectNamesDelegate,Delta.Engine.Dynamic.SelectContentProjectDelegate)">

      <summary>

            Show no content error dialog, which is mostly the same as

            ShowErrorDialog on most platforms. On Windows in debug mode however

            we allow grabbing content dynamically via a connect to the Content

            Server. This is asked in this several dialogs, which makes this method

            quite complicated. All data is returned via the delegates to the

            caller. If the data is invalid or the connect could not been made, the

            callbacks will return errors and this method will try again and again.

            Note: This will block the app and should only be called for serious

            content errors that prevent us from continuing (no content available).

            </summary>

      <param name="message">

            Message to display. Initially this will be a warning about not having

            content, but might also be a connection error or wrong login data.

            </param>

      <param name="username">Username to login, can be remembered</param>

      <param name="clientAlreadyConnected">Is the client already connected?

            Then we only need to select the content project, nothing more.</param>

      <param name="loginCallback">Callback that is being called when the

            user has entered his login information.</param>

      <param name="getListOfContentProjects">Get list of content projects

            for the ProjectsWindow dialog.</param>

      <param name="getAutocompleteProjectsCallback">Get follow-able projects

            when the user enters something in the project text box.</param>

      <param name="selectContentProjectCallback">And finally selecting one

            of the projects, will be checked if the user has access.</param>

      <returns>

            True if the user entered some data and the caller should try to grab

            the new content from the connected server, false if we have to quit.

            </returns>

    </member>

    <member name="M:Delta.Engine.Application.ShowLoginDialog(System.String,System.String,System.Boolean,Delta.Engine.Dynamic.LoginDelegate,Delta.Engine.Dynamic.GetContentProjectsDelegate,Delta.Engine.Dynamic.GetAutocompleteProjectNamesDelegate,Delta.Engine.Dynamic.SelectContentProjectDelegate)">

      <summary>

            Show no content error dialog, which is mostly the same as

            ShowErrorDialog on most platforms. On Windows in debug mode however

            we allow grabbing content dynamically via a connect to the Content

            Server. This is asked in this several dialogs, which makes this method

            quite complicated. All data is returned via the delegates to the

            caller. If the data is invalid or the connect could not been made, the

            callbacks will return errors and this method will try again and again.

            Note: This will block the app and should only be called for serious

            content errors that prevent us from continuing (no content available).

            </summary>

      <param name="message">

            Message to display. Initially this will be a warning about not having

            content, but might also be a connection error or wrong login data.

            </param>

      <param name="username">Username to login, can be remembered</param>

      <param name="clientAlreadyConnected">Is the client already connected?

            Then we only need to select the content project, nothing more.</param>

      <param name="loginCallback">Callback that is being called when the

            user has entered his login information.</param>

      <param name="getListOfContentProjects">Get list of content projects

            for the ProjectsWindow dialog.</param>

      <param name="getAutocompleteProjectsCallback">Get follow-able projects

            when the user enters something in the project…