Gamma-correct blending and shader math can be enabled globally via the new 't.gammacorrect' boolean flag in love.conf.
The new function love.graphics.isGammaCorrect will return true if it was requested in love.conf and is supported on the system.
When gamma correct rendering is enabled, colors (including the colors of pixels from images) are automatically converted from sRGB to linear RGB before use. When drawing to the main screen or to a canvas with the 'normal' or 'srgb' format, the final output colors of pixel shaders are automatically converted from linear RGB to sRGB after blending and before the color is stored in the pixel.
This lets the rendering pipeline do math using linear RGB values for colors rather than sRGB values, so the math is correct, without making users of the APIs manually linearize their colors with the love.math.gammaToLinear function (which still exists). The final output of the screen is encoded as sRGB, which is what systems expect. Canvases (except when otherwise requested) store their contents with sRGB encoding for increased precision with darker colors.
the 'srgb' window setting flag has been removed, as well as the 'srgb' image flag. A new image flag 'linear' has been added, which when set to true will cause the colors of the image to always be treated as linear RGB rather than sRGB, when gamma-correct rendering is enabled.
A new function 'Shader:sendColor' has been added, which has the same argument structure as 'Shader:send' but expects colors in the range of [0, 255]. When gamma-correct rendering is enabled it automatically gamma-corrects the given colors (by applying gammaToLinear to them.)
New shader code functions have been added: gammaToLinear, linearToGamma, gammaCorrectColor, and unGammaCorrectColor. When gamma-correct rendering is enabled, the LOVE_GAMMA_CORRECT #define is set and gammaCorrectColor and unGammaCorrectColor are aliases for gammaToLinear and linearToGamma respectively, otherwise the functions do nothing.
The new shader functions have 'precise' and 'fast' variants. If the LOVE_PRECISE_GAMMA define is set, then the normal functions default to the precise variants, otherwise they default to the fast variants. Currently the define is set in vertex shaders and not set in pixel shaders.
The default per-vertex color is automatically gamma-corrected by LÖVE when gamma correct rendering is enabled, but any custom named per-vertex attribute specified with the new custom attribute Mesh functionality won't be, unless 'gammaCorrectColor' or similar functions are explicitly used (preferably inside the vertex shader code that has the custom attribute.)
drawcalls: The number of internal draw calls made so far in the current frame.
canvasswitches: The number of times the active Canvas has been changed so far in the current frame.
texturememory: The approximate amount of video memory (in bytes) used by OpenGL textures created by Images, Canvases, and Fonts.
images: The number of active Image objects.
canvases: The number of active Canvas objects.
fonts: The number of active Font objects.
The list includes RGBA with 4-bit components, RGBA with 10-bit R, G, and B components and a 2-bit alpha component, RGB with 9-bit RGB components and a 5-bit exponent component (for HDR rendering), and several more.
--HG--
branch : Canvas-formats
love.graphics.newImage(path, “srgb”) creates a new Image whose texels are treated as being in the sRGB color space, so they are linearized when drawing/sampling from the image.
love.graphics.newCanvas(w, h, “srgb”) creates a new Canvas whose texels are treated as being in the sRGB color space, so drawing to the Canvas does a linear->sRGB conversion (but blends linearly), and sampling from it (drawing it or using it in a shader) converts from sRGB to linear space.
The "srgb" window flag does the same as Canvases for the main screen.
Canvases and Images are now subclasses of the new Texture class.
Added setTexture and getTexture methods for Meshes, ParticleSystems, and SpriteBatches (the old set/getImage methods are deprecated but not removed.)
Canvas texture coordinates are no longer flipped.
This allows for more diverse and complex Geometries, provided the lover understands how to use each mode. See http://escience.anu.edu.au/lecture/cg/surfaceModeling/image/surfaceModeling015.png
Changed love.graphics.newGeometry to optionally accept vertices as individual arguments instead of just a table of vertices (resolves issue #651).
Changed Geometry:setVertex to optionally accept a table containing x,y,u,v,r,g,b,a instead of just individual arguments.
Added Geometry:set/getDrawMode.
Removed the convex-check in love.graphics.newGeometry (all geometry modes have at least some form of concavity support, lovers can do their own check if needed with love.math.isConvex.)
Added an optional "vertex map" table argument to love.graphics.newGeometry (AKA a vertex index array / element array in graphics programming lingo.)
This allows lovers to change the order in which the vertices are used when drawing, or re-use a single vertex multiple times for different parts of the Geometry.
This is especially useful in the "triangles" Geometry draw mode. The vertex map lets you draw very complex (and concave) shapes / meshes without duplicating vertex data.
Added Geometry:set/getVertexMap.
A Geometry is a collection of vertices describing a non self-intersecting
(simple) polygon. In addition to screen coordinates, the vertices have
attributes for texture coordinates (s,t) and color (r,g,b,a).
It can be used as a quad, to display distorted images, or anything in between.
Added:
^^^^^^
-- geometry from table, where table has the format:
-- info = {
-- {x,y, s,t, [r = 255, g = 255, b = 255, a = 255]}
-- {x,y, s,t, [r = 255, g = 255, b = 255, a = 255]}
-- ...
-- }
geom = love.graphics.newGeometry(info)
-- convenience wrapper for quads (same as before)
geom = love.graphics.newQuad(x,y, w,h, sw,sh)
-- retrieve vertex i (1-indexed)
x,y,s,t,r,g,b,a = geom:getVertex(i)
-- set vertex i (1-indexed)
geom:setVertex(i, x,y, s,t, [r,g,b,a])
-- flip geometry
geom:flip(x, y)
Renamed:
^^^^^^^^
love.graphics.drawq() -> love.graphics.drawg()
Removed:
^^^^^^^^
quad:setViewport()
quad:getViewport()
- Simultanious rendering to multiple canvases requires all canvases to be the same size (limitation of pre-GL3.0 framebuffers)
- love.graphics.isSupported("mrtcanvas") was added
- love_Canvases[n] (0-based array of active canvases) can be written to in pixel shaders in the 'effects' callback function
- everything drawn to multiple canvases at once will be duplicated to all canvases if no shader is active or the standard 'effect' shader function is used
--HG--
branch : MRTs
* 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()'.
Alex Szpakowski
vrld
Alexander Szpakowski
rude
Bart van Strien
