Great, looking forward to see the results 
Kev
I have a question and I’m rather hesistant to put it here seeing my limited grasp of opengl and its internal mechanisms.
But anyways let me come out with it and bite on my fingers later.
Here’s the deal: I’m writting my own texturing class that takes png, gif and jpg image and dumps em into arrays representing the ARGB channels.
Assuming that opengl takes bytes to create textures, I think it might be alright to modify my following code (used it to show displacement map in a 2D applet) so that it creates byte array instead of int and use em in the said process.
import java.awt.*; //Used for Image and Color's definitions
import java.awt.image.PixelGrabber; //Defines the pixelGrabber
class grabPixels //This class will grab the texture's and heightmap's pixels
{
int[] r,g,b, //Red, green and blue components of every pixel grabbed
texels; //This array will hold the pixels of the texture image
point3f[] point; //This array holds the image's pixels as 3D points
public void initImage(displacement_map mc){ //Setting up the arrays' sizes and converting the pixels into 3D points
int size = mc.image_w*mc.image_h, //Size of the arrays
R = 0,
G = 0,
B = 0, //Temporary red,green and blue components of a pixel
pointer= 0; //This will point out the current pixel we're working on
mc.pixels = new int[size];
texels = new int[size];
g = new int[size];
b = new int[size];
r = new int[size];
mc.normal = new vec3f[size];
mc.z = new float[size];
point = new point3f[size];
getPixels(mc.map ,mc.pixels,mc.image_w,mc.image_h);
getPixels(mc.texture,texels ,mc.image_w,mc.image_h);
for(int a=0; a <mc.image_h; a++)
for(int i=0; i <mc.image_w; i++){
R = (mc.pixels[pointer] >> 16) & 0xFF;
G = (mc.pixels[pointer] >> 8) & 0xFF;
B = mc.pixels[pointer] & 0xFF;
r[pointer] = (texels[pointer] >> 16) & 0xFF;
g[pointer] = (texels[pointer] >> 8) & 0xFF;
b[pointer] = texels[pointer] & 0xFF;
point[pointer] = new point3f((float)i,
(float)a,
(mc.z[pointer] = (float)(R + G + B)/12f));
pointer++;
}
mc.normal = new normals().assignNormals(point,mc.image_w,mc.image_h,true);
System.gc();
}
public int[] getPixels(Image bumpThis,int[] getPixNum, int image_w, int image_h)
{
try{
new PixelGrabber(bumpThis,0,0,image_w,image_h,getPixNum,0,image_w).grabPixels();
}
catch (InterruptedException e) {}
System.out.println("Extracting picture's pixels");
return getPixNum;
}
}
Any comments on that one?
The code posted above is rather old and I don’t feel like tweaking it any longer so please don’t pay much attentions to the errors found in there.
Yes - don’t bother 
save yourself some time and grab the files linked a couple of pages back. You’ll have all the image support you listed up and working in minutes 
Unless you’ve got a really good reason you need your own version…?
Well I’ve been using the fine work written by Mr Greg up to now, but I feel like having something that’s been coded from scratch all by myself ;D
Call it “re-inventing the wheel” but that’s how things work out for me ;p.
Btw Greg, do you mind if I play around a bit with your code and add support to TGA images and potentially bmp?
Got something very basic to work correctly
class load_image
{
java.awt.Image tex;
byte[] data;
int width,
height,
pixels[];
load_image(){
destroy();
}
void generate_texture_info(String texture_name, int type){
try{
tex = java.awt.Toolkit.getDefaultToolkit().getImage(texture_name);
}
catch(NullPointerException e){
System.out.println(e);
}
while(width <= 0 || height <= 0){
width = tex.getWidth(null);
height = tex.getHeight(null);
}
pixels = new int[width*height];
extract_pixels();
switch(type){
case net.java.games.jogl.GL.GL_RGB:
data = new byte[pixels.length*3];
for(int i = 0,a = 0; i<pixels.length; i++, a+= 3){
data[a+0] = (byte)((pixels[i] >> 16) & 0xFF);
data[a+1] = (byte)((pixels[i] >> 8) & 0xFF);
data[a+2] = (byte) (pixels[i] & 0xFF);
}
break;
case net.java.games.jogl.GL.GL_RGBA:
data = new byte[pixels.length*4];
for(int i =0,a = 0; i<pixels.length; i++, a+= 4){
data[a+3] = (byte)((pixels[i] >> 24) & 0xFF);
data[a+0] = (byte)((pixels[i] >> 16) & 0xFF);
data[a+1] = (byte)((pixels[i] >> 8) & 0xFF);
data[a+2] = (byte)( pixels[i] & 0xFF);
}
break;
default: System.out.println("Unrecognized GL format or not supported yet ^_^");
}
}
void destroy(){
tex = null;
data = null;
width = -1;
height = -1;
pixels = null;
}
void extract_pixels(){
try{
new java.awt.image.PixelGrabber(tex,0,0,width,height,pixels,0,width).grabPixels();
}
catch (InterruptedException e) {}
}
}
Mr Greg I dunno why but when I load up jpg textures via your excellent loader, the color seems a bit brownish or indfidel to the origin.
However all those syndromes disappear at once when I deal with pngs.
Can you check that out please
Edit:
Here’s a screenshot and a simple demo as well
http://www.realityflux.com/abba/loader.jpg
http://www.realityflux.com/abba/Simple%20Texture%20Loader.zip
Tested with gif, png and jpg ;D
Edit2: oops mixed up the alpha and red channels …fixed
Don’t worry about making cnanges to the code - we can all learn from whatever changes you make. Also don’t worry about asking questions - even if they seem naive. For every question you don’t ask, there are probaby 10 other people out there who have the exact same question who just haven’t asked it.
Asking questions - even stupid ones, is how we learn. Its unfortunate that as we get older we start to get embarassed about asking questions. If you don’t know the answer to a question - its not a stupid question ;D
I’ll also take a look at your JPG issue (I never use them), but its likely because they aren’t in the same texture format as what I load in. Most likely some of the channels of RGB are in a different order.
Thank you Sir, I appreciate your response :).
Ah the wonders of unregistred image processing-software, all good all good ;D
The label that shows up in the left corner of any image manipulated with “Image Converter and Editor” was an indicator that java acutally flips images up side down before rendering them to the screen…or that’s what I think it does(maybe it’s the way pixels are mapped in windows…shrugs).
I had to come up with a trick to reverse the effect.
class load_image
{
java.awt.Image tex;
byte[] data;
int width,
height,
pixels[];
load_image(){
destroy();
}
void generate_texture_info(String texture_name, int type){
try{
tex = java.awt.Toolkit.getDefaultToolkit().getImage(texture_name);
}
catch(NullPointerException e){
System.out.println(e);
}
while(width <= 0 || height <= 0){
width = tex.getWidth(null);
height = tex.getHeight(null);
}
pixels = new int[width*height];
extract_pixels();
int pointer =0;
switch(type){
case net.java.games.jogl.GL.GL_RGB:
data = new byte[pixels.length*3];
for(int y = height -1; y>=0; y--)
for(int x = 0; x<width; x++){
data[pointer+0] = (byte)((pixels[y*width + x] >> 16) & 0xFF);
data[pointer+1] = (byte)((pixels[y*width + x] >> 8) & 0xFF);
data[pointer+2] = (byte) (pixels[y*width + x] & 0xFF);
pointer+=3;
}
break;
case net.java.games.jogl.GL.GL_RGBA:
data = new byte[pixels.length*4];
for(int y = height -1; y>=0; y--)
for(int x = 0; x<width; x++){
data[pointer+3] = (byte)((pixels[y*width + x] >> 24) & 0xFF);
data[pointer+0] = (byte)((pixels[y*width + x] >> 16) & 0xFF);
data[pointer+1] = (byte)((pixels[y*width + x] >> 8) & 0xFF);
data[pointer+2] = (byte)( pixels[y*width + x] & 0xFF);
pointer+=4;
}
break;
default: System.out.println("Unrecognized GL mode or not supported yet ^_^");
}
}
void destroy(){
tex = null;
data = null;
width = -1;
height = -1;
pixels = null;
}
void extract_pixels(){
try{
new java.awt.image.PixelGrabber(tex,0,0,width,height,pixels,0,width).grabPixels();
}
catch (InterruptedException e) {}
}
}
Updated the package as well
[quote]Yeah I took a look at what you guys had done and its good stuff. I spent some time putting in AnimatedTextures and QuicktimeTexture extends the AnimatedTexture stuff. All in all - happy happy stuff
[/quote]
I noticed that the TextureLoader uses the actual resource name/filename as the key for the texture objects, I’ve found it better in the past to asign an abstract name to images thats independant of the filename.
The actual changes are minimal (add name string to Texture, change key in TextureLoader) but its quite handy. Especially for things like tilesets where you can switch the actual resources but keep the names the same.
If you’re making changes you might want to bear it in mind, after all theres no reason that people can’t get the old behaviour using the resource name for both
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 ).
dude the seed is prity much all there…
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.
all tops stufff…
[quote]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.
[/quote]
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 >:(
;D
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.
Best of luck salvaging code from the HD, hardware failures are a pain >:(
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
He’s posted them here:
[/quote]
This is merely a Java 1.5 warning related to the new generics stuff.
You’re now “expected” to declare and instantiate collection style classes with a content specification.
eg.
Collection myIntegerCollection = new ArrayList();
I won’t go into the generics’ spec any further… happy reading. 
Hi all.
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.
The other texture loading example is available in the Wiki at:
http://wiki.java.net/bin/view/Games/TextureLoadingExample
Kev
Hi Kev.
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!
Greg.