Function for plotting text along a circular arc. The code exists in a demo, and can just be migrated into the library.
Alternate algorithm for the rasterizer that uses a smaller buffer but imposes a limit on the complexity of the shapes you can plot in a single fill operation. This would be useful when someone mostly just wants very large numbers to show the time and they are running out of memory.
Functions to plot simple “stroked” shapes like a straight line segment of a circular arc segment.
I’ve published an alpha version of a new tool for creating .ffont and .fpath resources for fctx. It is a Python tool and you should be able to install it with uv much like pebble-tool.
uv tool install fctx-tool
There are currently two commands available, font and paths.
fctx font my.ttf my.ffont [0-9:APM] for example will create a font with the glyphs 0-9, colon, and the letters A, P, and M.
fctx paths my.svg paths will create an .fpath file in the paths directory for each path element found in my.svg. The output file name will be taken from the id of the path element.
Improvements to the functionality and ergonomics of the tool will be driven by my own usage and the feedback I get here.
Haha, I suppose it does. Does pebble-fctx-compiler require the paths to be in defs? It’s been so long since I used it. When I got back into watch coding recently, I just made a new tool because I had it with javascript.
I must have thought that made sense for some reason at the time.
Anyway, please let me know if there are workflows that make sense for you that I could support.
I think it would make more sense to just take any path element in the regular svg body instead. Though this tould be a breaking change, I suppose. Maybe add an argument that lets you specify the parent element or something like that?
So are you meaning you only want some of the paths in the file to be converted, and you would have those grouped together under a parent element/layer? I could do something like that, yeah.
Yeah. This would also let it be backwards-compatible with the old compiler, since you’d be able to specify the defs tag as the parent tag to replicate the old behaviour.
Oh awesome! I saw there’s a note about AA not working on routd in BW mode. The Round wasn’t retdering properly specifically when I turned off AA in colour mode on the Round. I just switched to using AA, so you’rl have to turn that off again to see the rendering bug.
Ohhh…. okay. I was just trying to figure out why I didn’t see the glitch when I built your code. I hadn’t caught that detail that you were using bi-level rendering on the color screen. That makes a lot more sense now. I just assumed color == anti-aliasing because why wouldn’t you? Actually, why didn’t you? Meaning, I’m curious why you didn’t want to use anti-aliasing.
Anyway, this gives me a much better idea what is going on. If I recall, clipping in the bi-level renderer was more complex because there are 8 pixels in every byte and the edges of the round display cut between byte boundaries, so I just punted on that work. I’ll go take a look and re-educate myself and see if I think I can get it working.
I originally turned it off because I didn’t have any overlap in the different colours of my SVG so it made holes in the graphic so instead of adding a little bit of overlap I decided it wasn’t a problem for now and turned off AA lol
Ahhh I see. I saw the warning about BW mode on Round in the readme, but I thought that meat there was a separate mode that only rendered in black and white
@Flynn found a compile-time issue building fctx with the latest Pebble SDK, which looks like a result of using a newer C compiler which is flagging more warnings for dangerous code.
Here is the error Flynn encountered:
../src/c/fctx.c: In function 'fctx_draw_commands':
../src/c/fctx.c:832:24: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
832 | fixed16_t *param = (fixed16_t *)*&cmd->params[0];
| ^
cc1: all warnings being treated as errors
And here is the change to fctx.h line 125 that resolved the error for them:
fixed16_t params[] __attribute__((aligned(2)));
I have to admit that I don’t entirely understand that error or the fix. But that is not my first concern because I get a different error when I compile.
../src/c/fctx.c: In function 'fctx_draw_commands':
../src/c/fctx.c:807:40: error: taking address of packed member of 'struct FPathDrawCommand' may result in an unaligned pointer value [-Werror=address-of-packed-member]
807 | fixed16_t* param = (fixed16_t*)&cmd->params;
| ^~~~~~~~~~~~
cc1: all warnings being treated as errors
I am currently working to figure out how to correct this code. Well, I am trying to figure out how to satisfy the compiler that this code should work just as well as it always has. Flynn’s change doesn’t fix the error for me and my compiler. I’ve got plenty of experience (decades) with C pointer work, but I don’t really understand why the newer compiler has this, um, viewpoint, regarding what I’m doing here.
Okay, quick follow up, and slightly embarrassing. Flynn’s fix does, in fact, satisfy the compiler. As does simply removing the __packed__ attribute from that structure, which was unnecessary.
I was editing the wrong copy of fctx.h (the one from the dist folder) and so not really changing anything, of course. I blame vscode, haha, oy.
I currently use sed to wrap the paths in a defs tag