Make Duality a Portable Class Library

[AdamsLair]

In preparation for later cross-platform ports, Duality might need to lose some dependencies:

• For user plugins to be portable, they should be a PCL.
• Since they depend on Duality, the core also needs to be a PCL.
• All direct, static dependencies need to be PCLs (OpenTK, Farseer, NVorbis)
• There is no System.Drawing. No Bitmap and Font classes!
  • Deal with Pixmap.LoadXY methods (which use Bitmaps to read image data from files)
  • Deal with Font loading (which uses system Fonts to render .ttf to a Pixmap them at runtime)
• There is no File I/O
  • Deal with anything that uses File or Directory classes. Potentially Path as well.
• There is no Serializable / NonSerialized stuff
  • Switch to a custom attribute?
• There is no Assembly.Load from file or byte[]

As an alternative, Duality could use the Bait-And-Switch method to provide a pseudo PCL layer and provide different core binaries for different platforms. If achievable, however, it would be preferable if the Duality core was an actual PCL and all platform-specifics could be moved to a plugin.

[AdamsLair]

In theory, everything except plugin loading could be moved into a platform plugin. Maybe loading an Assembly from file could be done using a delegate, which the launcher provides. Since the launcher needs to be platform-specific anyway, that could be a good place for this.

On second thought, the platform backend stuff could also be provided by the launcher itself - as an alternative to providing it via plugin. Maybe not a great idea, tying those two.

[AdamsLair]

Progress:

• Got OpenTK out of most plugins, introduced Duality equivalents for relevant classes.
• Replaced System.Serializable stuff with Duality equivalents as well.

Immediate ToDo:

• Get OpenTK out of Duality and move it into a backend plugin.
• Transform the remaining dependencies (Farseer, NVorbis) into PCLs. Should only be a matter of changing the project type, as neither really has any big dependencies.
• Get rid of System.Drawing
  • Pixmaps
  • Fonts
• Let the launcher / environment provide the Assembly.Load code
• Move File I/O into a backend plugin
• See what's still missing.

[AdamsLair]

Progress:

• Completely separated Duality from OpenTK and moved it entirely into a backend plugin. There are no more direct dependencies to OpenTK in Duality.
• Transformed the remaining dependencies Farseer and NVorbis into PCLs.

Immediate ToDo:

• Use TypeInfo rather than Type.
• Get rid of System.Drawing
  • Pixmaps
  • Remove support for loading images from file.
  • Move all image loading code into the editors Pixmap importer.
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• See what's still missing.

To verify each step and ToDo, check the .Net Portability analyzer VS extension for reference. (Edit: Maybe just create a second .csproj with the portable config until it compiles?)

[AdamsLair]

Getting rid of System.Drawing has one problem: Former Pixmap.Layer / PixelData uses Bitmap internally for compressing image data using PNG. This needs to be replaced by something else.

• Is there a C# port of libpng?
  • Edit: The PngCS lib could be an option.
  • Fork it.
  • Run a performance test for loading large images vs. System.Drawing.Bitmap
  • Strip away unnecessary functionality.
  • If not possible otherwise, provide a way to directly write to a ColorRgba array without the need for copying. Since this will be a major intrusion into a distinct library, check how much loading times really improve without copying and only do this if it makes a real difference.
• Are there Open Source C# image compression libraries that allow borrowing some code on this?

[SirePi]

Maybe DevIL might help? http://openil.sourceforge.net/

[AdamsLair]

Maybe DevIL might help? http://openil.sourceforge.net/

