* draw pen skin lines and stamps to a framebuffer
* skip reading pixels and draw stamp to framebuffer
* update silhouette with readPixels
* draw pen canvas to buffer when its dirty
Composite lines and stamps on browser preferred side (cpu/gpu) until
the export texture is needed. Then blend the canvas with the current
buffer contents.
Updating this way invalidates useProgram optimization and the renderer
currently does not have a way to know this.
* draw lines on framebuffer through fragment shader
* optimize draw regions and pen skin matrix creation
* control draw regions
* mobile gpus need high precision floats for line drawing
* optimize cpu pen line math
* sampled pen line caps
* sampleless pen skin lines, lint, document pen skin buffer ops
* add PenSkin._canvasDirty to constructor
* remove DRAW_MODE_line
* comment PenSkin reused memory, use memory in drawRectangle
* turn draw region id's into optional method handlers
A region ID object may have an enter and exit method on it that are
used by default when entering and exiting that region.
* remove old DRAW_MODE_line precision setting
* standardize vert lines on 4 spaces
* fixup! turn draw region id's into optional method handlers
* do not draw when updating pen skin silhouette
* do not premultiply stamp colors by alpha
* fixup! do not draw when updating pen skin silhouette
* do not premultiply line color
* add a small rim around the line for aliasing
* variable pen line alias amount
* reverse offset pen line on y axis by relative alias amount
Reverse the offset to keep small line overlap to a minimum.
* fixup! reverse offset pen line on y axis by relative alias amount
* medium precision gpu floats
Some mobile GPUs end up dividing by "zero" with the previous epsilon
value. The larger epsilon doesn't cause any problems on systems which
didn't exhibit the bug (like my main dev machine).
The `isTouchingColor` function now takes an optional mask parameter. If
provided, only the parts of the Drawable which match the mask color will
be used for the test. For example:
```
isTouchingColor(4, red, blue);
```
This means "are there any parts of Drawable #4 which are blue and are
touching a red pixel on some other Drawable?"
HSL's lightness is, in this case, basically the same as half of HSV's
value, so this change halves the threshold value used by the color
effect to make it similar in appearance to the HSV implementation.
This will allow rendering the primary view, picking view, and "touching
color" view with different projection matrices without needing to
recalculate the model matrix for every Drawable every time.
Pixelate still needs a bit more work: at certain scales the edges of the
"pixels" are ragged. This happens in Scratch 2.0 as well, but for me it
seems slightly worse in this implementation.
The renderer now uses premultiplied alpha in the frame buffer, though
textures are still stored without premultiplied alpha. This makes it
easier to get the desired results from the browser's canvas compositing
step, and might be nicer for mobile hardware depending on which parts of
the Internet you believe.
This implementation of the pixel effect is now very similar to the
PixelBender implementation in Scratch 2.0
I also added a slider to demo.html as a debugging aid: it manipulates a
value that is passed into the shader and used in whatever way helps.
The current fragment chader contains non-uniform control flow for
determining the texture coordinates to use with `texture2D()`. The spec
says that this can cause undefined behavior; in my case I see a
"sparkle" of wrong pixels near primitive edges.
See:
https://www.opengl.org/wiki/Sampler_%28GLSL%29#Non-uniform_flow_control
This change introduces the Drawable class, which corresponds to a
Scratch sprite or clone. It supports setting its "skin" (corresponding
to a Scratch costume) by md5+extension, but currently only supports
bitmap skins. Drawables can be created, destroyed, and otherwise
manipulated by ID through the renderer.
