2024-09-27 02:02:57 adafruit is very good at documenting their stuff so that you don't have to use adafruit software 2024-09-27 02:03:29 including, often, things like where the chip on the hardware they're selling fails to fulfill all the promises the manufacturer's datasheet makes for it :) 2024-09-27 02:04:24 unjust: `glaze` sounds great! 2024-09-27 02:05:06 works well enough for chucking a rectangle on the screen at arbitrary co-ords so far 2024-09-27 02:05:26 it's a shame sh doesn't have a readbytes() builtin 2024-09-27 02:06:48 it definitely is, it's also a shame that dd wouldn't do repeated transfers of the source data to the destination 2024-09-27 02:07:09 there's the yes trickery that works for that, but it'd be better if dd did it itself 2024-09-27 02:07:29 yes? 2024-09-27 02:08:33 yeah, dd's seek and skip parameters only apply at the beginning of the transfer, not for every block ;) 2024-09-27 02:10:58 for example, to generate a mustard block of 960 * 540 * 4 bytes: yes $(printf "\x55\xcc\xff\x00") | dd of=/tmp/mustard bs=$((960 * 4)) count=540 2024-09-27 02:12:12 to display this mess in the (almost) centre of /dev/fb0 in 1920x1080(x4) mode: glaze /tmp/mustard $((1920 / 4)) $((1080 / 4)) 960 540 /dev/fb0 2024-09-27 02:12:30 oh hey, I didn't realize that dd knew how to convert from Forth block files: dd if=~/dev3/hanoi.blk cbs=64 conv=unblock 2024-09-27 02:13:03 i didn't know that either 2024-09-27 02:14:00 I was looking at the man page to see if it had an option to seek N bytes between each output operation 2024-09-27 02:14:35 I think I'll write a smaller glaze 2024-09-27 02:15:34 i'm sure you'll do a better job than i did 2024-09-27 02:16:18 i started investigating evdev for mouse input today 2024-09-27 02:17:28 evdev is not as nice as you might hope but not as terrible as you might fear 2024-09-27 02:17:43 it's not that bad 2024-09-27 02:18:04 the cheapskate intel framebuffer i have that doesn't support transparency is more of a disappointment, so i'm relegated to dot/block cursors for now 2024-09-27 02:18:57 but i don't think it's worth the hassle of buffering everything then refreshing the whole screen view just for the sake of transparency 2024-09-27 02:24:02 more than anything else i'm interested in getting to a stage where i can perform postscript/html-canvas like drawing operations on the framebuffer from shell script 2024-09-27 02:39:44 and if the operations just rip off postscript names and operand order, they'd mostly just move from the postfix to prefix position and then it might then look like this: https://pastebin.com/LDYHhcZa 2024-09-27 02:44:47 unjust: here's what I've come up with so far; I haven't tested it on an actual framebuffer yet: http://canonical.org/~kragen/sw/dev3/uglaze.c 2024-09-27 02:45:41 the shell postscript looks awesome 2024-09-27 02:47:16 the credit goes to a chatgpt-backed puzzle bot in another channel that i coerce into generating random postscript flyers when i get bored 2024-09-27 02:47:16 buffering everything and refreshing the whole screen view is indeed worthwhile for transparency, which goes a bit beyond what uglaze can do, byte-oriented as it is 2024-09-27 02:48:33 do you have some test data in mind for running through uglaze? 2024-09-27 02:50:02 well, I was thinking that it should be capable of, for example, drawing a character glyph from a font into a PPM P6 image, or drawing a window onto a framebuffer 2024-09-27 02:50:53 with two more parameters, you could use it to read a glyph from a PPM P6 glyph atlas and draw it into a PPM P6 image 2024-09-27 02:52:01 i'm looking at a reference for that format to understand that 2024-09-27 02:52:08 right now it copies a contiguous segment of bytes starting at the beginning of its input, but to copy a rectangle out of a glyph atlas it would need to seek to the beginning of the glyph in its input and then between each line 2024-09-27 02:52:39 oh, my reference is My Very First Raytracer. Here's the file format: 2024-09-27 02:53:35 static void output_header(int ww, int hh) { printf("P6\n%d %d\n255\n", ww, hh); } 2024-09-27 02:53:38 static unsigned char byte(double dd) { return dd > 1 ? 255 : dd < 0 ? 0 : dd * 255 + 0.5; } 2024-09-27 02:53:41 static void encode_color(color co) { putchar(byte(co.x)); putchar(byte(co.y)); putchar(byte(co.z)); } 2024-09-27 02:53:46 static void render_pixel(world here, int ww, int hh, int xx, int yy) { encode_color(pixel_color(here, ww, hh, xx, yy)); } 2024-09-27 02:53:52 output_header(ww, hh); 2024-09-27 02:53:52 for (ii = 0; ii < hh; ii++) 2024-09-27 02:54:26 thanks 2024-09-27 02:54:29 I guess byte() and pixel_color() are not really part of the format 2024-09-27 02:55:12 but that's basically it: P6\n%d %d\n255\n, then w×h×3 bytes of R, G, and then B, one byte each 2024-09-27 02:55:57 I think there may be another option for 255, and some amount of flexibility about the amount of whitespace on those three header lines 2024-09-27 02:56:28 is it fixed at 24-bit colour depth, or is there a flag that declares the pixel formaT? 2024-09-27 02:56:40 I think that's the 255 2024-09-27 02:56:57 the authoritative reference is 2024-09-27 02:57:10 cool, that's the one i was looking at 2024-09-27 02:57:37 that format would be easy enough to use for 24-bit framebuffers, as-is, you'd just skip over the header and write it the remainder directly to the fb 2024-09-27 02:57:50 well, not really 2024-09-27 02:57:51 provided your fb is using the RGB order 2024-09-27 02:57:56 right 2024-09-27 02:58:03 but none of them do, and they're all 32-bit 2024-09-27 02:59:30 yeah, apparently 255 is "Maxval" and if it's more than 255 each component is two bytes instead of one 2024-09-27 03:00:18 I mean there are also 16-bit framebuffers out there. but so far I haven't found one where pixels start at multiples of some odd number of bytes like 3. they must have existed in the 90s 2024-09-27 03:02:49 I don't think the PPM format can really handle 16-bit framebuffer formats that have more bits for green 2024-09-27 03:03:02 as in RGB565? 2024-09-27 03:03:19 yes 2024-09-27 03:03:45 I mean I guess you could multiply your R and B components by 2? 2024-09-27 03:04:35 you already have to pad them with zeroes on the left, you could pad them on the right too. but if you're doing that maybe you should just left-justify all three components and set maxval=255? 2024-09-27 03:10:53 so far i've just used BMPs stripped off their headers, with pixel data stored in BGRA 2024-09-27 03:10:53 s/off/of/ 2024-09-27 03:11:51 it's easy enough to keep headerless copies around, if you can tolerate the large file sizes - but it's also easy enough to skip over the header and retain the ability of being able to edit them in something like gimp 2024-09-27 13:01:21 BMPs should be fine too 2024-09-27 14:53:22 unjust: https://github.com/jhswartz/usx/ has evaporated? 2024-09-27 15:53:34 xentrac: i can recondense it if you need it 2024-09-27 15:59:25 i had changed the repo visibility because i didn't sanitize, or just wipe out, the flash dumps from the donor phone 2024-09-27 16:00:43 the issue there is that people start asking unfriendly questions when cloned handsets start appearing on their GSM networks, should anyone attempt to flash those to their own phones 2024-09-27 16:11:44 oh, I see 2024-09-27 16:12:01 well, I was interested in learning more, but I don't *need* it in any sense 2024-09-27 16:13:26 it's np, i'll create it 2024-09-27 16:13:41 again 2024-09-27 16:16:35 oh awesome :) 2024-09-27 16:19:26 it should be accessible again 2024-09-27 16:20:02 thanks! 2024-09-27 16:20:07 looks like i had confused it with another directory, because this one actually didn't contain the dumps 2024-09-27 16:21:23 what's fdl/sc6531efm_nokia105_0x14000000_fdl2.bin? 2024-09-27 16:21:44 second stage firmware loader 2024-09-27 16:21:52 aha, cool! 2024-09-27 16:22:08 I was thinking about blitting from the shell 2024-09-27 16:22:50 those are often signed by vendor, so you can't always cut them out of arbitrary firmware dumps for other phones with the same SoC 2024-09-27 16:23:48 what do you think about ./sprite fb.spig 5x8+15+8 +11+2 5x8+35+8 +16+2 < myfont.spig? 2024-09-27 16:24:26 where .spig is a raw RGBA image format and ./sprite opens fb.spig read/write in order to alpha-composite into it 2024-09-27 16:25:27 you could put your entire display list in a single command line if it's all drawn from the same texture atlas 2024-09-27 16:26:07 sprite.c is definitely going to be more complex than http://canonical.org/~kragen/sw/dev3/uglaze.c 2024-09-27 16:26:26 I shouldn't say "raw RGBA image format". an uncompressed RGBA image format with a header 2024-09-27 16:27:05 that way you don't have to specify the raster width on the command line 2024-09-27 16:27:25 what are names of each of those arguments? 2024-09-27 16:27:32 +the names 2024-09-27 16:29:05 texture atlas sounds like an interesting concept 2024-09-27 16:29:15 that's a collection of adjacent sprites? 2024-09-27 16:36:09 yeah, a spritesheet 2024-09-27 16:37:01 5x8+15+8 is a source rectangle, and +11+2 is a destination location at which to composite it. 5x8+35+8 is another source rectangle, and +16+2 is a destination location for it 2024-09-27 16:37:01 for font rendering, assuming there's just one face and scale available (take it or leave it), is there a more effective approach to symbol/glyph retrieval than referencing a lookup table of ordinals to get the byte offset of the origin of each of their respective glyphs in the spritesheet? 2024-09-27 16:38:24 effective? I don't see how anything could be more effective than that; it works perfectly 2024-09-27 16:39:13 but I was thinking it might be useful to think in terms of rectangles made of pixels instead of just a byte array 2024-09-27 16:39:27 i've only ever been a consumer of libraries that dealt with this level of rendering, so i'm pretty sure my initial ideas/approaches are often sub-optimal 2024-09-27 16:44:49 I'm no expert myself 2024-09-27 16:45:46 for a fixed-width font you could just do something like "${width}x$height+$(($idx * $width))+0" if it's all on one line 2024-09-27 16:46:26 for http://canonical.org/~kragen/sw/dofonts-1k.html I went with a slightly more elaborate approach in order to make the font image a less unwieldy aspect ratio 2024-09-27 16:47:05 fi%16*4, ~~(fi/16)*6, where 6 is the height, 4 is the width, and 16 is the number of glyphs per line