Re: FreeType - A TrueType engine

[Tomas Berndtsson <tomas@nocrew.org>]

Guido Flohr <gufl0000@stud.uni-sb.de> writes:

> Am I particularly stupid or are these things really particularly
> complicated on the Atari?  The next thing I need is the xpm
> library for MiNT and I have the same problem to write portable
> routines to display bitmaps.

It's not only the Atari, although bitplanes can mess things up more
than chunky pixels.

> I've been looking around for free code that handles this stuff
> but I couldn't find any.  Have I missed something?
> 
> What I would really like is a library that performs all the nice
> stuff the graphics gurus do in their programs (blitting images,
> dithering in various qualities, color management...) but don't
> like to talk about.  In fact I've already started with such a library.
> I try to design an API which is sufficiently similar
> to the Xlib (to allow easy porting of graphics software) but
> still handles all the peculiarities of the Atari resp. the
> VDI.

libmagick can do a lot of things. It's mainly made for X though, but
can be used elsewhere too. Me and some others are making a graphics
lib for Linux, oFBis, which handles the basic graphical things,
bitblt, lines, pixels a.s.o. We've made a simple picture viewer that
uses libmagick, and it can handle a lot of different formats.

Unfortunetely, it's a bit too magic sometimes, cause you don't really
have much control of what it actually does to the image.

> If this library shall ever run stable I will most probably need
> help.  The biggest problem I currently have is the interleaved
> format of some resolutions.  Am I right that this format is
> only used for color depths of (1), 2, 4, and 8 bits (i.e. the
> standard ST and TT resolutions)?  Has anybody
> got (preferably fast) code that converts bitmaps from the
> "default" (i.e. packed pixels) format to these plane-oriented
> formats?

I have an assembler routine to convert 8-bit packed pixels (chunky)
into 8 bitplanes. I got it from another guy, so I haven't looked into
it much, but it works, and is fast.
http://tomas.nocrew.org/stuff/c2p.tar.gz 

> Another thing I've come across:  The Xlib specification distinguishes
> between "TrueColor" and "DirectColor" visuals.  Can anybody
> explain the difference to me?

In Truecolour, the pixel data is exactly what comes up on the
screen. I'm not sure about Directcolour, but I _think_ it is that you
take each component of the pixeldata (red, green, blue) and look up
those values in a palette to get the actual colour that is put on the
screen. In packed pixels or bitplanes, you have one index that points
out a colour in a palette, but in Directcolour you have three
palettes, one for each red, green and blue.

Please correct me someone, if I'm wrong.

> Last but not least, the xbios functions EgetShift() and EgetGray().
> My edition of Julian's "Profibuch" reads that these functins are
> reserved for TT hardware.  What about newer machines, Falcon,
> Milan, Hades etc.?

It does not exist on Falcon, and most likely not in Milan or Hades
either, unless a software compatibility has been made in those TOS
versions.

AFAIK, those extra bits in the TT shifter doesn't affect the program
or VDI, but only how the shifter interprets the image and displays it
differently to the monitor. I don't know how the VDI in TT's are
handling this.


Tomas - tomas[@.]nocrew.org