trying to get chickadee 0.8.0 out in time for the lisp game jam. really trying to make this version much easier for beginners to use.

and for fun, here's square-limit. this one really exposes some performance issues with the current vector graphics implementation. when I look at this picture, I see two draw calls needed: one to draw the filled circles, and one to draw the stroked circles. however, to make the computer recognize this truth is complicated! so right now it's 2 draw calls for every filled circle/stroked circle pair. I'm only getting about 45fps rendering this, as a result.

corner-split a la SICP section 2.2.4 using chickadee's vector path rendering. using a gradient filled circle for simplicity here but it could be any arbitrarily complex vector graphic.

@ekaitz_zarraga BLOCKED

never pay full price for a sirius subscription. just open up the chat and tell them you want to cancel and they will cut the cost by over 50%.

@ekaitz_zarraga the standard guile repl does not support being used in combination with an event loop at all. when you run that repl, it has complete control over the thread it is running in until the user quits the repl.

I've worked around it with a big gross hack that prevents multi-line expressions but prevents hanging the repl. an okay trade-off for now until guile replaces the c reader with a scheme one, which could happen as soon as the next release because I know it has been worked on.

there's one big issue remaining with my non-blocking guile repl: if you press enter without having typed in a full s-expression, it hangs. this is because guile's 'read' procedure will block until a full expression has been input. guile has a buffered input port type that could address this, but I rely upon delimited continuations to suspend the repl while waiting for user input. delimited continuations do not work if the call stack has anything from guile's c api in it. the 'read' procedure is implemented in c, so I'm stuck.

the next release of chickadee is going to come with an executable like the "love" executable from love2d. will make it very easy to get started with the library by eliminating a bunch of boilerplate and providing repl integration.

@ekaitz_zarraga thanks for trying! hope you get to relax a bit, too.

@ekaitz_zarraga I like to code to relax sometimes but it's been hard to get in that state. I don't feel any pressure to work on something that no one uses. ;)

if I wasn't so dang stressed out I'd like to take another pass over my vector path (SVG-like) rendering module for chickadee. it currently has support for solid color fills using the non-zero rule and solid color strokes with a few styles of end caps. I'd like to add support for linear gradient, radial gradient, and texture pattern fills, even-odd rule fills, dashed strokes, raster images, and text. if I could get all of that in there it would be a solid realtime vector graphics package.

I learned the math for computing the vertices of an icosahedron but I couldn't think of a way to easily generate the mesh, so I wrapped tape around a d20 I had from back when I played mtg, labeled all the vertices, and used that as reference to build the 20 triangles in the mesh.

you can say this is a really low resolution sphere. for my next trick, I will subdivide each of the 20 triangles several times and transform each vertex so that it is the same distance from the origin. this will create a nice approximation of a sphere.

now it's spherical. the trick is that once you subdivide the triangles of the icosahedron, you take the normal of each vertex and scale it by the sphere's radius to get the final position. this sphere is made of 1280 triangles and looks pretty good at this scale.

wireframe of 2 recursive subdivisions, not yet made spherical.

the sphere now has texture coordinates, but there is a very obvious issue. I used the formula here https://en.wikipedia.org/wiki/UV_mapping#Finding_UV_on_a_sphere but it creates a seam where u coordinate does a hard jump from 0 to 1 and creates that gross looking result. I don't know if I'm just missing something. trying to tweak the formula has just introduced new distortions so far.

I believe the issue here is that the vertices along this seam need to be duplicated but with different u coordinates, one where u=0 and another where u=1. same position and normals, though. it's tricky to solve because my algorithm has no knowledge of where this seam even is.

I found a solution that wasn't too gross, but not too great either. added about 27 lines of new code. maybe I can improve upon it, but not now. onto the next and hopefully final problem: bad texture coordinates at the poles.

turns out lots of people go down this road and run into the same problem. the solution seems to be to detect the problem by examining the uvs of entire triangles and generating new, fixed vertices. I'll see if I can do that without making my code disgusting.