-
Your game will contain a number of non-code assets
-
Your program will need to access these at run-time
-
Where does an executable look for external files?
-
e.g. for "Sdl-logo.bmp"??
-
-
In the "Working Directory"
-
wherever that is?
-
where the executable was loaded from
-
not, necessarily where the executable is !!!! [frown o]
-
-
The "Working Directory" is OUT OF YOUR CONTROL
-
your user/player could start your program from anywhere
-
for example, they could start it like this, from
C:\Windows
-
C:\Windows\>C:\Users\aUser\gamesProgramming\build\bin\myAwesomeGame.exe
- Working Directory
-
C:\Windows\
- Exe Location
-
C:\Users\aUser\gamesProgramming\build\bin\myAwesomeGame.exe
-
The directory where each projects project file is
-
.vcxproj
files for each project -
e.g.
myAwesomeGame.vcxproj
-
-
You can change this in Visual Studio
-
Configuration Properties / Debugging
-
-
CMake doesn’t have direct support for setting the working directory, but there are some automated solutions
-
in an assets folder
-
with your source
-
-
copied to your build folder (
build/bin
) automatically-
by your
setup.bat
(akaconfigure.bat
,auto.bat
) -
by CMake (https://cmake.org/cmake/help/latest/command/file.html - look for COPY)
-
-
As the
working directory
is out of your control, you should look for files relative to your executable -
argv[0] is frequently the full path to your executable, but not always
-
SDL has a function to get the path of your executalbe
-
You could use this to make sure your program stills find its assets even when run from other working directories
-
For our games to do anything, we need to change its state
-
Unlike many other systems, Games tend to change their state over time
-
even when there is no human interaction
-
e.g. a ball keeps falling
-
-
Changing a model over time
-
Our world has some state to one time
-
A timestep later the world state has changed
-
We have to determine what should change and how
-
-
In general all game simulation is fakery
-
i.e. a "model" of how things change - not 100% correct
-
-
We have choices about how much we fake things
-
And choices about efficient algorithms etc
-
Why always fakery?
-
We may not be attempting to simulate the real world
-
Almost all physical systems are mathmatically impossible to compute analytically
-
see three-body problem - https://en.wikipedia.org/wiki/Three-body_problem
-
-
Time
-
Length
-
Position
-
Velocity
-
Speed
-
Acceleration
-
Mass
-
Force
-
A measure of duration
-
A scalar (single dimensional / not a vector / has no direction)
-
Units are seconds: (\$s\$)
-
Usual symbol is \$t\$
-
e.g. \$t = 4.3s\$
-
Where in space a point is, relative to some base point
-
Units are metres: (\$m\$)
-
A vector (\$m\$ on each axis)
-
Usual symbol is \$\vec{p}\$ or \$\vec{r}\$
-
e.g. \$\vec{p} = (2.3, 4.5)\$
-
The rate of change of position over time (derivative)
-
Units are metres per second: \$\frac m s\$ (also \$m s^{-1}\$)
-
A vector (\$m s^{-1}\$ on each axis)
-
Usual symbol is \$\vec{v}\$
-
e.g. \$\vec{v} = (0.4, 2.3){m s^{-1}}\$
-
Magnitude of velocity: \$|v|\$
-
i.e. independent of the direction
-
-
Units are also metres per second: \$\frac m s\$ (also \$m s^{-1}\$)
-
A scalar (has no direction)
-
e.g. \$speed = 2.33{m s^{-1}}\$
-
Can compute from velocity - (and reverse if have the direction)
-
Magnitude of a vector is its length
-
How do we compute the length of vector?
-
Square root of the sum of the squares
-
-
if \$\vec{v} = (x, y)\$
-
\$|v| = \sqrt{x^2 + y^2}\$
-
-
if \$\vec{v} = (0.4, 2.3)\$
-
\$|v| = \sqrt{0.4^2 + 2.3^2} = 2.33\$
-
-
if \$\vec{v} = (x, y, z)\$
-
\$|v| = \sqrt{x^2 + y^2 + z^2}\$
-
-
if \$\vec{v} = (0.4, 2.3, 3.2)\$
-
\$|v| = \sqrt{0.4^2 + 2.3^2 + 3.2^2} = 3.96\$
-
-
The rate of change of velocity over time (derivative)
-
Units are metres per second per second: \$\frac m {s^2}\$ (also \$m s^{-2}\$)
-
A vector (\$m s^{-2}\$ on each axis)
-
Usual symbol is \$\vec{a}\$
-
e.g. \$\vec{a} = (0.4, 2.3){m s^{-2}}\$
-
A measure of resistance to change of motion when a force is applied
-
Is NOT the weight of an object (that depends on gravitational pull)
-
Units are \$kg\$
-
A scalar (has no direction)
-
Usual symbol is \$m\$
-
e.g. \$m = 45.3kg\$
-
Vectors are a good representation
-
Easy to understand
-
Moving from 2D to 3D is easier
-
Efficient for processing
-
Use SI Units
-
International System of Units (Système international d’unités, SI)
-
-
Will make your life MUCH easier
-
avoid inches, miles
-
-
What are they?
-
Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it
-
also indicates that if an object is at rest (not moving) it will remain at rest
-
-
A force is applied only to the concept we commonly call acceleration
-
An object’s mass, acceleration, and the applied force may be represented by
-
\$\LARGE F = ma\$
-
-
For every action there is an equal and opposite reaction`
-
If two objects bump into each other they will react by moving apart
-
in an interaction between two objects, apply the same (but opposite direction) forces to each
-
can simplify for infinite masses, or things we don’t want to move
-
-
-
Some representation of velocity in your game is vital for objects to move (new positions calculated from old positions, velocity and time)
-
You don’t have to use acceleration
-
your game could set velocity values directly
-
this is unrealistic (compared to real world), but frequently doesn’t matter
-
e.g. changing from not moving to travelling at \$5{m s^{-1}}\$ instantly is an infinite acceleration
-
-
-
If we know the position and velocity of an object we can calculate its position some time later
-
\$\vec{p'} = \vec{p} + \vec{v} * \Delta t\$
-
this is called integration
-
-
This works just fine as long a \$\vec{v}\$ is constant throughout \$\Delta t\$
-
Assuming velocity is constant through a simulation step is frequently (usually) wrong
-
The impact of the incorrect assumption can be mitigated by:
-
reducing the duration of the time step
-
using a more sophisticated form of integration (e.g. Runge-Kutta 4)
-
-
Just as we can change position according to velocity we can change velocity according to acceleration
-
\$\vec{v'} = \vec{v} + \vec{a} * \Delta t\$
-
-
Assumes that \$\vec{a}\$ is constant throughout \$\Delta t\$
-
It’s important to be able to obtain the real time in games
-
so that we can make sure we simulate and render appropriately
-
-
Using \$seconds\$ everywhere is my strong recommendation
-
possibly worth wrapping functions/methods that use \$ms\$ to use \$seconds\$
-
in some situations the precision of a 32-bit float may not be enough
-
consider using a 64-bit float
-
double
- double precision floating point type.-
usually IEEE-754 64 bit floating point type
-
-
-
-
SDL_GetTicks() gives you the number of milliseconds since the SDL library initialization (as 32 bit int)
-
How many milliseconds per frame
-
at 60fps?
-
at 100fps?
-
at 120fps?
-
#include <iostream>
#include <chrono>
typedef std::chrono::high_resolution_clock Clock;
int main()
{
auto t1 = Clock::now();
auto t2 = Clock::now();
std::cout << "Delta t2-t1: "
<< std::chrono::duration_cast<std::chrono::nanoseconds>(t2 - t1).count()
<< " nanoseconds" << std::endl;
}
-
Your speed of render will be variable
-
across machines
-
over time
-
-
Track how long it has been since the last render and simulate that length of time
-
what happens if no-vsync
-
??
-
-
Adjusting your simulation rate to vary with render rate is non-deterministic
-
for networking and test determinism in important (more next year)
-
you could simulate with a fixed time step
-
-
Only in some situations the future may be calculated analytically
-
for very simple models (or parts of a more complex model)
-
e.g. determine analytically when a ball will hit the floor
-
-
Distance \$d\$ travelled by an object falling for time \$t\$:
\$d=\frac{1}{2}(g*t^2)\$
-
Time \$t\$ taken for an object to fall distance \$d\$:
\$t =\ \sqrt {\frac{2d}{g}} \$
-
let’s assume t is 2 seconds
-
what is g?
\$d=\frac{1}{2}(g*t^2)\$
-
⇒ d = ???
-
let’s assume t is 2 seconds
-
what is g?
-
force/acceleration due to gravity
-
= 9.81 meters per second per second
-
-
t = 2.00
-
g = 9.81
\$d=\frac{1}{2}(g*t^2)\$
-
⇒ d = 19.62 meters !!
-
g = 9.81
-
d = 54 meters (height of the Leaning Tower of Pisa)
\$t =\ \sqrt {\frac{2d}{g}} \$
-
⇒ t = ???
-
the vast majority of game simulations cannot be solved analytically
-
see three-body problem (" no general analytical solution for the three-body problem") - https://en.wikipedia.org/wiki/Three-body_problem
-
-
so we solve instead by taking time steps
-
and assuming (usually incorrectly) that some properties don’t change during that step
-
this means that our simulations are INCORRECT
-
-
incorrect gain (or loss) of energy in the system
-
leading to instability / blowing up
-
-
There may be other things in your game which change or you want to change
-
these should be changed in
update
also -
perhaps in a separate part of
update
-
i.e. do all "physics", then do all other updates
-
-
-
What might this include???