From: Shawn H. <Sh...@ta...> - 1997-09-22 02:51:41
|
Dominic Cooney <co...@ho...> writes: >Earlier this year I wrote some antialiasing routines for text >(http://www.ozemail.com.au/~coonsta/text_a.html) and they generated some >interest. They're terribly slow but I plan to improve them. Actually I was thinking about that, and I have some ideas how they could be made faster... The current method of repeatedly drawing a translucent pixel for varying degrees of solidity works well, but isn't the fastest approach in the world. It would be much nicer if the drawing could be done with draw_trans_sprite(), and that would be quite possible if you set up the color mapping table so that it uses the sprite color as an alpha value to interpolate between the current screen color and some fixed text color, eg. you could build a lookup table that would draw antialised white text without any trouble at all. To be useful, though, the routines obviously need to support different colors of text without an entire mapping table per color, and I think I know how that can be done. You don't need a full 256 levels of transparancy for text: in fact I think four would be enough (blank, solid, and two antialias levels). Out of a 256 color palette, that would give you enough room in the lookup table to store transparancy info for 64 different text colors, with 4 levels of alpha in each. Obviously the bitmap data in the font would use colors 0-3, but it could be shifted alnog to use a different part of the table simply by offseting the table pointer, so the correct range of colors would be used. I haven't explained that very well, and I've no idea how you could wrap it up into a nice clean API, but I'm pretty sure that it would work. What do you think? Speaking of antialised fonts, I recently discovered (while grabbing a Katakana character set for use in Extreme-G, but I'm sure the same thing will apply to Latin characters...) that the antialiased output from ttf2pcx looks a _lot_ better if you run a sharpen filter over it! >Anyway, this is a call for comments about implementing truetype font >support as an add-on for Allegro. Sounds good to me! It certainly has a very high "coolness" value, and if it can be done fast enough (maybe caching the most recently used couple of fonts in bitmap form?) I think it could be a useful addition... >I mean, if Microsoft programmers can implement it then it can't be >_that_ hard, right? Actually I have a feeling that Microsoft bought the code in from Adobe or someone like that... >Apparently Adobe, Microsoft and Apple and some other giant has agreed >on a new standard called OpenType which is completely different from >the old TTF standard: This might mean truetype fonts become really >cheap or it might mean they disappear completely. I don't think that should be a worry: there are enough truetype fonts around on the web that even if Microsoft stopped using them tomorrow, there would still be plenty around for people to download and use... I might be totally wrong about this, but I have a sneaking feeling that POVRAY and load in and render truetype fonts. If so, it might be worth having a look at how they did it... -- Shawn Hargreaves - sh...@ta... - http://www.talula.demon.co.uk/ Beauty is a French phonetic corruption of a short cloth neck ornament. |