Useful for bitmaps pixelated fonts where anti-aliasing is not desired!
Change also enables additional font generation mechanisms in a future (cleartype, hinting...).
strprbrk() does not follow raylib function name convention but as it is
very similar to the standard strpbrk(), we'll keep the naming... also,
don't like to mix static functions with API functions but as strprbrk()
is just used in the two functions below, it's ok to be there... maybe it
could be refactored in a future or even move the logic inside the
required functions...
When a batch reach its vertex limit, a draw call is issued and batch restarted for refilling but if the draw call was issued for vertex data accumulated inside rlPushMatrix/rlPopMatrix, draw call was issued before the rlPopMatrix, consequently modelview matrix was not properly recovered before the draw call... obviously, it only happened the following draw calls, not the first one...
Now it works ok but this system needs to reviewed, noticed and important frames drop when processing around 20 dynamic batch draw calls, it means filling MAX_QUADS_BATCH (8192) quads of data 20 times per frame, including data updating and sending for draw processing.
Doing some maths, it means:
Vertex data (float) -----> 8192 quads * 4 vertex * 3 comp * 4 byte = 393216 bytes
Texcoords data (float) -> 8192 quads * 4 vertex * 2 comp * 4 byte = 262144 bytes
Color data (uchar) -----> 8192 quads * 4 vertex * 4 comp * 1 byte = 131072 bytes
Thats a total of 786432 bytes (0.75MB) sent to GPU 20 times per frame for processing... I'm testing in an Intel HD Graphics integrated, I imagine is too much data to be sent and and it causes stalls, so the frames drop...
Added support form vertical and horizontal 3-patches.
Corrected the distortion caused when destRec size is smaller than 4x4. Now even 1x10 or 0x0 sizes are drawn correctly.
Added support form vertical and horizontal 3-patches.
Corrected the distortion caused when destRec size is smaller than 4x4. Now even 1x10 or 0x0 sizes are drawn correctly.
The GLFW tree distributed with raylib has two modifications:
- GLFW_PKG_{DEPS,LIBS} are exported to PARENT_SCOPE, so we can use them
in our pkg-config file
- An intermediary glfw_objlib target is added, so we can reexport GLFW
symbols from libraylib.a
rglfw can fix the second point, but for Wayland usage, we would have to
replicate protocol generation, so we just leverage GLFW's existing
support instead.
To make maintenance easier, I have submitted a pull request for
including these modifications to upstream GLFW.
And to make that one easier, this patch dog-foods the modifications,
so raylib users can help find regressions. :-)
glfw/glfw#1307
