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