commit fb76258e410c1703bed59dd814d4fbee26c23c45
Author: H. Utku Maden <utkumaden@hotmail.com>
Date:   Wed Dec 11 20:56:39 2024 +0300

    Initial commit of the Dashboard rewrite.

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..668d5eb
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,11 @@
+bin/
+obj/
+/packages/
+riderModule.iml
+/_ReSharper.Caches/
+.idea
+.vs
+.vscode
+nuget_repo
+**/out
+**/runtimes
\ No newline at end of file
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..4bc8f88
--- /dev/null
+++ b/README.md
@@ -0,0 +1,77 @@
+Dashboard
+=========
+Dashboard is a modular immediate rendering and UI toolkit that is intended to
+develop modular graphics applications in .NET. The library comes in layers,
+with no tight coupling between each stage. It makes Dashboard an excellent
+library to embed into your OpenGL, Vulkan or DirectX applications as a UI or
+HUD rendering toolkit.
+
+### Scope
+Generally speaking, this library is not going to replace a professional UI
+toolkit for most .NET programmers. The 1st and 3rd party frameworks available
+are already excellent for most people. As such, the library does not follow
+any UI development discipline, like MVVM. This is supposed to be easy to
+integrate, customize and deliver. You are free to pick and choose which
+components you like, hate, include and exclude.
+
+### Availability
+This library is currently under development and is not intended for end users
+until further notice. Things are subject to change without notice, or
+deprecation. You have been warned. And we do not talk about the original
+QUIK/Dashboard code base. It's a mess.
+
+Dashboard.Drawing - The Immediate Rendering System
+----------------------------------------------------
+The Dashboard immediate rendering system provides a framework for issuing
+rendering commands independtly of the graphics backend present. In order
+to draw anything, you must issue enqueue drawing commands into a queue.
+This queue is later consumed by the graphics backend in order to reach a
+final image.
+
+The main benefit of the graphics queue is that you can write your graphics calls
+once and expect the same results, at least approximately. As an advanced
+example, you could write a DrawQueue to PostScript transpiler, which can be
+consumed by a tool like ghostscript to conver it into a PDF file. And with the
+same DrawQueue contents, you can also render the same thing with OpenGL, or your
+custom software renderer.
+
+Each draw queue is going to contain the following main components:
+
+- The image bounding box.
+- The list of extensions required to draw the image.
+- The list of resources referenced by the draw queue.
+- The list of commands that have been used in the draw queue.
+- The stream of bytes that make up the draw queue.
+
+This creates an extremely de/serializable command queue that can be generated
+and interpreted with ease.
+
+### Coordinate Systems and Measures.
+
+The coordinate system is assumed to be left handed and with a top-left origin.
+The length unit is device independent points (pt). Without accounting for high
+pixel density displays, 1pt is 96/72 pixels (~1.3). The angle unit is degrees.
+These set of conventions set herein follow the conventions set by traditional
+computer aided graphics design. Following these conventions is entirely
+optional, if and when you see fit.
+
+### Extensions
+A drawing extension defines a set of features and commands that need to be
+understood to generate the image correctly. Extensions are simple strings that
+are valid ISO C99 identifiers. This means that they must only contain
+alphanumeric characters, or an underscore, and must not begin with a number.
+
+The prefix `DB_` is reserved for the Dashboard library itself. Please refrain
+from making an extension with this prefix. We recommend naming your extensions
+with an underscore case name. Also please consider including a vendor prefix,
+such as our own `DB_`. If you do not wish to do so, please consider your vendor
+prefix as `X_`.
+
+## Special Thanks
+I would like to thank the following people, in no particular order, for their
+contributions in this endevour:
+
+- Callum McGing for BlurgText, the text rendering library.
+- "BoyBayKiller", for providing valuable feedback for the libraries that spun off of Dashboard.
+- "Froil" for coining the name Dashboard, fitting with the suite of ReFuel libraries, after the inevitable issues that the name QUIK has caused.
+