-
Sorry if this post is a bit vague, it has been very difficult to wrap my head around everything involved.
For starters:
Language - VB.NET...yes, I already know -_-
SFML - Posting these questions here because the graphics engine plays a key part in my maths.
Farseer - Unable to locate examples that will translate into vb.net
Box2d - I found 1 C# example that I was able to get translated, but am unable to grasp how to set the objects sizes and positions...let's pretend that I don't program as a 9-5, and/or am an idiot.
Okay, with that out of the way I have been transitioning a top down game engine to be able to support 2D side-scrolling. To test I have been simply trying to get a ball to have visually accurate physics in a testbed application. It didn't take very long to determine that I would need to incorporate a physics engine for the simple purpose of providing (any) objects realistic physics...and since I have been unable to locate a solid example in vb.net, and trying to get the above engines to work properly is beyond the scope of my understanding, I am simplifying things and building my own engine.
Change in Time, or Delta Time, is one thing that has come up in just about every physics equation that I would have to use to calculate falling/collision/velocity. The way I am using SFML in my application has a large effect on the time that I need to calculate:
Private Sub InitializeEngine()
' Request a 24-bits depth bufer when creating the window.
Dim contextSettings As New ContextSettings()
contextSettings.DepthBits = 24
' Create main window.
_testbedWindow = New RenderWindow(New VideoMode(800, 600), "SFML Graphic Controls Testbed Application.", Styles.Default, contextSettings)
_testbedWindow.SetVerticalSyncEnabled(True)
_testbedWindow.SetFramerateLimit(60)
End Sub
I understand what SetFramerateLimit does, but when it is turned off it seems pointless since SetVerticalSyncEnabled keeps my FPS around ~60. However, just found out that is most likely due to the refresh rate of my monitor, and someone with a 75hertz refresh rate would have a higher FPS without the limit. Perfect, and I understand it...
Now in my game loop I am calling this every loop:
' Reset to keep all timers in sync.
_currentTick = Environment.TickCount
' Counts time every loop, then updates the FPS every second.
If _currentTick - _timeCount >= 1000 Then
_fps = _fpsCount
_fpsCount = 0
_timeCount = _currentTick
Else
_fpsCount += 1
End If
Great...every loop add 1 to the _fpsCount until it reaches 1000 ticks, then update my _fps value that will display on my screen...Check!
In order to achieve realistic physics, I have to get the Change in Time between each game loop. Since I am already returning the Environment.TickCount every loop, what is the most practical, and most accurate, method to produce the time between the frames? I could have a Delta_Time variable setup, but I honestly have no clue using SFML the way currently am to return a value to apply to it, that can be applied to the physics equations I have found with my google-foo.
Please not I'm not looking for code, just the logic behind how this is supposed to work properly. If there is anything that I have overlooked, please let me know.
-
Maybe this will help Fix Your Timestep! (http://gafferongames.com/game-physics/fix-your-timestep/).
-
Maybe this will help Fix Your Timestep! (http://gafferongames.com/game-physics/fix-your-timestep/).
I have that exact document up in my browser right now LOL
But I was unclear how applicable it would be considering how I can set the max FPS, and the Vsync, both have an effect on the speed of the game. I did not know if other people use this, or a different method using SFML to correctly adjust TimeStep in their games.
-
Well for one, you don't want both a framerate limit and Vsync.
Two, having a fixed timestep allows for your game to run flexibly, while more-or-less playing the same on different quality hardware. Lower FPS on low-end machines, and higher FPS on high-end machines. But, due to the fixed timestep, the game will still run as desired (potentially except for machines below your minimum required specs).
-
Well for one, you don't want both a framerate limit and Vsync.
Two, having a fixed timestep allows for your game to run flexibly, while more-or-less playing the same on different quality hardware. Lower FPS on low-end machines, and higher FPS on high-end machines. But, due to the fixed timestep, the game will still run as desired (potentially except for machines below your minimum required specs).
Okay, would it be advised to turn off the vsync and just have a max FPS set?
-
Okay, would it be advised to turn off the vsync and just have a max FPS set?
This is subject to opinion and taste.
The guy who wrote Fix Your Timestep says somewhere that everyone should just use vertical sync. This, however, has a few drawbacks. The main one, of course, is that vertical sync is dependant on the graphics driver. SFML simply requests that it should be on (or off) and the driver decides whether or not it should listen. Most drivers have options to turn on, off, or let the application decide. If this is not set to letting the application decide, there's nothing the application can do.
Limiting the frame rate also has its drawbacks, of course. The actual length of time for each frame is not consistent so framerates can still fluxuate. Limiting the frame rate is useful to avoid hogging the CPU when it's not actually needed; this, for one, can help reduce the power consumption, which is something to consider if you're building for battery-powered devices. However, the frame rate just being limited doesn't help with the possibility of visual "tearing", which can only really be fixed properly by vertical synchronisation.
So, frame rate limiting is done by the program and vertical sync is asked to be done by the graphics driver. You can use either or neither but, whatever happens, never use both.
-
The option I'm partial towards is letting the player choose. Have a V-sync option, and a frame rate limit option. I've seen several AAA games do this. So, by default, for example, you simply have neither enabled (or whatever you think is best). Then players can choose as they like.
Just make sure to make them mutually-exclusive!
-
Thanks guys!
I decided to change getting the time from the Environmental.TickCount to using SFML's clock class. Using this I am looping through until the time between passes hits an interval amount (16ms - for 60hz; 20ms - for 50hz), so I can have either fps limit or vsync on, or neither and still produce a relative rate to pass through for DeltaTime (16ms).
I'm sending 1/dt through and getting 0.0625ms consistently, which now gives me something to work with to calculate a falling object and implementing gravity. However, I am not quite understanding the values for the monitor refresh rates (16 or 20), and why they seem to be arbitrary values.
'// 16 for 60hz; 20 for 50hz
interval As Double = 16
_previousTime = _currentTime
Do
_currentTime = clk.ElapsedTime.AsMilliseconds()
Loop While (_currentTime - _previousTime) < interval
_elapsedTime = _currentTime - _previousTime
_deltaTime = (1 / _elapsedTime)
While I have no idea why the specific interval value, I got the idea for looping through like this from Hapax's Kairos project. I even tried to make that a dll to use, but I failed horribly because I suck at c++, LOL. I'm gonna have to crack down and see if there is any way to do a class similar to that so it would be .net compatible (unless it already is and I just am clueless on how to use it) ;)
-
The Timestep classes (Timestep and Timestep Lite) in Kairos (https://github.com/Hapaxia/Kairos/wiki) are designed to simplify the fixed timestep method described in Fix Your Timestep (http://gafferongames.com/game-physics/fix-your-timestep/).
Your code, however, seems to be just looping until a certain period of time has occurred. This is blocking and can slow down your application (it's also very similar to setFrameLimit).
This means that each frame will be at least a certain amount (it can be greater than or equal to "interval") but never reliably exact. Deltatime in this case is not consistent. If this loop is interrupted (say, the window is moved) and when it returns the time is (for example) interval * 100 past the previous time, elapsed would be interval * 100 and delta time would be 100 times smaller.
The idea behind the method(s) in Fix Your Timestep (http://gafferongames.com/game-physics/fix-your-timestep/) is to always process the same timestep each time. If the amount of time past isn't enough ("< interval" in your case), don't update any logic, physics etc.. If the time past is higher than interval, process just that interval and remove it from the amount of time (accumulation is a way of keeping of track of this). The loop is for cases where the amount of time past is greater than two times that desired interval/delta time. It would process each interval in the loop until there isn't enough time to process a single interval. Then, it would exit the loop and update the window etc..
Fix Your Timestep (http://gafferongames.com/game-physics/fix-your-timestep/) has the pseudo code already for you to be able to implement it yourself. Just remember that "integrate" in this case means "update your game's logic and physics".
-
I really appreciate you taking the time to explain this stuff better than what I am understanding it.
Okay, so essentially I am doing everything wrong in order to have a consistent game loop. Current here is my loop:
While (myRenderWindow.IsOpen)
CalculateTimers()
SetupScreen()
ApplyPhysics()
DrawEntities()
DrawInfo()
PresentScreen()
End While
DestroyGame()
Instead I should be moving all of my objects (ApplyPhysics) when I am calculating the timers?
All of this is really confusing. I tried porting over the RK4 integration (http://gafferongames.com/game-physics/integration-basics/) from his website. The term "State" used in it is a Structure that holds a Position and Velocity definition. However, the balls Position and Velocity both have an (x, y) coordinate value. Since gravity is constantly applied to the Ball, am I only supposed to be calculating the Position.Y and Velocity.Y?
Dim alpha As Double = accumulator / dt
Dim state As State= currentState * alpha + previousState * (1.0 - alpha)
render(state)
I don't know about C++, but in VB there is no way to simply add [State(x, v) = currState(x. v) * alpha ...], and instead I would have to add:
[State.x = currState.x * alpha ...]
[State.v = currState.v * alpha ...]
Which is fine, but what does "render(state)" mean? Is that simply just displaying everything I have moved and drawn to the screen, or have I completely missed the idea and should just take up stamp collecting for a hobby? LOL
-
The code used in that article is rather pseudo.
"State" is, simply, the state of everything at that time. It is every variable used for everything in the physics and logic.
Now, with that said, you don't necessarily use everything.
There is no real reason to not apply both components though:
state.position = currentState.position * alpha
state here would be the final state of everything for the frame you are preparing for and currentState would be the state of everything at the previous frame. This sounds overly complicated but it's only needed if you are doing the very final step in that article (the final touch). I'd leave that for now until you're more comfortable with the timing.
Some pseudo code for an implementation of fixed timestep:
deltaTime = 0.1 seconds
while (windowIsOpen)
{
currentTime = clock.currentTime
timeToProcess = timeToProcess + currentTime - previousTime
previousTime = currentTime
while (timeToProcess >= deltaTime)
{
applyLogicAndPhysics()
timeToProcess = timeToProcess - deltaTime
}
prepareDisplay()
drawDisplay()
}
-
No joke, but I literally almost had that exact same code after downloading the actual C++ sources from the tutorial. It took me quite a while to figure out why the movements were so sudden, meaning I would press a direction and the ball was on the other side of the screen.
I had to look at Kairos Timestep example to figure out I had to multiply by the delta time. For some reason everything I had for RK4 movement would not work, so I just implemented it inline and now it is working:
Dim k1 As Double, k2 As Double, k3 As Double, k4 As Double
'4th order
k1 = deltaTime * dydx(Ball.Velocity.Y, Ball.Position.Y)
k2 = deltaTime * dydx(Ball.Velocity.Y + deltaTime / 2, Ball.Position.Y + k1 / 2)
k3 = deltaTime * dydx(Ball.Velocity.Y + deltaTime / 2, Ball.Position.Y + k2 / 2)
k4 = deltaTime * dydx(Ball.Velocity.Y + deltaTime, Ball.Position.Y + k3)
Ball.Position.Y += (1 / 6) * (k1 + (2 * k2) + (2 * k3) + k4)
That is probably wrong though, but I will worry with it later. Thanks again for all the help man!
-
You don't technically have to multiply by the delta time. Since the delta time is constant, you can just use lower values. However, if it's at all regular-time based (for physics for example), it would be easier to use easier to understand values along with multiplying with dt. This also is required if you ever need to change the delta time but that should not be done as much as possible.
I haven't implemented RK4 myself so I can't really help. However, looking at the Gaffer on Games explanation, it looks like there is a lot more code required.
-
Yeah, this was all my original code for the RK4 method that I ninja'd from the C++ code examples. Before I followed your instructions for fixing my timestep I had this working, but since I implemented the fix I am going back over all the code, because there is a lot that is being left out of the calculations (momentum, friction).
More basic equations can be found here Runge Kutta 4 (http://people.revoledu.com/kardi/tutorial/ODE/Runge%20Kutta%204.htm)...it took me forever to find something that was easy to understand, and not have all the complicated symbols.
One thing I do not understand about all of this is why isn't any of the (x) values being calculated? Because all this is totally new to me, and I suck at differential equations, this has been a struggle to understand.
Regardless, since this is VB, it is about as close to pseudo code as you can get ;)
Private Structure State
Dim pos As Single ' position
Dim vel As Single ' velocity
End Structure
Private Structure Derivative
Dim dx As Single ' dx/dt = velocity
Dim dv As Single ' dv/dt = acceleration
End Structure
Private Function acceleration(ByVal state As State, ByVal t As Single) As Single
Const k As Single = 10
Const b As Single = 1
Return -(k * state.pos - b * state.vel)
End Function
Private Function evaluate(ByVal initial As State, ByVal t As Single) As Derivative
Dim output As New Derivative()
output.dx = initial.vel
output.dv = acceleration(initial, t)
Return output
End Function
Private Function evaluate(ByVal initial As State, ByVal t As Single, ByVal dt As Single, ByVal d As Derivative) As Derivative
Dim state As New State()
state.pos = initial.pos + d.dx * dt
state.vel = initial.vel + d.dv * dt
Dim output As New Derivative()
output.dx = state.vel
output.dv = acceleration(state, t + dt)
Return output
End Function
Private Sub integrate(ByVal state As State, ByVal t As Single, ByVal dt As Single)
Dim a As Derivative = evaluate(state, t)
Dim b As Derivative = evaluate(state, t, dt * 0.5F, a)
Dim c As Derivative = evaluate(state, t, dt * 0.5F, b)
Dim d As Derivative = evaluate(state, t, dt, c)
Dim dxdt As Single = (1.0F / 6.0F) * (a.dx + (2.0F * (b.dx + c.dx)) + d.dx)
Dim dvdt As Single = (1.0F / 6.0F) * (a.dv + (2.0F * (b.dv + c.dv)) + d.dv)
state.pos = state.pos + dxdt * dt
state.vel = state.vel + dvdt * dt
End Sub
-
Which (x) values aren't being calculated? Which (x) values?
VB is not pseudo code; it's very language-specific code :P
-
Private Structure State
Dim pos As Single
Dim vel As Single
End Structure
The original C++ code for this structure is:
struct State
{
float x;
float v;
};
From my understanding of the syntax a float is the smallest variable that can be used and should translate to single in vb.net.
I replaced State(x, v,) with State(pos, vel) so I understand it better (position, velocity). In a 2d environment there's coordinates for Object.Position(x, y) and Object.Velocity(x, y). Since I cannot store a vector value in a single, and I have no idea what I am doing, I tried this:
Private Structure State
Dim posX As Single
Dim posY As Single
Dim velX As Single
Dim velY As Single
End Structure
And modified the rest of the methods and functions to support that. But since it is not used in the original C++ code, and none of the simple methods for RK4 used anything like that I felt it was best to try something more realistic, instead of my redneck-math-foo I tried to develop, LOL
I also realized that this was not intended to find the (x) horizontal values for velocity, only the vertical values. I have found only 1 other source specific to vb for resolving all the physics for a falling ball. However the maths used for it were very flawed, and were not easily compatible with anything else, such as the trig functions used for multiple object collisions.
Regardless of all that, I have had the gravity partially working before I actually had a fixed time step. The whole point of starting this was to make sure the maths were correct so I could extend my 2d top down engine to support side scrolling platform. Since just about all the math involved relies on a fixed time step, I have to sit down again and go over pretty much everything. I honestly did not know it was going to be this much work, time, and confusion just trying to get not only something that works, but something that works like it is supposed to so that all they other systems work better.
***Note: I believe my maths are completely wrong on the slimmed down RK4, and I have the positions and velocities backwards.
-
SFML provides "vectors" that can be used to store both x and y fields together and perform calculations on them together as a vector. I can only assume that the VB binding has them too.
You could then pass the two Vector2 variables around the physics maths; you'd simply pass position and velocity (each would be [x,y]).
If you can't get that to work, though, simply passing position.x with velocity.x and position.y with velocity.y is possible by performing the calculation twice.
Note: float in c++ simply means a single floating-point value. I would presume that "single" would match "float" since c++ also has "double" after float ;D
-
Yes, I have recently tried using vectors to try to work through this, Vector2f to be precise. Even when I use 2 vectors in the Enum State, one for the [position(x,y) As Vector2f] and one for the [velocity(x,y) As Vector2f], I still have to access them like this:
Obj.State.Position.Y += Obj.State.Velocity.Y * DT
Several examples I have come across (in C++) actually use the entire Vector in the calculations. Those are mostly in particle simulators that change both the (x,y) values at the same time so an object will go in an ellipse around a central object.
After a brief break to brush up on calculus, using the original code from the integration example, I do not understand this:
Private Function acceleration(ByVal state As State, ByVal t As Single) As Single
Const k As Single = 10 '//-------gravity
Const b As Single = 1 '//-------randomly obscure value
Return -k * state.pos - b * state.vel '//------this line, right here...
End Function
I can partially get the slimmed down equations work though, but struggling to understand why so I can finish adding stuff to it. For the most part every RK2-4 example uses the same math equations regardless of language:
Runge-Kutta_method (https://rosettacode.org/wiki/Runge-Kutta_method)
double rk4
(double(*f
)(double, double), double dx
, double x
, double y
){ double k1
= dx
* f
(x
, y
), k2
= dx
* f
(x
+ dx
/ 2, y
+ k1
/ 2), k3
= dx
* f
(x
+ dx
/ 2, y
+ k2
/ 2), k4
= dx
* f
(x
+ dx
, y
+ k3
); return y
+ (k1
+ 2 * k2
+ 2 * k3
+ k4
) / 6;} double rate
(double x
, double y
){ return x
* sqrt(y
);} int main
(void){ double *y
, x
, y2
; double x0
= 0, x1
= 10, dx
= .1; int i
, n
= 1 + (x1
- x0
)/dx
; y
= malloc(sizeof(double) * n
); for (y
[0] = 1, i
= 1; i
< n
; i
++) y
[i
] = rk4
(rate
, dx
, x0
+ dx
* (i
- 1), y
[i
-1]); printf("x\ty\trel. err.\n------------\n"); for (i
= 0; i
< n
; i
+= 10) { x
= x0
+ dx
* i
; y2
= pow(x
* x
/ 4 + 1, 2); printf("%g\t%g\t%g\n", x
, y
[i
], y
[i
]/y2
- 1); } return 0;}
Unless I am reading that wrong, it and nearly every other code example using RK4 use [pos * Sqrt(vel)] to work out the f functions, which works if I swap the positions and velocities in the function. However, buried way off in a power point file I alternatively found [dy/dx = y-x^2] to work out the functions. That does not return proper results though (but I cannot remember what it does right now).
Eh, wall-o-text again :/ . The reason I need to understand this is because there are several things I am not able to calculate, like Drag & Friction. Acceleration seems to be calculated somewhere in there, and depending on which method I try to calculate the function will appear to speed up as an object is falling...I just don't know where.
Gonna go back and reevaluate the needs of this method, or needing a physics engine altogether...
-
I think I may at least partially understand your issue.
You're trying to smush 2 dimensions (x and y) into 1 dimension for rk4. ("State" in gaffer's article.)
Remember that dimensions are completely separate from one another!
Gaffer's article shows rk4 in only 1 dimension. Be careful with x and y in some articles. x and y may be used as variable names without much meaning, whereas they represent different spatial dimensions in physics. :)
Are you familiar with Taylor Series? The RK4 is similar-ish.
Constant position (1st order): p(t) = c.
Constant velocity (2nd order): p(t) = v * t + c.
Constant acceleration (3rd order): p(t) = a * t^2 + v * t + c.
Constant jerk (4th order): p(t) = j * t^3 + a * t^2 + v * t + c.
(Yes, "jerk" is the correct name for "change in acceleration". However, I guess it's sometimes called a "jolt". Yes, it exists. Real-life example: you pressing the gas pedal in a vehicle is jerk, as you are changing the acceleration of the vehicle.)
You can keep going, but, there's a point where it's just inane (jerk is usually that point).
Euler's method is inaccurate when any of the above values are not constant over a timestep, 't' (realistically true). Gaffer explains this in the beginning of his article you linked.
And since computers are finite, we can't be as accurate as the real world, hence the concept of a timestep.
RK4 takes this into account, and takes 4 samples ahead, where each following sample uses the previous sample to calculate itself, to more accurately estimate changes in velocity, acceleration, and jerk.
I hope this helps RK4 make more sense.
As for your acceleration function you have there, that's not acceleration due to gravity. That's acceleration due to a spring, Hooke's Law (https://en.wikipedia.org/wiki/Hooke%27s_law).
What you should do in that function, is add together all sources of acceleration on an object. Gravity, collisions, friction, drag.... springs. :) Then return that total.
Also, since you're using VB.NET, C# DLLs should *just work*, since they both are just compiled to CLR IR.
-
You're trying to smush 2 dimensions (x and y) into 1 dimension for rk4.
Yes and no. Initially I was, but then realized with several examples that the (x, v) referred to position and velocity. C++ programming examples provided enough info for calculating the position of a particle, but not as a 1 dimensional point, which confused me even more. Some examples were using single values for their states and not vector values, while others did use vectors, but the same equations as the single value states.
I honestly felt a bit better that no one else had a definitive idea of what they were doing since everyone was doing something different o achieve the same results :)
I had not heard of the Taylor Series, but have the wiki page pulled up to read over in a bit. I believe "jerk" and "jolt" are possibly "impulse" or "thrust" as well, as I have ran into those references many times over the past few weeks.
I have also ran into RK4 equations that calculate not only (k1, k2, k3, k4) but (l1, l2, l3, l4) which refer to a coupled equation, which I had to read even more info on that made much less sense. (a1, a2, a3, a4) are in a few as well, but they calculate what I believe is acceleration from (kn, ln). Honestly the more that is added the more sense it makes, yet confuses the heck out of me even more, LOL
What you should do in that function, is add together all sources of acceleration on an object. Gravity, collisions, friction, drag.... springs. :) Then return that total.
That is the simplest explanation of what-to-do I have ran into regarding all of this. It gives me a much better idea of what all needs to be calculated in that function so it will calculate accordingly.
My original goal of extending my engine has been drastically changed to me reinventing the wheel for a lot of things that just do not publicly exist for vb.net apps. And while there are some C# libraries that I could use, this is proving to be a very eye-opening experience of what little I really understand about what I need to do to accomplish a simple 2d platformer engine, correctly at least. I am literally 1 month in and essentially have not 1 line of working code that is going to be able to be used in my final project outline (aside from the time step). That's 6 month's in total on my entire engine that I am putting on the back burner to brush up on more logical and applicable math concepts ;)
-
Yes, I have recently tried using vectors to try to work through this, Vector2f to be precise. Even when I use 2 vectors in the Enum State, one for the [position(x,y) As Vector2f] and one for the [velocity(x,y) As Vector2f], I still have to access them like this:
Obj.State.Position.Y += Obj.State.Velocity.Y * DT
Several examples I have come across (in C++) actually use the entire Vector in the calculations.
Vector2fs have the ability to be multiplied with a scalar so, with your code example here, this code be simply replaced with:
Obj.State.Position += Obj.State.Velocity * DT
instead of:
Obj.State.Position.x += Obj.State.Velocity.x * DT
Obj.State.Position.y += Obj.State.Velocity.y * DT
After a brief break to brush up on calculus, using the original code from the integration example, I do not understand this:
Private Function acceleration(ByVal state As State, ByVal t As Single) As Single
Const k As Single = 10 '//-------gravity
Const b As Single = 1 '//-------randomly obscure value
Return -k * state.pos - b * state.vel '//------this line, right here...
End Function
I can't say that I fully understand this.
k represents the force and b is (as far as I can tell) is multiplying the velocity by 1 (so, in this case, doing nothing). From reading some of the comments, b looks like it is damping.
It's likely that this is all negative because the axis is based on increased y being upwards so you may need to change this for use with SFML.
-
Yes, I can multiply by scalar values. What I don't understand is why I would want to multiply the entire position, including horizontal (x) coordinate as well. This likely has more to do with the type of game you are designing for. What works for making one planet rotate around a sun (particle A in middle, particle B circling) in an example, is not going to work similarly to a character jumping. So a normal physics engine is going to use functionA when gravity is pulling in the center, and functionB when gravity is pulling down...probably not likely.
This is the original code from the Gaffer TimeStep and Integration sources:
float acceleration(const State &state, float t)
{
const float k = 10;
const float b = 1;
return - k*state.x - b*state.v;
}
I believe it is the same thing as what I am doing, and the b = 1 just makes no sense, because before subtraction, multiplication is going to happen without parenthesis defining which come first. And why is he passing t (time step?) through, yet doing nothing with it? However, in Timestep when converted to VB code, the ball in the center just springs left to right, so maybe that is why he is calculating things the way he is?
I am going to have to let this be for now because I am not making any progress understanding how to mush everything else in there, not to mention what all I have to mush in there for it to calculate correctly. It seems a physics engine is going to be out of the scope of my understanding. Don't get me wrong, everything you guys have had to say make 100% sense, but I believe trying to properly take into account all the variables that I am supposed to be calculating is just too overwhelming.
All that being said, I have not even touched code in the last few days because I have been reading this: http://gameprogrammingpatterns.com (http://gameprogrammingpatterns.com). Just in case no one has come across it I thought I would pass it along. It's great and has given me a better insight on how I need to develop my engine.
No joke, I have been so stubborn about changing languages in the last 8 years because of how much I like VB, but now with all this I feel I might make better progress if I just moved to C++ because there is so much more support for doing really complicated stuff...not to mention much smarter people already have working physics engines working for C++ ;D
-
Yes, I can multiply by scalar values. What I don't understand is why I would want to multiply the entire position, including horizontal (x) coordinate as well.
The position is two-dimensional so all forces act on both dimensions. In this case, k would probably also be two-dimensional; that's the direction of the force. If that force is gravity, the x value of velocity would be zero.
This is the original code from the Gaffer TimeStep and Integration sources:
[...]
I believe it is the same thing as what I am doing, and the b = 1 just makes no sense, because before subtraction, multiplication is going to happen without parenthesis defining which come first. And why is he passing t (time step?) through, yet doing nothing with it? However, in Timestep when converted to VB code, the ball in the center just springs left to right, so maybe that is why he is calculating things the way he is?
That's right. b being 1 and used as multiplication has no effect. b is "damping" and, in this case, is not used. b would be changed to allow damping.
t is passed, I believe, because some calculations require the current time (t = current time). His implementation here has been stripped of requiring those calculations so does not use t. If you read the comments (you really should; there are a lot of questions answered there), you can see that someone has pointed out this already.
However, in Timestep when converted to VB code, the ball in the center just springs left to right, so maybe that is why he is calculating things the way he is?
Is it possible that you're applying it to the x co-ordinate instead of the y and maybe the view's centre is (0, 0)?
-
OMG, the comments...how did I not notice them before?!? You're right, they do provide much clearer explanations of what all is going on in the equations.
No joke, I thought this area would be a general 1-type of equation is going to work, but that is not the case. He's leaving out friction, and drag is set to 1. He even further explains that his example IS for 1D, and that t can be used for other things that he isn't covering.
However, after reevaluating everything (the pm I sent) I am going to take a different approach on how to implement the 2d physics class, because not every game is going to use the same class :)
-
There are further articles on that site (http://gafferongames.com/) that progress onto applying physics in three dimensions (http://gafferongames.com/game-physics/physics-in-3d/) so there should be plenty of information for working with just two dimensions ;)
-
Some pseudo code for an implementation of fixed timestep:
deltaTime = 0.1 seconds
while (windowIsOpen)
{
currentTime = clock.currentTime
timeToProcess = timeToProcess + currentTime - previousTime
previousTime = currentTime
while (timeToProcess >= deltaTime)
{
applyLogicAndPhysics()
timeToProcess = timeToProcess - deltaTime
}
prepareDisplay()
drawDisplay()
}
One question here.
In RTS games like SimCity or Age of Empires player can change game speed by changing deltaTime. World simulation can run 0.5x slower (1/15), 1x - normal speed (1/30) or 10x times faster (1/300). Thats right approach if I'm not wrong.
But what with rest of logic - some GUI updates, smooth camera movement (1/60), determine which object is under cursor (1/10). They should be outside world simulation but also they need some limitation - not to burden the CPU, not move too fast (camera). Can I just use more fixed updates (in row) like the one above or what is propper way?
-
One important thing to remember is that changing the delta time doesn't really change how fast the application runs/updates; it only changes the size of the chunk of time that is processed.
One way to "slow down time" is to scale the delta time that is multiplied in the updates differently from the delta time that is processed in the time loops.
In that pseudo code you just quoted, I might put it here:
applyLogicAndPhysics(deltaTime * 0.5);
instead of passing the deltaTime unaltered (it should probably have passed the deltaTime in the original pseudo code).
Again, leaving the actual time processed being the same but the updates think that a different amount of time has passed.
Another way is to use a clock in which the speed of time can be changed. I'll mention Kairos' Timestep (https://github.com/Hapaxia/Kairos/wiki/Timestep) because I use it myself for time step stuff including time bending stuff. Timestep uses Kairos' Continuum clock, which can change time's speed so you can change the speed of Timestep.
You could change only the speed of the clock, which means that the same delta time takes longer so might update more jerkily at slower speeds but updates logically identically, or change the speed of the clock and scale the delta time used to match, which means that the updates takes the same amount of actual time and can be more smooth at slower speeds but updates are logically different since the timestep has now changed.
One thing to be aware of if you do use a time-bending clock is that a speed of zero could cause an infinite loop. Also, a time-bending clock running in reverse (negative speed) means that the delta time needs to be able to deal with that.
It's been a little while since I did time-bending timesteps so my memory on the subject might be a little rusty.
-
applyLogicAndPhysics(deltaTime * 0.5);
This seems working fine. I found one thing, sf::Texture::setSmooth = false (GL_NEAREST) causes some rounding and it also affects sprite movement, "it's jumping by integers". With GL_LINEAR it's smooth even on low update rates / lower multiplier.
Another way is to use a clock in which the speed of time can be changed. I'll mention Kairos' Timestep (https://github.com/Hapaxia/Kairos/wiki/Timestep)
..
You could change only the speed of the clock, which means that the same delta time takes longer so might update more jerkily at slower speeds but updates logically identically, or change the speed of the clock and scale the delta time used to match, which means that the updates takes the same amount of actual time and can be more smooth at slower speeds but updates are logically different since the timestep has now changed.
In both cases it's still tied with system time (lockstep, amount of game time elapsed per tick is constant)? Anyway I will test it.
-
One more simple way to approach some of the more common speeds is to simply process updates multiple times.
So, for 1x speed, update once whereas for 2x speed, update twice. For 3x speed, update thrice and so on.
Basically:
speedMultiplier = 3 // for 3x speed
while (timeToProcess >= deltaTime)
{
loop speedMultiplier times:
{
applyLogicAndPhysics()
}
timeToProcess = timeToProcess - deltaTime
}
Of course, if you wanted slower speeds, you could start slower and multiply to get the normal speed but this seems to be a less efficient approach for that case.