-
|
I'm a beginner to bevy but I've previously been doing low level optimization tricks and I was just wondering how exactly this example component is stored in memory: #[derive(Component)]
struct Player {
position: Position,
id: u32,
}
#[derive(Component)]
struct Position {
x: f32,
y: f32,
}Does the underlying memory for
which one is the reality currently? does bevy have
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
Underlying storage (if using tables) is basically a vector per component (and archetype). Not sure which option to select since
doesn't fit with the example (Player is a component not a bundle) |
Beta Was this translation helpful? Give feedback.
-
|
The answer is a) The fact that However:
This is not correct. If you insert a #[derive(Bundle)] // <-- not Component!
struct PosVel {
position: Position,
velocity: Velocity,
}The layout is per component: each component gets its own contiguous storage. But fields of components are not components themselves, so this doesn't recurse. |
Beta Was this translation helpful? Give feedback.
The answer is a)
The fact that
PositionimplementsComponentdoes nothing here. In other words, the entity you spawned does not have thePositioncomponent. It's just a field.However:
This is not correct. If you insert a
(Position, Velocity)then the layout will look like&[Position], &[Velocity]. Similarly if you insert an instance of the followingPosVeltype:The layout is per component: each component gets its own contiguous storage. But fields of components are not components themselves, so this doesn't recurse.