bringing docs up to date

This commit is contained in:
2020-02-13 17:14:29 -08:00
parent 659cd98a1f
commit fcfa40e335
112 changed files with 869 additions and 1837 deletions

View File

@@ -12,7 +12,6 @@ The Canvas needs to package certain buffers along with their metadata. These tak
All buffers will have a coupled handle type stored in the [[/src/canvas/mod.rs|canvas/mod.rs]] and a reference to that handle
===== CanvasImage =====

View File

@@ -10,46 +10,20 @@ Creation-Date: 2020-02-03T23:57:15-08:00
Canvas frame is at it's core, an accumulator of meta data to draw to the screen.
At the moment it is split up into these groups:
In reality it is a fairly inneficient accumulator of `enum VertexType`s. This enum is the only real way I found to preserve type safety when passing dynamic amounts of differently typed data
* Colored items like non-textured sprites are just a list of triangles, simple vertices.
@todo
* Textured are grouped by their texture handle. Currently implemented as a list of lists of vertices. I don't think the vertices need to be grouped by sprite as long as they are triangle lists with texture coords included in the definition
* Images are just the same as Textured
* Text is a simple Font->Glyph lookup. XY coords of the font and the ASCII code
{{{code: lang="rust" linenumbers="True"
colored_drawables: Vec<RuntimeVertexDef>
textured_drawables: HashMap<Arc<CanvasTextureHandle>, Vec<Vec<RuntimeVertexDef>>>
image_drawables: HashMap<Arc<CanvasImageHandle>, Vec<Vec<RuntimeVertexDef>>>
text_drawables: HashMap<Arc<CanvasFontHandle>, Vec<GlyphInstance>>
}}}
This enum consists of (currently) :
* TextureType(Vec<TextureVertex2D>, Arc<CanvasTextureHandle>),
* ImageType(Vec<ImageVertex2D>, Arc<CanvasImageHandle>)
* ColorType(Vec<ColorVertex2D>)
* ThreeDType(Vec<Vertex3D>)
Cool enough, we can enforce the handle type as well using this
===== Future =====
I like this immediate interface for this simple style of UI and drawing.
I like this immediate interface for this simple style of UI and drawing. Unless I need some other sort of data or data which has links to other data, I don't see any interface being much better.
@todo finish this
Now. The CanvasFrame is closely coupled with the Drawable trait, the object which allows CanvasFrame to ingest all drawable object on a single interface
Drawable needs a few things:
Handle to the Texture or Image it is using
Vertices describing it
(vertices will be character data for text)
Instances?
The handle is queiried and then turned into a descriptor set in the draw_commands.
* What if I pass using function params? But then how do I store???
==== Problem ====
I need to store vectors of multiple unequal types in a vec
vec<vec<T>>
Why can't I pass in
--------------------
@@ -57,7 +31,10 @@ Why can't I pass in
===== Data =====
**Borrowed:**
[[VKProcessor::CanvasContainerClasses|CanvasTextureHandle
CanvasImageHandle
CanvasFontHandle]]
**Owns:**
--------------------

View File

@@ -7,7 +7,7 @@ Creation-Date: 2020-02-03T23:42:33-08:00
[[/doc/sfml_rust/canvas/canvas_buffer/struct.CanvasImage.html|Documentation]]
===== Details =====
Container class for
Container class for an ImmutableImage object
**<notes>**
@@ -21,10 +21,3 @@ Container class for
**Owns:**
--------------------

View File

@@ -21,9 +21,7 @@ Creation-Date: 2020-02-03T23:30:41-08:00
The class then interacts with these stored items by taking and executing a list of operations to perform on them.
CanvasFrame
Going to need some interface for getting vertices.
Some interface for getting the texture or image
[[VKProcessor::CanvasFrame|CanvasFrame]]
--------------------
@@ -37,12 +35,9 @@ Creation-Date: 2020-02-03T23:30:41-08:00
**Owns:**
render_pass
[[CanvasImage]]
[[VKProcessor:CanvasTexture]]
[[VKProcessor:CanvasTexture|CanvasTexture]]
[[CanvasFont]]
CompiledGraphicsPipeline
colored_vertex_buffer
image_vertex_buffer
text_instances
[[CompiledGraphicsPipeline]]
--------------------

View File

@@ -0,0 +1,11 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2020-02-12T23:22:51-08:00
====== CompiledGraphicsPipeline ======
Unfortunately we have to explicitly provide the type to the graphics pipeline if we don't want to fall out into the