Done. Still sorting out some issues with the Quicktime Texture stuff as I'm trying to get it running faster, and capable of running with an alpha channel or at least a transparent color. I may give in and just release what I have since its causing me grief (and because there is another OSX seed available and there never is a guarantee this stuff will work from seed to seed ).

fire up what u have and i will take a look- and ask some dudes i no about ways we can make it run alittle faster. it seemed to me that QuickTime was doing alot of processing to get its content into the QTImageProducer.

Done. Still sorting out some issues with the Quicktime Texture stuff as I'm trying to get it running faster, and capable of running with an alpha channel or at least a transparent color.

Any word on this? I just hit a snag with the version of this loader i'm using - I need to generate a font texture at runtime, and was hoping to use the loader to do the heavy lifting of converting a BufferedImage into a GL Texture. Unfortunatly this doesn't seem possible without some reworking here and there.

I'm guessing you've already hit and worked around this problem if you're working on Quicktime animation, is it possible to save myself some time by getting my hands on your current version? And then the font generation can be released to everyone who wants to use it

Yeah I can zip up what I have, but its not a good base to build from. 10.3 is releasing new builds very rapidly and I find myself reinstalling more than I do anything else at this point so I haven't had a chance to pick it back up. My other dev box is a WindowsXP box which apparently has suffered a hard drive crash so at the moment I'm in a pause until I can recover the files off the Window box.

I plan to pop the drive and attach it to an external Firewire port and see if the Mac can extract some data off the drive (code mostly). I didn't mention it because I didn't want to succomb to the shame of not checking code into CVS Thanks for making me bring that into the open

I found that it was pretty simple to hack together a simple solution, just simply passing a buffered image in with the normal loading parameters, and assuming this is null if loading from disk is needed.

FWIW, I just started trying to use these, and on the compile I get the following warning about them (using Java 1.5 -- I've gathered that this warning is nonexistent in 1.4.x):

TextureLoader.java:80: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type java.util.HashMap

I dunno if this is a big deal, though it doesn't seem to be. Also, Is this still kind of the "definitive" texture loading group for JOGL? I haven't been able to find anything else that looks as complete.

--Scott

Quote

For completeness, Troggan has provided update versions of my loaders that fix the texture size bug (e.g. it now copes with wierd shape images) and also removed depedancy on my GameFrame code

Has anyone else used gregory's texture loader stuff for PNG files that have transparency in it?

I can only assume the PNG format can have alpha or not alpha in the picture file. I'm having no problems with some PNGs I've gotten from (nehe) lessons, but with some i've got (for fonts for example) that have a transparent background, they load all screwy.

I'm finding (from the initially posted version of the code) the pcitures generally end up fairly corrupted (a lot of vertical lines over the basic picture). I've tried RGB and RGBA for the texture type.

I'll be the first to admit I generally don't know a great deal about graphic formats, athough I'm sure I "should" take the time to learn as I'm sure it's relatively simple.

Any suggestions would be great.

Greg.

ps. most of the links in previous posts in this thread no longer work, so i could grab any other code samples identified.

Thanks for the links. I've plugged in the convertImage... routing into the original code and took out the source pixel type as you've done, and all is happy now with my transparent texture fonts.Mind you, it also helped that I hit myself with a big stick when I remembered to make sure the pictures I was trying to load where n^2 height/width, which they weren't! That explains why they were always blank!

i'm currently porting the postet files to my own application. we are using a sever <-> client concept, where the server loads the textures from a db and then transfer them to the client. so i will split both files into a version without OpenGL (for the server) and a conversion + binding loader/manager on the client side.

currently i'm wondering, if i save the byte array in the db or the real file...

Yeah I can zip up what I have, but its not a good base to build from. 10.3 is releasing new builds very rapidly and I find myself reinstalling more than I do anything else at this point so I haven't had a chance to pick it back up.

have you ever released this code? Or, has aNt optimized the QT loading? I need to do exactly the same thing and it would save a lot of time if the code that loads QT stuff (in its most updated form) was accessible.

the movie loader was slow because we had to convertusing a QTImageProducer. Seems Apple my have dropthat little class with there newer QTJ version.

I will have another look at it to see if we can use RawImageEncoders. At the end of the day QT still needsto uncompress the media so we can then hand it toGL. QTJ doesnt have the call to output the Data to agiven format (its in the ObjC/C headers- Apple just didntport it). So we have to find other tricks to do the samething- these seem to be slower then doing the 'Applehave done it us' that to ObjC dudes get.

shame we miss out If anyone at Apple wants to tellus a trick to pull this off fell free.

i just threw together a 'proof-of-concept' i was thinking about for some time now.

after having a lot of trouble with the, as of now, crappy QTJ API i finally figured out a way to use the native QT API through the JNI. as mentionened above the code is more of a 'proof-of-concept' and since i have not much experience with C/CPP i didn t manage to come up with a windows version ( maybe someone can help ). it s just osx.

the basic concept is to get rid off the, especially under osx, annoying copying of data from native to java to native to opengl and rather leave all the heavy data pushing in native world where it belongs.

i was really suprised to find out that when suppling a valid opengl context from jogl, you can call 'native' opengl functions via JNI from native code. i m not sure if this is valid, whatever that means, but i tested it under osx on several occasion and it seems to be robust.

with that knowledge i wrote ( and snipped of course ) a little wrapper around the native QT API that would simply allocate some memory, let quicktime write into this memory and copy it to opengl, all on the native side. the java/jogl part would just controll the whole process. which is creating, playing, looping movies etc.

it still seems a bit like blackmagic to me and maybe is. i would be happy to get some feedback and even better some improvement on this approach.