[notcurses things & things]

[Nick Black]

----- Forwarded message from José Luis Cruz <jose...@andamira.net> -----

Date: Sun, 1 Nov 2020 23:13:11 +0100
From: José Luis Cruz <jose...@andamira.net>
To: Nick Black <dankam...@gmail.com>
Subject: notcurses things & things

Hi Nick, how are ya?

I'm thinking probably this week I'll continue working on the notcurses
rust bindings, I'm feeling more mental space for this recently.

I also wanted to ask you, how would you do to show an image filtered
with the chosen blitter, but reading it from an array instead of from
a file? Do we need new API functions for that?

I'm very excited with the new sexblitter and the future sixel support...

The thing is in my new laptop using the same OS and same packages I
believe, I can't see the new unicode 13 simbols for legacy computing
in Alacritty, only in xfce4-terminal .... I had to manually install
this font which I didn't had before. But I played so much with the
font system that I may have done some additional thing at the time...
The linux font system can be seriously a PITA.

I saw you also experience similar shenanigans
https://github.com/dankamongmen/notcurses/issues/137#issuecomment-711677973

And I was wondering since I intend to publish games using those
unicode characters and more... how could I make sure that people will
be able to see them?

I think the most bulletproof and multiplatform-ready method would be
to supply a good enough terminal binary supporting the needed
functionality and preconfigured to load the provided font including
all the needed unicode characters... What do you think?

Ideally I should be able to include multiple fonts and configure the
terminal to use them all in a priority list but I don't think that
terminal exists... nor with sixel support.

bye!
--
José Luis Cruz

----- End forwarded message -----

José Luis Cruz left as an exercise for the reader:
> I'm thinking probably this week I'll continue working on the
> notcurses
> rust bindings, I'm feeling more mental space for this
> recently.

[wild cheers] i saw the subject and feared you were going to
say "i'm tired of your ridiculous grandstanding ass, and will
play the espontáneo elsewhere."

> I also wanted to ask you, how would you do to show an image
> filtered
> with the chosen blitter, but reading it from an array instead
> of from
> a file? Do we need new API functions for that?

https://notcurses.com/notcurses_visual.3.html

an array can be fed in with ncvisual_from_rgba() or
ncvisual_from_bgrx(). you can create an ncvisual from a plane's
contents with ncvisual_from_plane(). that's handled all the
cases i've been able to come up with.

examples can be found in the dragon demo. i'm plotting a
Lindenmayer string system there, and don't want to have to worry
about compensating for the particular blitter etc. so i build up
an ncvisual via ncpixel_set_{r, a}() operations, then render
that:

https://github.com/dankamongmen/notcurses/blob/master/src/demo/dragon.c

in normal.c, i use ncvisual_from_plane() to pick up the
mandelbrot fractal i've drawn and rotate it. the code is kinda
terrible here; i was drinking sterno that day or something:

https://github.com/dankamongmen/notcurses/blob/master/src/demo/normal.c

> I'm very excited with the new sexblitter and the future sixel
> support...

sixel isn't supported on anything worth using save xterm, or i'd
have done it much sooner. it also has weird interactions with
text. i actually started last night on `ncls`, which is like
`lsix` except decaying back to our cell blitters in the absence
of sixel support (so it'll actually run for most people). i
think with sexblitter we ought come close enough to not require
sixel. consider a cell of 12 pixels. with sexblitter, you're
able to "address" that in 4 pixel increments. not so shabby.

braille also has issues (you could otherwise trivially step up
to 4x2, 3 pixel increments on a 12-pixel cell). what
"foreground" means with braille varies pretty substantially, but
in no cases is it rectangular regions =[. it's possible we'll
get Kaypro 2x4 mosaics in Unicode 14, in which case i'll of
course jump on that immediately.

further downsides of increasing pseudoresolution via solutions
like this is that you end up having to smash more colors into a
foreground and background, which is lossy at best and calls for
dithering, to which i am kinda philosophically (and
uninformedly, in the American tradition) opposed. also, you're
less and less likely to evenly divide your pixel geometry, with
predictably shitty results.

not sure if you noticed, but sexblitter was written with much
less handcoded crap than prior ones; i've worked out an
algorithm accepting geometry of your glyph set and an ordered
set of symmetric, partitioning glyphs, and it will optimally
blit.

with that said, sixel is hella more efficient in terms of
bandwidth to the terminal. just (last time i checked, to the
best of abilities) not a damn thing supported it. w3m/links
still, AFAIK, do graphics by throwing up an overlapping XBM
window.

so i think i'm gonna polish that, microoptimize the fuck out of
it, and write it up for hopeful publication in CACM.

but yes, the fact that we can render 3x2 in 20% of the cpu
required by mpv TCT to render 2x1 pleases me very much.

> The thing is in my new laptop using the same OS and same packages I
> believe, I can't see the new unicode 13 simbols for legacy computing
> in Alacritty, only in xfce4-terminal .... I had to manually install
> this font which I didn't had before. But I played so much with the

yes, this has been a concern of mine. in the browser, i can't
see these, and they only became available to me at all maybe two
weeks ago. alacritty is weirdly warped with them. i'm thinking
maybe we back away from sexblitter-by-default, at least for
awhile (returning to quadblitter).

> And I was wondering since I intend to publish games using
> those
> unicode characters and more... how could I make sure that
> people will
> be able to see them?

this is an excellent question, one i have considered deeply.

> I think the most bulletproof and multiplatform-ready method
> would be
> to supply a good enough terminal binary supporting the needed
> functionality and preconfigured to load the provided font
> including
> all the needed unicode characters... What do you think?

are you suggesting writing our own terminal emulator? i mean,
sure, yeah, before i die, but i don't have the bandwidth right
now. on the linux console, i reprogram the font tables to add
the glyphs necessary for quadblitter:

https://github.com/dankamongmen/notcurses/blob/master/src/lib/linux.c

i'm thinking something more along the lines of shipping a small
font supplying only a small collection of blitted glyphs, and
install that as a fallback in the system font config. i'm unsure
how/if exactly this gets done.

if you're suggesting like, a docker above, that seems a good
solution for something like a game (i.e. for you), but for
general applicability it won't fly. i'm trying to come up with a
good general solution, but it is a struggle. as i say in the
README:

https://github.com/dankamongmen/notcurses#fonts

--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.