network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 4 months |
| seen | Jan 21 at 13:35 | |
| stats | profile views | 0 |
|
Jan 27 |
awarded | Tumbleweed |
|
Jan 20 |
asked | Using boost function to wrap execution of a boost signals2 signal |
|
Jan 17 |
awarded | Editor |
|
Jan 17 |
revised |
Handling movement using an Entity Component-based System Architecture added 818 characters in body |
|
Jan 17 |
comment |
Handling movement using an Entity Component-based System Architecture In your design, I'm guessing that the way you prevent the cyclic notification of component changes is by applying some force or movement vector/velocity to an entity. This is handled by the physics step and reset to zero each frame. All the physics step does is post collision check & motion change, updates the transforms raw position. The renderables in this case can listen for transform raw position changes and update accordingly. That all makes sense until you consider teleports. Then how would one differ between a physics update to transform and an outside user teleporting? |
|
Jan 17 |
comment |
Handling movement using an Entity Component-based System Architecture How are you preventing cyclic updates from happening, particularly where Transform's change updates the physical representation which yields an update which gets replicated back to Transform from Physics. This would appear to restart the process over again if one isn't careful. |
|
Jan 17 |
awarded | Student |
|
Jan 17 |
asked | Handling movement using an Entity Component-based System Architecture |
