Used to handle jump input. This is to encapsulate all
the nitty-picky logic about considering a button is still
pressed a fraction of seconds after it has been pressed, etc.
It does not actually poll and/or listens to the real hardware,
it just keeps track of what’s happening with push/pop operations.
An object to tract steering, that is, going left, or going right.
This does not actually poll/reacts to the physical controllers,
it just collects “go right” or “go left” informations then
aggregates and consolidates them.
Different defs of slabs (those rectangles the ball can roll on).
A def is what defines a slab, it will be translated into a kind
at runtime. Typically some defs can be “a random slab”, or
even “a slab that varies with time”, etc.
Indices for rows can not be bigger than this. It is insanely big though,
at 100 slabs per sec, it represents 1 million seconds, which is more than
10 days of continuous play.
Keyboard sensibility, one way to think of it is “how many pixels should be
a corresponding mouse move, if it lasted 1 second”. So moving the
mouse of 1000 pixels in 1 second is equivalent to keeping a move
arrow pressed for 1 second.
Setting it to negative value will invert keyboard.
By default, the stickiness is set to a bit more than 1/10th of a second.
This means that if player pushes a jump control less than
1/10th of a second before it can actually jump, the jump
is still recorded as valid.
History about one level will be kept only below this limit.
Above it, the initial slabs will disappear. This should really
not be a problem as for a complete restart, we can reinitialize with
a seed, and otherwise it stills allows going back in time by 10k slabs,
which means several minutes even at high speed.
Maximum number of seconds we can track. This is related
to the limit of a mantissa in 64-bit IEEE numbers, which
is about 10^15. Since we count in msec, we have to divide
to take away 3 digits. This is still several centuries.
A maximum width, most playable values should range from 6 to 12,
so 32 is already a lot. To simplify/optimize code, program uses
fixed size rows, set to the WIDTH_MAX. With slabs of 4 or 8 bytes,
it means only 256 bytes (worst case) for a row. With this setting,
a 10_000 rows level, playable for about an hour, at 3 slabs/sec still
fits into 30Mb of memory.
Pulse func as defined here:
https://en.wikipedia.org/wiki/Pulse_wave
The global period is 1, the alpha value can be used
to control the ratio between 1s and 0s.
Sawtooth wave func as defined here:
https://en.wikipedia.org/wiki/Sawtooth_wave
It alternates between values of -1 and 1, with a global period of 1.
It switches between them at x == 0.5.
Sine wave func as defined here:
https://en.wikipedia.org/wiki/Sine_wave
It’s a simple sinusoid, only this one has a period of 1 instead of 2PI.
The idea is to be able to use it as a drop in for triangle_wave for
instance, without introducing a 2*PI factor. If you want a real sin,
just use the builtin func.
Square wave func as defined here:
https://en.wikipedia.org/wiki/Square_wave
It alternates between values of -1 and 1, with a global period of 1.
It switches between them at x == 0.5.
Triangle wave func as defined here:
https://en.wikipedia.org/wiki/Triangle_wave
It alternates between values of -1 and 1, with a global period of 1.
It switches between them at x == 0.5.
Return the time contained in the option if it is defined.
If not (None was passed) returns the result of an actual
call to Instant::now(). This is useful for testing: in
mainstream production code, just pass None, but for
testing it is possible to pass fake instants.