[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[libcaca] Re: the AAlib competition
> o dithering modes:
> We can already do all of this, except the extra random factor.
Which can easily be added afterward. Not a big deal.
> o showcursor/hidecursor/gotoxy functions for the keyboard cursor. If
> we do something like that, we should be aware of double width chars.
You mean text cursor ? (like good-old MSDOS's edit, or gpm in linux
console ?) that's quite straightforward as well, but we'll need to deal
with "real" cursor, then (thinking about X11, OpenGL, and win32 drivers
mostly).
> o built-in mouse pointer (we have something like that in test/demo
> but of course it only works with X11 and GL).
Same as the above, in fact it must be handled in text, so we only have to
write some hide/show hardware cursors functions to remove arrow and add a
character instead.
> o brightness (0-255) and contrast (0-127) functions for the bitmap
> to text routines, and negative rendering
I guessed (don't have sources to watch right now) it was already done (for
brightness/contrat at least). Or maybe only in the final rendering ?
Negative rendering is easy to write, too, but I don't know if the purpose
of lubcucul is to deal with graphical effects, that's users work.
> o aa_edit: a text edit widget
We already had a discussion about this, it'll need a libcaca driven event
loop, or very piggy code on users side. Or maybe you have a clever idea :)
> o two different bitmap to text routines, one being labeled "fast". I
> don't know the difference yet. But their rendering algorithm
> outperforms ours for various reasons, including the fact that they
> have foreknowledge of the font glyphs.
And in fact their rendering is quite simple. Make the image B&W, if it
isn't already done by the user, and dither if needed. We could maybe make
performances tests on both the libraries, but I guess it'll be hard to
write something faster while we have much stuff to handle at the same
time. But we should make these tests.
> o ability to load external fonts into the engine. Only really useful
> if we allow on-the-fly driver changes.
It'll be a mess. Not all drivers support font customisation, we'll need
"some" (write here ttf (??), png, bmp, real bitmap font format, whatever
you want) loaders, we'll have to deal with unicode (or not). Anyway, as we
already talked about, we'll soon need to embbed a minimal font for
framebuffer/bitmap driver/exporter. Maybe it's time we talk about this in
a deeper way.
> o save formats: nhtml, html, html_alt, ansi, text, more, hp, hp2,
> irc, zephyr, htmlk. I don't know yet what they all do.
*html*: Deals with the many differents HTML format we had before (IE3,
netscape navigator, etc, back in the 90's)
vyhen : didn't found any infos about it. Seems to be a czech word, great,
and I don't know czech. Anyone ? :)
ansi : obvious
text : Simple ascii ouput, no characters attributes (bold, etc)
more : same as text, with attributes in ansi
irc : We all know that
zephyr: "instant messenger protocol and application-suite with a heavy
Unix background", according to wikipedia (didn't knew this one)
hp/hp2 : HP laser jet, small and big font, respectively
So there's not really any stuff to mimic here. I guess we don't care about
hp*, we already have PostScript output. we have IRC, zephyr seems cold
dead, we have ansi, text and 'more' are b&w.
>
> o output drivers: curses, DOS, Linux, slang, stdout, stderr, X11,
> os2vio. No idea what stdout and stderr are for, but they probably
> do exactly what our network driver outputs (slightly improved
> ANSI to work on most terminals).
We have curses, DOS, slang, X11.
Linux driver uses /dev/vcsa* to print raw chars to screen. Quite useless,
as we already have ncurses/slang. Maybe writing an ansi driver ? Don't
know if it is really needed.
os2vio : I don't own OS/2, but that's true we lack this plateform.
stdout/stderr : just printf() the buffer to stdout/stderr. Quite useless
for us.
> As you can see, some of the things we did (ANSI and IRC output) or
> planned to do (text edit widget) aren't that stupid after all. We're
> just 8 years behind :-)
Talking about the text edit widget, it seems they have a (quite ugly)
while(getkey()...) function to deal with it. I'm not fond of this
implementation, as it blocks all other stuff.
My conclusion: We lack somes things (OS/2 driver, cursor handling, font
loading, text widget), but nothing is *really* important, and nothing will
break API. So that's quite a good thing, I'm tired beginning rewriting all
my code each time Sam commits (from ILLEGAL WIFI ACCESS, ALMOST DRUNK WITH
VANILLA RUM !!!) something :)
Not that much work before a freeze \o/
--
Jean-Yves Lamoureux
--
This is the libcaca mailing-list, see http://sam.zoy.org/libcaca/
Trouble unsubscribing? Please contact <sam@zoy.org>
List archives are at http://sam.zoy.org/libcaca/threads.html