Trac3r-rust/notes/MakingAnActualThing.txt

Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2020-08-06T21:51:48-07:00

====== MakingAnActualThing ======
Created Thursday 06 August 2020

So, I need to figure out how to determine which objects will :
	* Be rendered
	* Be notified
	* Get batched
	* And initialized


Looks like it could possibly be specs...

Sprites currently are just a container for the meta-information needed in order to return a VertexTypeContainer. 

{{{code: lang="rust" linenumbers="True"
pub enum VertexTypeContainer {
    TextureType(Vec<TextureVertex3D>, Arc<CanvasTextureHandle>),
    ImageType(Vec<ImageVertex3D>, Arc<CanvasImageHandle>),
    ColorType(Vec<ColorVertex3D>),
    ThreeDType(Vec<Vertex3D>),
    TextType(Vec<ColorVertex3D>),
}
}}}


So for a sprite, which is a generic texture and position/size combo
Images are similar, but instead of a "sprite" I made a computsprite because that's the only thing that uses them.

Now if I had to shove these into a component / a set of components... I could have a component of the vertex type even?



===== Sep 2020 =====

Lets think about this for a minute...

* We have components which are purely data...
	* But can also have structs that impl functionality
	* The data can be contained within traits. But it has to do all IO through the trait interface. ALL
		* Problem, for example I have primitives like textured sprites, and also complex widgets which also have additional IO they they need. Like text input or buttons. I suppose This could all be made message based. So when the text input receives a focus, and then key presses it would update. When the enter key is pressed it could create a customer event for which another component is the listener... 
		* Maybe this is the way to go... Have some generic structure that has a render(params), notify(event), update(delta) -> VEvent
		* So if I had a textbox sprite it could notify(key events) render 
* We can split up components in order to have sharable sets of data for shared functionality. e.g rendering

[[paste]]



So that article more or less talked about what I was thinking with the ECS. But they didn't really go into the separation of components.