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()
- The "replace" color mode can easily be duplicated with love.graphics.setColor(255, 255, 255)
- The current color mode has no effect when a shader is active
- Color mode functionality can easily be replicated with shaders
- OpenGL ES 2 (iOS, Android, etc) does not have the functions used by love.graphics.setColorMode
setColorMask enables or disables specific color components when rendering and clearing the screen.
For example, setColorMask(true, false, true, true) will prevent the green component of the color of all rendered objects from being written to the current frame buffer.
setColorMask is a wrapper for http://www.opengl.org/sdk/docs/man2/xhtml/glColorMask.xml
--HG--
branch : love.graphics.setColorMask
Add the somewhat lengthy named love.graphics.getDefaultImageFilter() and
love.graphics.getDefaultImageFilter(). The verbose name should point to the
fact that changing the default filter midway through the game will not affect
the images already loaded using love.graphics.newImage().
Error reporting now resides in Graphics::newCanvas() instead of the
previous location wrap_newFramebuffer(). Changed error text for
"Error in implementation" to point to a possible fix.
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
vrld
Alexander Szpakowski
Bart van Strien
rude
Bill Meltsner
vrld
Bart van Strien