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