Contains just a RNG for now, but may include other functionality (e.g.
transforms) later on.
New Functions:
-- as in the lua math library:
love.math.randomseed(number) -- set random seed
love.math.random() -- get random number in [0:1) (uniformly distributed)
love.math.random(high) -- get integer random number in [1:high]
love.math.random(low, high) -- get integer random number in [low:high]
-- additional functions
love.math.randnormal() -- get normally distributed number with zero mean
-- and unit variance
love.math.randnormal(o) -- get normally distributed number with zero mean
-- and standard deviation `o`
love.math.randnormal(m, o) -- get normally distributed number with mean `m`
-- and standard deviation `o`
If in conf.lua `t.screen' is set to false or nil, the OpenGL context will not
be initialized, leading to a crash in 'Font::print()' when printing the compat
message later on.
Example setMode invocation: love.graphics.setMode(800, 600, {fullscreen = false, vsync = true, borderless = true})
t.screen.resizable and t.screen.borderless are available in love.conf
And love.resize(w, h) gets called if it exists on a resize event.
NOTE: love.handlers.resize(w, h) does the required setMode, but that does mean a visual reload
--HG--
branch : minor
To do this we needed to take ThreadVariant out of love.thread, and move it to common.
This also changes event names, instead of 1/2-letter abbreviations, full names!
Moving the event loop improves accuracy of various input functions, and thus decreases mouse lag for custom pointers, for instance.
Doing a timestep after window creation makes sure that engine initialization isn't in the first dt.
NOTE: A near-zero dt can occur.
Users (or lovers) do not get to choose which implementation of
a module they would like to use.
The abstraction is for dealing with portability issues, not
for giving people the ability to choose an alternative
(inferior) backend. The best choice for any platform/situation
should at all times be the *default* for that platform/situation.
If this is not the case; it's a bug (that is easily fixed).
Any module should provide the functionality promised in the docs.
The lover (or user) should not care how, and if [s]he does, [s]he
does still not get to choose.
Also, a related note: duplication of wrapper code is something I
especially wanted to avoid when I first (or should I say ...
"eventually") formed the current architecture.
--HG--
branch : minor
Alex Szpakowski
Bart van Strien
vrld
Alexander Szpakowski
Bill Meltsner
vrld
Bart van Strien
rude