Gregory's Server|
11 comments
 Implemented sixel RLE. A 128x128 1-bit image turns into 1.4kb of sixels.  @neauoire kinda fascinating but inevitable that compression plays a part here. rle is so simple but so good. plaintext impl is good for transmission elsewhere, and looks like it is something to support inside the display device itself rather than just being expanded into vram? @maxc I was looking for a way to embed little graphics in the internal files that we make, I didn't want to use paths, and I didn't want to use values that would turn our files into a binary files to the eyes of git. The DCS and ST bytes to escape into sixels mode seems work pretty well for that. @neauoire wanting text diffs for this stuff makes a surprising amount of sense given the size, haha. i think paths can be a useful concept but i appreciate the single file benefits, and if you can have an area of the file where all the big blobs of stuff are put its kinda fine for arco we're up to some more than a thousand png files but the scope of media for uxn stuff is a lil less i think haha  @neauoire the culture of ricing unix desktops implies a permaculture of fermenting uxn desktops @neauoire nice, thanks! and... ugh, disjoint sets. So looks like a screen device writing to a terminal should support both pixel rendering and sixel rendering for reasonable coverage of common terminals. I worry that the frame rate might be unusably terrible when repeatedly overwriting the same square with consecutive frames though... only one way to find out!! @gvv some roms have very small screen sizes, like, try catclock as an experiment. It updates once every second. |
Almost RLE support.