next »

[InfiniteStateMachine]

Yeah I dont remember GCC being that bad for me but I rarely have reason to use it outside of personal interest.

[MorleyDev]

Build time comparisons between GCC and VS can get odd, Visual C++ seems faster at 'straight forward' C++, and to fall down horribly when any kind of reasonably complicated metaprogramming gets involved (especially recursion with variadics).

I wrote a unit testing and assertion library in C++ (to see how much easier such things would be to build when you use C++11 to get rid of those hideous preprocessor define hacks old libraries used), and in drone.io it builds itself and its unit tests from scratch in 1 minute in GCC, but takes 5 minutes in Visual Studio with appveyor.

And then when I used it for an actual project, builds in gcc of the unit tests for that project took like a minute tops in GCC on my machine, but 11 minutes when invoking visual studio.

[oahda]

How did you get such long build times for a library like that on any compiler?

My game in its current state has a bunch of shit plus its engine and together they compile in less than a minute on LLVM so far (including some libraries I compile myself, like AngelScript).

[Schrompf]

I build myself and link statically: AngelScript, freetype, TinyXML, GLFW, AOIS (now SNIIS), curl. Plus own framework. But as I said: it's mostly because I rely heavily on Precompiled Headers, and GCC does not seem to be make good use of it.

[MorleyDev]

How did you get such long build times for a library like that on any compiler?

For my post? Well, my bets are how all that was once done with heavy macros is now done with heavy templating (and variadic templates, and recursive) and makes extensive usage of SFINAE. And then this is hidden behind a couple of variadic recursive macros. Visual Studio seems to hate all of those.

Plus I favour many small classes where possible, so the initial build has to compile a lot of cpp files that only declare one or two functions (This does reduce the time of subsequent builds significantly, but increases the time of build from clean).

[InfiniteStateMachine]

How did you get such long build times for a library like that on any compiler?

My game in its current state has a bunch of shit plus its engine and together they compile in less than a minute on LLVM so far (including some libraries I compile myself, like AngelScript).

I've definitely worked on a codebase or two where a cold compile could take 30 mins :| It's absolutely huge though. Typically a warm compile is very quick though.


I hope some day another systems language picks up steam because compile times in C/C++ are archaic


 

[Layl]

I hope some day another systems language picks up steam because compile times in C/C++ are archaic

Rust is promising, though doesn't support incremental compiles at all currently, and build times with optimization can be gigantic.

[InfiniteStateMachine]

yeah rust and D are the two languages I have my eye on. I wish I had more time to spend with them.

[indie11]

I am a bit confused here, need some feedback.

The speed of an Object depends on how fast a key is pressed. This means that the speed of that object will change almost every frame. Do I still multiply that speed with Delta Time to make it frame rate independent?

[Schrompf]

For starters? Yes. I'm not really sure what you mean by "how fast a key is pressed", but generally you could say that as long as a key is pressed, a linear acceleration affects the player. So movement of the player is basic vector math.

vel += accel * deltatime;
pos += v * deltatime + accel/2 * deltatime^2;

The first part of the pos formula is the "frame rate independent" part of linear velocity. The latter part is the added effect of a linear acceleration. You won't notice a difference for slow accelerations, though - its numbers are very small for most cases.

[InfiniteStateMachine]

Working on a codebase that goes out to about 5 different c++ compilers. Managed to make an coding error that caused clang and another compiler fail with a linkage error. It was relating to constructing a param to a function inside the param brackets. Once I just brought it out as a local and passed it in it passed on clang.

Still not entirely sure about the cause. It's possible our clang is running at a higher warning-as-error level than the other compilers but if that were true it wouldn't be a linker error.

[indie11]

For starters? Yes. I'm not really sure what you mean by "how fast a key is pressed", but generally you could say that as long as a key is pressed, a linear acceleration affects the player. So movement of the player is basic vector math.

vel += accel * deltatime;
pos += v * deltatime + accel/2 * deltatime^2;

The first part of the pos formula is the "frame rate independent" part of linear velocity. The latter part is the added effect of a linear acceleration. You won't notice a difference for slow accelerations, though - its numbers are very small for most cases.

  this is what I am currently doing... the speed of this button press is applied on the objects so they can move

[Boreal]

For starters? Yes. I'm not really sure what you mean by "how fast a key is pressed", but generally you could say that as long as a key is pressed, a linear acceleration affects the player. So movement of the player is basic vector math.

vel += accel * deltatime;
pos += v * deltatime + accel/2 * deltatime^2;

The first part of the pos formula is the "frame rate independent" part of linear velocity. The latter part is the added effect of a linear acceleration. You won't notice a difference for slow accelerations, though - its numbers are very small for most cases.

It's a mistake to incorporate acceleration into the position integration.  It should simply be:

Code:

x += v * dt;
v += a * dt;

for Euler integration (which I don't recommend, but that's outside the scope of this).  Doing it your way, you're integrating acceleration twice.  The 0.5a^2 term comes from the indefinite integration of a.

[Garthy]

