Indeed it did sound a little odd!

I copied by gemcvs folder from my old suse8 machine and did a cvs update, thats it. Here is the linking output:

g++ -o Gem.pd_linux -L/usr/X11R6/lib ../Manips/*.o ../Particles/*.o ../Base/*.o ../MarkEx/*.o ../Pixes/*.o ../Controls/*.o ../Nongeos/*.o ../Geos/*.o ../openGL/*.o -shared -Wl,-rpath,/usr/lib -laviplay -laa -lquicktime -lmpeg3 -lttf -lgltt -ljpeg -ltiff -lpng -lglut -lGLU -lGL -lz -lm -Wl,-shared -Wl,-export-dynamic -lXxf86vm -lXext -lX11 strip --strip-unneeded Gem.pd_linux

And indeed it fails without aalib!

What makefile shoud I look for a reference in? Should I try a new checkout?

B.

tigital@mac.com wrote:

...

On Monday, January 12, 2004, at 12:04 PM, B. Bogart wrote:

...

Hey all,

I got aalib to work (aalib-devel not install grrr)

...uh, when was aalib added to GEM? In what manner is it used? I ask, because it's not implemented on OSX, yet (but the library is available via fink)...

actually i was asking me the same thing. ben, where did you get the sources from ? aalib is by no way supposed to be in the official gem-cvs (not for now).

did you use pd-gem@sf.net ?

mfg.as.dr IOhannes

what are the options for the configure ? ("./configure --help") if you can specify the pd-version (with "--with-pdversion=0.41" then you have a recent copy of the "right" cvs)

Yup thats it, avifile: linux:/store/Data # avifile-config --libs -Wl,-rpath,/usr/lib -laviplay -laa

what does the Base/configLinux.h look like after the configure-process. there should be a line like "#define HAVE_LIBFTGL 1" (if you want ftgl-support). this define defines another one "FTGL" in TextBase.h which does the actual commenting in/out of the correct code.

Yes the FTGL define is in configLinux.h (and GLTT commented out) Look like FTGL does get set in TextBase.h:

# ifdef HAVE_LIBFTGL # define FTGL

So I'm running out of ideas, can I use GLTT rather than FTGL? I tried ./configure --without-ftgl --with-gltt and the compile goes through, but the gem text examples don't work:

error: GEM: text3d: unable to create polygonal font

Doh! The font path in the example 03.ChangeText.pd file is wrong, it should be [font arial.ttf] not [font ../data/arial.ttf]

So I get text now with gltt. So whats the improvement with ftgl?

Thanks Ben

mfg.as.dr IOhannes

...

B.

tigital@mac.com wrote:

On Monday, January 12, 2004, at 02:19 PM, ben@ekran.org wrote:

...

Doh! The font path in the example 03.ChangeText.pd file is wrong, it should be [font arial.ttf] not [font ../data/arial.ttf]

...yeh, definately a problem when ya don't load the font ;-) Btw, this is another sticky spot in the examples when done on osx, because the patches assume that font's are [loadbang]'ed, but that doesn't do the right thing on OSX (need to have an opengl context before creating the gl font representations)...I've been meaning to upload versions of these examples without the [loadbang], or at least with another comment explaining that the font needs to be loaded AFTER the gl window has been created...

and i think(!) it is the same under linux (with ftgl), however, the examples were written for gltt. anyhow, couldn't the font-loading be executed when the gl-context has been established, no matter, when the user clicks/loadbangs the "font"-message. you don't see anything without gl-context, so no one should complain...

...

So I get text now with gltt. So whats the improvement with ftgl?

...very big improvement: extruded 3d fonts! plus the ability to play with character vertices and such...

for me, the most important improvement of ftgl is, that it renders the fonts correctly! under gltt, some letters at special font-sizes (esp. small fonts, like "e" @ 8pts - if i remember correctly) are not rendered at all, resulting in output like "H llo", which is not very useful... (but i guess this could have been fixed with some scaling-tricks)

mf.as.dr IOhannes

ben@ekran.org wrote:

Hey Jamie,

For a tech question, does pix_snap copy the buffer into main memory and then back to the card, or is all the copying done on the gfx card memory? I ask because I imagine putting it all on the gfx card would be very very nice performance wise. (on windows I can run the feedback patch at 128x128@30fps on linux I can do 512x512@60fps, same patch, same machine, go figure. ;)

well [pix_snap] really copies the buffer from the gfx-card to the main-memory and back-again. this is fine if you want to do some image-processing.

if you don't need it, you can use [pix_snap2tex] which keeps the snapped buffer on the gfx-card. (and indeed: you don't need the "mode 0"-message to make your patch work then)

btw: very beautiful

mfg.asd.r IOhannes

On Jan 12, 2004, at 12:48 PM, ben@ekran.org wrote:

I still don't understand pix_texture "mode 0" though, since I also can't get live video to texture on OSX without it. (geforce cards perhaps?)

"mode 0" is power-of-two texturing where the texcoords are in the range 0..1. "mode 1" is for rectangle textures with texcoords from 0..height and 0..width. that's why using 'mode 1' results in the 'One Big Pixel Syndrome'. only a few objects accept the rectangle coords like square, rectangle and cube, and because pix_texture doesn't know which Geos come after it, there is no way to automagically set this flag. a name change might clarify what the flag does. 'texture type ?' 'texture mode ?' ????

the only way to fix this is to rewrite all of the glu based objects like sphere and cylinder to accept whatever coordinate range defined by pix_texture and not assume that it will always be 0..1. i plan to do this in the near term, and will roll it into the vertex array stuff as well. a nice thing about using arbitrary texcoord ranges is that the entire surface is covered by _any_ size texture and there are no more black gaps caused by subtexturing.

cgc

Thanks for the compliment.

B.

On Jan 13, 2004, at 1:44 AM, IOhannes zmoelnig wrote:

probably "rectangle $1" ?

yeah, sounds fine to me. any other suggestions?

we could then turn on/off "special" texturing, like rectangle or client-storage independently, which would also help at debugging.

there's been a 'client_storage $1' message for several months. you have to start and stop rendering manually to have it change though.

just a note about the client storage and DMA stuff on OSX: as it turns out i sorta really fucked it up in a way. the way it works is by eliminating the driver copy of the texture which means that the client app has to protect the buffer data itself. well the GEM way of rendering has pix_film doing all the movie tasking before pix_texture sets up and calls the texture upload, and that creates some problems. you might have noticed some texture corruption on OSX especially when doing any UI actions while a film is playing - that's when GEM is not protecting the buffers. so the near term fix has me writing a new pix_movie object that's coded from the ground up for this special case and it calls the QT tasking _after_ the texturing. so far it works fine, and it will be a good option for those that want to play lots of .movs at once or just get video to screen as fast as possible.

pix_texture is going to have client storage turned off until i figure out a fix. the fix i have in mind is to simply pass the qt movie data as part of GemState, and have pix_texture do the tasking. the might have the added benefit of allowing other objects access to the QT data, and thus avoiding the god-awful 242.film hell of a thousand million messages.

and i have thought of finally rolling in the stupid teapot, this is: copy'n'paste the code from glut so we don't have that dependency any more. what do we need the teapot for ? still a cool complex object for testing, and it is the standard 3d-object.

oh, i thought we decided to get rid of that teapot ages ago? it's funny for demos, but you're right - what's the point? anyway, i have the mesa glu source now and will probably set about doing some of the coding tomorrow. i've got the glu objects and model to change texcoord handling, and pix_movieDarwin to finish up, which could either go in the almost mythical 0.888 or wait.

cgc

mfg.asd.r IOhannes

ben@ekran.org wrote:

...

On Jan 12, 2004, at 12:48 PM, ben@ekran.org wrote:

Ah I understand now, Thanks Chris for taking the time to explain it. Now it makes sense. Would we alias one mode for one texture and the other mode for another? pix_texture as 2^x and pix_texture_rect as rectangular textures? Or a method selector for pix_texture could be "rect 1/0" I suppose part of the root of this is that it should be stated in the pix_source helpfile if the output is rect or 2^x .

in former days we had [pix_texture] (for 2^n-sized pixes) and [pix_texture2] (for non-2^n-sized pixes) however, in terms of usability, we decided to merge this into one object [pix_texture] which would texture all images.

this is meant to be totally transparent to the user (but unfortunately is not)

Only pix_film pix_video output rect textures curretly is this correct?

no, you could load an image ([pix_image]) with non-2^n-dimensions.

This sounds like the best long-term solution to me, I've had a few headaches with black areas using non 2^x textures.

of course

Right on on linux it seems that if the texture is 2^x then those pixels are dropped into a 2^x frame that coveres the whole texture, leaving black, or when switching between 2^x and non 2^x remnants of the last texture... :(

this is only half of the truth. if you have a geforce-card and have installed nvidia's openGL-headers (copy them from /usr/share/doc/nvidia-glx/include/GL (on my debian-system) to /usr/include/GL) and recompile Gem, you have native rectangle-texturing too. (with all the problems like in osX) however, i believe few people (but me ;-)) do so...

mfg.asdr IOhannes