Unfortunately, since the overarching goal of this is portability, I can only use .Net libraries that are portable as well - written in 100% managed code and without native DllImport. DevIL would require a native library in the backend, which is not an option in this case. :(

By now, I have also asked on StackOverflow on this particular matter and it looks like that PngCs library might actually be an option.

[SirePi]

Ah, missed that part.. my bad

[AdamsLair]

Progress:

• As tested here, while PngCS is entirely portable, it is about 4-5 times slower for loading PNG files than System.Drawing.Bitmap, the culprit being DeflateStream.
• So, unless there is a replacement that significantly improves its performance, this is not an option.
  • Could create a micro abstraction ImageCodec for the internally used image compression. They all get an ID, so deserialized PixelData can choose the appropriate one. Serializing PixelData could just choose a PNG codec by priority.
  • The "Desktop" system backend provides a fast Bitmap PNG compression.
  • The core always has its internal PngCS compression as a fallback.
  • Still, it would be kind of nice if that wasn't necessary..

[AdamsLair]

Progress:

• Created a pcl_wip branch to begin with this.
• Created a dummy PCL project for the Duality core to see what's up.
• Moved Rect and MathF to the Primitives project.
• Introduced Point2 struct as a non-math int version of Vector2 and replaced System.Drawing.Point core usages with it.
• Tweaked MathF and Rect API.
• StreamWrapper classes are now PCL-compatible.
• Default Content is now loading in a PCL-compatible way, using manifest resource streams rather than a ResourceManager. It's also more concise and half-automated now.

Immediate ToDo:

• Replace CoreRes ResourceManager with an embedded / manifest resource stream variant.
  • Adjust EditorHintImage attribute, as well as its editor resolver.
  • Might be simplified to defining a manifest resource name which is searched across all Assemblies.
  • Resolving to Stream or byte[] instead of Image, so the core won't need System.Drawing for this, editor will load the Bitmap.
• Use TypeInfo rather than Type.
• Get rid of System.Drawing
  • Pixmaps
  • Remove support for loading images from file.
  • Move all image loading code into the editors Pixmap importer.
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.

[AdamsLair]

Progress:

• EditorHintImages are now loading in a PCL-compatible way.
• EditorHintCategory no longer requires a ResourceManager and is now PCL-compatible as well.
• Removed non PCL-compatible Log methods (requiring StackTrace) and introduced an alternative method based on CallerInfo attributes.
• Removed non-PCL-compatible Bitmap surrogates from cloning and serialization systems. They were unused anyway.
• Moved Bitmap extension methods to the editor.
• First experiments with TypeInfo, but didn't do anything about it yet.

Immediate ToDo:

• Use TypeInfo rather than Type.
  • MemberTypes is unavailable. Adjust ReflectionHelper implementations.
  • BindingFlags is unavailable. Remove all traces of them.
• Get rid of System.Drawing
  • Pixmaps
  • Remove support for loading images from file.
  • Move all image loading code into the editors Pixmap importer.
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.

[AdamsLair]

Progress:

• General ReflectionHelper cleanup.
• General Serializer cleanup.
• Removed MemberTypes usages from Duality core.
• Started removing BindingFlags usages from Duality core and also started replacing the old Type API with the new TypeInfo API in the process.

Immediate ToDo:

• Use TypeInfo rather than Type.
  • BindingFlags is unavailable. Remove all traces of them.
• Get rid of System.Drawing
  • Pixmaps
  • Remove support for loading images from file.
  • Move all image loading code into the editors Pixmap importer.
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.

[AdamsLair]

Progress:

• General ReflectionHelper cleanup.
• Removed all BindingFlags usages from the core.
• Changed some more spots of Type usage with TypeInfo usage. Not done yet.

Immediate ToDo:

• Use TypeInfo rather than Type.
  • FormatterServices.GetUninitializedObject is unavailable. This needs to be replaced with a more sophisticated object creation algorithm in ReflectionHelper.CreateInstanceOf in order to assure serialization and cloning to work.
  • If it's a struct, just use the Activator class for creating a default one? Investigate if there's a faster way using Expressions. Also, see here.
  • Iterate over all constructors from the one with the least number of parameters to the one with most. Provide the default value for each parameter. If all fails, try the Activator method.
  • Get ReflectionHelper.cs to the point where intellisense doesn't report errors in the PCL dummy project.
• Get rid of System.Drawing
  • Pixmaps
  • Remove support for loading images from file.
  • Move all image loading code into the editors Pixmap importer.
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.

[AdamsLair]

Progress:

• Added some unit tests for CreateInstanceOf to make sure not to screw things up.
• Moved reflection-driven object creation code / algorithm to new static ObjectCreator class, tidying up ReflectionHelper a bit more.
• Replaced FormatterServices.GetUninitializedObject with some more sophisticated code for object creation that attempts to use all available constructors (sorted from trivial to complex) until it finds one that works.
  • In 99% of all cases, the trivial constructor doesn't have parameters and works right away.
  • In a lot of the remaining cases, a constructor with parameters can be used by using default(T) on each argument.
  • If no constructor works at all, the search algorithm gives up and logs a warning, informing users about the problem.
  • In a previous commit, the algorithm would call itself recursively in order to create objects for constructor arguments, but I thought this was too "aggressive" / dangerous, so I removed it again and added the warning instead.
• The "Type to TypeInfo" stuff seems to be mostly done, but more might turn up later.

Immediate ToDo:

• Deal with MemberInfoEquals. Write unit tests and change its implementation not to use MetadataTokens, as PCL MemberInfos do not have them.
• Move ConsoleLogOutput to the launcher, also open the logfile there and pass the stream to the core.
  • Can't use plugins here, because logging needs to be up and running before doing anything complex.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Set up a "DesktopSystem" plugin project, similar to the "DefaultOpenTK" one.
• Get rid of System.Drawing
  • Pixmaps
  • Remove support for loading images from file.
  • Move all image loading code into the editors Pixmap importer.
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Added unit tests for MemberInfoEquals.
• Renamed / Moved MemberInfoEquals from ReflectionHelper to ExtMethodsMemberInfo.IsEquivalent.
• Replaced its implementation with a PCL-friendly version that doesn't rely on MetadataToken.

Immediate ToDo:

• Move ConsoleLogOutput to the launcher, also open the logfile there and pass the stream to the core.
  • Can't use plugins here, because logging needs to be up and running before doing anything complex.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Set up a "DesktopSystem" plugin project, similar to the "DefaultOpenTK" one.
• Get rid of System.Drawing
  • Pixmaps
  • Remove support for loading images from file.
  • Move all image loading code into the editors Pixmap importer.
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Moved ConsoleLogOutput to the launcher.
• Moved all log output handling (Creating logfiles) from the core to the execution environment (launcher, editor, etc.)
• Removed unused Font and FormattedText rendering methods with a System.Drawing.Bitmap as a target.
• Tweaked some Logging API things.

Immediate ToDo:

• Fix the first batch of compiler errors from the dummy PCL project, to get to the "deeper" ones and get a better overview on required changes.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Set up a "DesktopSystem" plugin project, similar to the "DefaultOpenTK" one.
• Get rid of System.Drawing
  • Pixmaps
  • Remove support for loading images from file.
  • Move all image loading code into the editors Pixmap importer.
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Introduced ImageCodec Abstraction layer.
• Removed all System.Drawing stuff from Pixmap and PixelData.
• Implemented a default System.Drawing.Bitmap-based image codec, directly in the core for now.
• Pixmap and PixelData are now PCL-compatible!

Immediate ToDo:

• Fix the first batch of compiler errors from the dummy PCL project, to get to the "deeper" ones and get a better overview on required changes.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Set up a "DotNetFramework" plugin project, similar to the "DefaultOpenTK" one.
  • Move the BitmapImageCodec into that plugin.
• Get rid of System.Drawing
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Created a DotNetFramework system backend plugin.
• Moved the BitmapImageCodec into that plugin.

Immediate ToDo:

• Fix the first batch of compiler errors from the dummy PCL project, to get to the "deeper" ones and get a better overview on required changes.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Get rid of System.Drawing
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
  • Roadmap:
    1. Let Fonts save their glyph and pixel data by default. Don't re-generate on load.
    2. Save the default Fonts as Resources and directly embed them in the core, rather than generating them on startup.
    3. Introduce a Font API for specifying their internal pixel and glyph data from the outside.
    4. Move the rendering code into a set of extension methods for Fonts.
    5. Adjust the FontPropertyEditor to update its font properly, get rid of "NeedsReload" mechanic and make properties that require rendering the font get-only in the core.
    6. Move those extension methods to the editor.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Fonts no longer re-generate their pixel data when loading, but directly use pre-rendered meta- and pixel data, which is also saved.
• The XmlSerializer was upgraded to allow writing primitive value type arrays as comma-separated lists, which significantly shrinks Font Resources in XML, as they contain a lot of int[] of kerning sample data.

Immediate ToDo:

• Fix the first batch of compiler errors from the dummy PCL project, to get to the "deeper" ones and get a better overview on required changes.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Get rid of System.Drawing
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
  • Roadmap:
    1. Save the default Fonts as Resources and directly embed them in the core, rather than generating them on startup.
    2. Introduce a Font API for specifying their internal pixel and glyph data from the outside.
    3. Move the rendering code into a set of extension methods for Fonts.
    4. Adjust the FontPropertyEditor to update its font properly, get rid of "NeedsReload" mechanic and make properties that require rendering the font get-only in the core.
    5. Move those extension methods to the editor.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Default Fonts no longer render on startup using system Fonts, but are instead loaded as complete Resources from an embedded data stream.
• Using system Fonts is no longer supported. All Fonts need to be based on embedded TrueType fonts, i.e. need to be imported by doing a dragdrop operation using a .ttf file.

Immediate ToDo:

• Fix the first batch of compiler errors from the dummy PCL project, to get to the "deeper" ones and get a better overview on required changes.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Get rid of System.Drawing
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
  • Roadmap:
    1. Introduce a Font API for specifying their internal pixel and glyph data from the outside.
    2. Move the rendering code into a set of extension methods for Fonts.
    3. Adjust the FontPropertyEditor to update its font properly, get rid of "NeedsReload" mechanic and make properties that require rendering the font get-only in the core.
    4. Move those extension methods to the editor.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Added Font API for specifying glyph data from the outside and refactored glyph rendering method.
• Fonts now support arbitrary characters (Core only, no Editor support yet).

Immediate ToDo:

• Fix the first batch of compiler errors from the dummy PCL project, to get to the "deeper" ones and get a better overview on required changes.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Get rid of System.Drawing
  • Fonts
  • Turn them into full Bitmap Fonts, carrying their binary source font and config with them for editor support, but also carrying an internal rendered Pixmap that will be loaded at runtime.
  • Configuring a Font can only be done in the editor. Make those properties read-only with an editor override hint.
  • The editors Font importer should carry all the rendering logic. The core Font should only load Fonts from a prepared Pixmap and metadata.
  • Roadmap:
    1. Move the rendering code into a set of extension methods for Fonts.
    2. Adjust the FontPropertyEditor to update its font properly, get rid of "NeedsReload" mechanic and make properties that require rendering the font get-only in the core.
    3. Move those extension methods to the editor.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Moved Font glyph rendering code to the editor using an extension method.
• System.Drawing is no longer a dependency of the Duality core.

Immediate ToDo:

• Test and fix all official sample packages for Font Resources that need to be updated.
  • DualStickSpaceShooter
  • Steering
  • DynamicLighting
• Fix the first batch of compiler errors from the dummy PCL project, to get to the "deeper" ones and get a better overview on required changes.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Merged the pcl_wip branch back into master due to the increasingly high amount of bugfixes and tweaks in there. Also, the branch has reached a quite usable state with the only WiP part being a single experimental project file for the core.
• Tested and fixed Steering, DualStickSpaceShooter and DynamicLighting plugins and samples.

Immediate ToDo:

• Fix the first batch of compiler errors from the dummy PCL project, to get to the "deeper" ones and get a better overview on required changes.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Move File I/O into a backend plugin.
• Let the launcher / environment provide the Assembly.Load code, and a list of available plugins, because neither I/O nor Assembly.Load is available before loading the backend plugins.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Added an IPluginLoader abstraction, which is used by the (portable) core to pull in all plugins, including the actual backend. An implementation of this is provided via DualityApp.Init.
• Moved some of the plugin loading code out of the core and into the default IPluginLoader implementation.
• Fixed the first batch of compiler errors. Now getting the real ones when compiling the PCL version of the core.

Immediate ToDo:

• Create a Path replacement class (PathOp?) and move it to a Duality.IO namespace, together with those streaming classes and other IO-related stuff.
  • Only provide path string functionality that can be implemented without any file system access or knowledge.
  • Use it instead of System.IO.Path wherever possible.
  • Neither this class nor any of its functionality should be platform-dependent. Just define a single path format that Duality uses and let the backend handle translating it to the system's representation when queried.
• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Add file system access to the ISystemBackend API.
• Fix the remaining compile errors.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Introduced new static PathStr class to Duality.IO that mirrors System.IO.Path functionality in a (mostly) platform-agnostic way. Used it instead of Path in the Duality core. Added thorough unit tests for it.
• Moved some editor functionality out of the Duality core to increase PCL compatibility.
• AbstractShader and AudioData no longer expose (uncritical) file path IO functionality to comply with PCL subset.

Immediate ToDo:

• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Add file system access to the ISystemBackend API. Consider wrapping it in a separate IFileSystem interface, so ISystemBackend doesn't enter godmode.
• Fix the Type / TypeInfo conversion errors.
  • Constantly casting back and forth is not a good way. Consider re-defining parts of the Duality API to be based on TypeInfo instead of Type, as most operations require deep knowledge anyway.
  • Serialization and Cloning will deal primarily in TypeInfo. Their surrogate and explicit API needs to be adjusted.
  • ObjectCreator needs to be adjusted.
  • Parts of ReflectionHelper should be considered for adjustment.
• Fix the remaining compile errors.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Renamed PathStr to PathOp due to future API considerations.
• Fixed various Type / TypeInfo compiler errors.

Immediate ToDo:

• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Add file system access to the ISystemBackend API. Consider wrapping it in a separate IFileSystem interface, so ISystemBackend doesn't enter godmode.
• Fix the Type / TypeInfo conversion errors.
  • Constantly casting back and forth is not a good way. Consider re-defining parts of the Duality API to be based on TypeInfo instead of Type, as most operations require deep knowledge anyway.
  • Serialization and Cloning will deal primarily in TypeInfo.
  • Parts of ReflectionHelper should be considered for adjustment.
• Fix the remaining compile errors.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Fixed most remaining Type / TypeInfo compiler errors.

Immediate ToDo:

• Set up an ISystemBackend API. Leave it empty first and gradually add things.
• Add file system access to the ISystemBackend API. Consider wrapping it in a separate IFileSystem interface, so ISystemBackend doesn't enter godmode.
• Fix the remaining compile errors.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• Added ISystemBackend and IFileSystem interfaces, and an implementation for both in the DotNetFramework backend plugin. There is also a dummy implementation directly in the core, which acts as a fallback.
• Added static DirectoryOp and FileOp classes, which internally use the currently active ISystemBackend for file system access.
• Replaced all usages of System.IO file system access in the core with their new Duality equivalents.

Immediate ToDo:

• Fix the remaining compile errors.
• Adjust the default core plugins to be PCLs.
• Adjust the default core plugin template to be a PCL, and also see if the editor one requires changes.

[AdamsLair]

Progress:

• The Duality core and all core plugins are now PCLs.
• The default core plugin template in the editor is now a PCL.

Closing this.