You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
54 lines
2.1 KiB
54 lines
2.1 KiB
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.
|