HandmadeHero/docs/Day 043.md

38 lines
1.8 KiB
Markdown
Raw Permalink Normal View History

2023-10-28 14:10:30 -07:00
# Day 43
My little experiment with making a types of vectors for the physical interpreations
used when doing basic 2D physics actually produced some interesting results.
I made types for position, distance, direction, velocity, and acceleration so far.
Right now at the level of complexity our "physics" code is operating at they feel more
"in the way" than actually something helping us with intuition or productivity.
However, when Casey explained that delta-time is essentially applied to intergrate to "lower" frame of time;
I realized that you could technically compress the application of delta time when you apply acceleration to velocity, velocity to position, etc.
```cpp
inline Pos2_f32& operator+=( Pos2_f32& pos, Vel2_f32 const vel )
{
pos.x += vel.x * engine::get_context()->delta_time;
pos.y += vel.y * engine::get_context()->delta_time;
return pos;
}
inline Vel2_f32& operator+=( Vel2_f32& vel, Accel2_f32 const accel )
{
vel.x += accel.x * engine::get_context()->delta_time;
vel.y += accel.y * engine::get_context()->delta_time;
return vel;
}
```
The of this encapsulation is that the operators need to have awareness of the delta time from some context.
So in a sense your enforcing that there is an implicit delta universally.
For now I'm making that context just the engine's known delta from the platform's frametime.
This most likely would get more complex if there are multiple physics threads or substepping is involved.
I'm also not sure how much performance is also sacrificed with this approach since an indirection was introduced with having to grab the context.
If there is a issue with performance the user can always at worst case downcast to regular vectors and just do the math directly...
For now I'll continue to use this approach and see how it goes.