[cells-devel] Building (and patching) FTGL

[Kenneth Tilton]

On Oct 18, 2004, at 10:18 AM, Mark Sapa wrote:

> Ehhhm... As to the Project Builder stuff: I am completely naive to PB, 
> but at the moment
> I am trying to get FTGL to work. First, it seems I have to install 
> cppunit for that... :(
>
> So far my approach to adding the includes and the library has been to 
> select libftgl.a
> in the "Targets" Group, selecting the editor tool, selecting "Search 
> Paths" and then doing
> the obvious thing in the Headers, Libraries, etc. subcategories.
>

Fantastic, it worked. And using Project Builder, which helps because I 
have never spent much time on Unix/Linux and I hope to avoid mastering 
all that as long as possible.

> The funk seems to be that the Project file is expecting the header 
> file names to be all
> UPPERCASE with _subscores_ as in
>
>> #include FT_GLYPH_H
>
> where in my /sw/lib/freetype2/include/freetype2/freetype/
> there is a ftglyph.h.
>
> Maybe if someone was diligent enough to fix all this... ;-)

I see that funny #include, but the build error I was getting mentioned 
"ft2build.h" and once I added a path to that and another path to the 
slightly deeper freetype2 directory project builder was able to build 
everything.

btw, I mentioned to Frank a fix to FTGL which apparently is still in 
testing in an upcoming FTGL 2.1. Here it is.

In FTTextureGlyph.cpp, in the Render method, modify the first few lines 
to look like this:

float FTTextureGlyph::Render( const FTPoint& pen)
{
     //glGetIntegerv( GL_TEXTURE_2D_BINDING_EXT, &activeTextureID);
     //if( activeTextureID != glTextureID)
     //{
	glBindTexture( GL_TEXTURE_2D, (GLuint)glTextureID);
     //}
    ...etc....

The original tried to avoid binding the texture if it was already the 
bound texture, but when one builds a display list this cannot work, 
because all the glGet calls run immediately instead of being added to 
the display list. But the glBindTexture call just gets compiled and 
does not execute. So glget in this case just returns whatever texture 
happens to be bound during the display list compilation (rather random, 
that).

Besides, display lists just include opengl calls, so there is no way to 
build a display list which branches conditionally based on runtime 
values.

A better fix might be to have the application keep track of the last 
texture bound during display list compilation, but the FTGL author just 
went for always binding the texture. My guess is there is no cost if 
one happens to be rebinding the same texture.

Meanwhile, Doh! I just remembered I have to add my FTGLFromC.cpp suite 
of glue routines to FTGL so Lisp can talk to FTGL in "C". This could be 
a little trickier because we also have to publish the new entry points.

kenny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3030 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20041018/b3b9c363/attachment.bin>