* Add `love.graphics.isSupported("hdrcanvas")' to query whether the hardware
actually supports HDR canvases.
* Add optional third argument to `love.graphics.newCanvas(w,h, type)', where
`type' is one of "normal" or "hdr" and defaults to "normal". HDR canvases
use floating point that can have values > 1 to store pixels, allowing for
HDR rendering and other higher level lighting techniques when combined with
pixel effects.
* Add `canvas:getType()'.
New particles are spawned around the particle emitter position according to a
configurabe distribution.
New functionality:
particlesystem:setAreaSpread(distributon, x, y)
distribution, x, y = particlesystem:getAreaSpread()
Where `distribution' is one of "none", "uniform", "normal".
`x' and `y' take different meaning based on the distribution:
* none: no area spread - particles spawned at emitter position.
* uniform: particle spawned at px,py in the rectangle around emitter
position ex,ey, i.e.:
ex - x < px < ex + x, ey - y < py < ey + y,
* normal: particle position drawn from a normal/gaussian distribution
with mean ex,ey and standard deviation x,y, i.e.:
px \in N(ex, x²), py \in N(ey, y²).
Add a extern vec2 love_ScreenSize to the pixel effects that will
be (re)set upon PixelEffect::loadVolatile() and is used to flip
the fragment coordinate.
Unfixes #324 because canvases can have different dimensions than
the screen.
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
When drawing lines at scales>1 the inner workings (gradients) of the
antialiasing too were upscaled and became visible. When the scale was very
large this produced interesing yet unexpected visuals.
Instead of letting OpenGL manage the memory mapping, allocate a temporary
block of memory upon VBO:map(). Upon VBO::unmap() the block is copied to
graphics memory using glBufferSubDataARB() and then released.
Hopefully this will fix some weird error with Windows XP + old drivers, where
VBOs can be created, but the mapped memory cannot be allocated resulting in
the sprite batch drawing nothing at all.
According to the interwebs this could actually faster than using OpenGL mapped
memory, because there is no unnecessary syncing involved.
rude
vrld
Bart van Strien
Marc Lepage
Bill Meltsner