[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[libcaca] Re: the AAlib competition
On Fri, Mar 24, 2006, jylam@lnxscene.org wrote:
> > 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.
Well it means adding a function, which means an API change. So better
think about it before.
> > 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).
Yeah, some drivers will need an emulated cursor. Not that difficult.
> > 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.
It looks too much of a hassle to me anyway. The user can already
see the mouse cursor, and if the programmer really wants a nice mouse
cursor, he can blit a sprite or a canvas at the mouse coordinates. Maybe
we could just think of something to hide the main cursor in drivers that
support the feature.
> > 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.
We just have gamma for now. But the rest isn't very hard to do.
> > 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 :)
Or we can just hook something at the end of caca_get_event that
hijacks keyboard events if the text widget is active.
> > 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.
Well, it's not that simple. They have a best-match glyph selection
algorithm that not only matches the overall brightness of the area but
also its shape.
> > 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.
Indeed.
> > 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.
I see one interest in the Linux driver, which is that it does not
require an extra library.
--
Sam.
--
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