Assuming the problem being solved is that of applying constant acceleration over a time period, Schrompf has provided the correct formulae:

vel += accel * deltatime;
pos += v * deltatime + accel/2 * deltatime^2;

This is correct.

Further confirmation:

- http://en.wikipedia.org/wiki/Equations_of_motion (see "Uniform acceleration").
- http://www.google.com.au/?q=position+given+constant+acceleration

[Boreal]

I'll go from first principles to prove my point.  Definite integration is signified by integral(f, a, b) where f is the function to integrate and a and b are the lower and upper bounds.

The differential equations we are working with are simple.

a = dv/dt
v = dx/dt

Given a changing acceleration a(t), we want to find the changing position x(t).

dx = v*dt
x(t) = x(0) + integral(v, 0, t)

But what is the changing velocity v(t)?

dv = a*dt
v(t) = v(0) + integral(a, 0, t)

If a(t) was a constant a, we could do analytical integration and end up with a couple of familiar equations of motion.

v(t) = v(0) + a*t
x(t) = x(0) + v(0)*t + 0.5*a*t^2

However, in a game an object's acceleration is often dependent on too many factors to analytically model, so we use numerical integration instead (Euler method for illustration).

v(t+dt) = v(t) + a(t)*dt
x(t+dt) = x(t) + v(t)*dt

This easily translates into the simple pseudocode I posted earlier.

Code:

x += v * dt;
v += a * dt;

Adding in an extra (improper) integration of velocity as you have is not terribly bad with a small timestep, but especially as you start using more accurate integrators like midpoint or RK4 it is mathematically incorrect.

[Garthy]

However, in a game an object's acceleration is often dependent on too many factors to analytically model...

I'm fairly confident that this argument does not invalidate the formulae provided.

The formulae are well-established and correct with multiple sources confirming. If my appeal to authority is insufficient, a single counter-example could be provided to disprove the formuale. I do not think there is one though. Saying that the formulae are incorrect is, well, incorrect. Saying that games are complex is irrelevant to the correctness of the equations provided.

But perhaps what you mean to say is: For games (or perhaps the particular application discussed here), there is a better approach than assuming constant acceleration? That's reasonable to say. It would then come down to demonstrating why an alternate approach is superior.

I am curious as to the advantages of the approach you are suggesting.

EDIT: Missed an "e".

[GuiltyGreens]

Boreal isn't saying that the links you provided are incorrect. You and indie11 are incorrectly applying the formula.

It's a mistake to incorporate acceleration into the position integration.  It should simply be:

Code:

x += v * dt;
v += a * dt;

for Euler integration (which I don't recommend, but that's outside the scope of this). Doing it your way, you're integrating acceleration twice.  The 0.5a^2 term comes from the indefinite integration of a.

...

Adding in an extra (improper) integration of velocity as you have is not terribly bad with a small timestep, but especially as you start using more accurate integrators like midpoint or RK4 it is mathematically incorrect.

The wiki link shows that Eq1 and Eq2:

v = v_o + at
x = x_o + v_ot + .5at², where

x_o is the initial position
v_o is the initial velocity
v is the final velocity
x is the final position

Also note that v_o appears in both equations. Eq2 accounts for the change in velocity (.5at²) which is why it does not use the final velocity, v. It would be incorrect to do so again.

Edit:

Oh, I see.

For starters? Yes. I'm not really sure what you mean by "how fast a key is pressed", but generally you could say that as long as a key is pressed, a linear acceleration affects the player. So movement of the player is basic vector math.

vel += accel * deltatime;
pos += v * deltatime + accel/2 * deltatime^2;

The first part of the pos formula is the "frame rate independent" part of linear velocity. The latter part is the added effect of a linear acceleration. You won't notice a difference for slow accelerations, though - its numbers are very small for most cases.

I mistook vel for v. But, v is the initial velocity and vel is still the final velocity.

[Garthy]

You and indie11 are incorrectly applying the formula.

Me? I believe my application of the formulae is entirely correct.

I mistook vel for v. But, v is the initial velocity and vel is still the final velocity.

Yeah, it's a touch confusing as expressed. "v" is used to mean "v(0)". The form used in your post is the most clear IMHO:

v = v_o + at
x = x_o + v_ot + .5at², where

[Schrompf]

Didn't want to create confusion. I realize the code is wrong when written directly like this.

Given current position p₀, velocity v₀ and a constant acceleration a = a₀ = a₁, the per-frame code would look like

v₁ = v₀ + dt * a;
p₁ = p₀ + dt * v₀ + 0.5 * a * dt²;

Which is what Garthy and BeTheLeaf already wrote. Now stop being helpful and return to being grumpy :-)

[Boreal]

I've personally never seen the twice-integrated acceleration term as part of an Euler integration, but I did a simple test in MATLAB and it does make it match the analytical solution perfectly.  So that would be the error term of the Euler integration for those simple equations of motion.

But if you are using a different integrator like the midpoint method, Verlet, or RK4 it is incorrect to include that error term.  It is also not really correct to include it unless a constant acceleration due to gravity is the only acceleration you are modelling.