loading time

Try the Intel JPEG Library. I use it and find it very fast.
You can download it here:
http://www.intel.com/software/products/perflib/index.htm

To quickly get started with it, search for EncodeJPGFileFromDIB and
DecodeJPGFileToGeneralBuffer in ijlman.pdf.

Load times depend on more than just file format. Things like amount of free memory, memory speed, hard disk speed, cpu speed, etc all affect it.

Also, jpegs need to be read in and then decompressed, whereas bitmaps just need to be read in. Jpegs wont have as good quality neither.

-----------------------
0wn 0wn 0wn your goat
gently down the pw33n

the textures are all 50 mb big and they are 40 and the biggest resuluton is 1600+1200 (the surface of mars)the textureloading would not be a prob if i can find a way to load text in the opengl engine . when i include text ca 20 lines with 10 words the engine has a performance problem so i would need a solution of this prob too

thanks

they are 50 MB alltogether

and they need 25 seconds(athlonxp1900+,u-dma 100,7200 rpm, 256 ddr)

and 2 minutes(p3 500, u-dma 66,5400 rpm,64 mb sd ram)

and i load :

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);
AUX_RGBImageRec *LoadBMP(char *Filename)
{
FILE *File=NULL; if (!Filename) {
return NULL; }
File=fopen(Filename,"r");
if (File)
{
fclose(File);
return auxDIBImageLoad(Filename);
}

return NULL;
}
.
.
.
.
.
.

bool Status=FALSE; // Status Indicator
AUX_RGBImageRec *TextureImage[30]; // Create Storage Space For The Textures
memset(TextureImage,0,sizeof(void *)*30); // Set The Pointer To NULL

if ((TextureImage[ 0]=LoadBMP("Data/mars.bmp")) &&
(TextureImage[ 1]=LoadBMP("Data/sonne2.bmp")) &&
(TextureImage[ 2]=LoadBMP("Data/merkur.bmp")) &&
(TextureImage[ 3]=LoadBMP("Data/venus.bmp")) &&
(TextureImage[ 4]=LoadBMP("Data/erde.bmp")) &&
(TextureImage[ 5]=LoadBMP("Data/mars.bmp")) &&
(TextureImage[ 6]=LoadBMP("Data/jupiter.bmp")) &&
(TextureImage[ 7]=LoadBMP("Data/saturn.bmp")) &&
(TextureImage[ 8]=LoadBMP("Data/uranus.bmp")) &&
(TextureImage[ 9]=LoadBMP("Data/neptun.bmp")) &&
(TextureImage[10]=LoadBMP("Data/pluto.bmp")) &&
(TextureImage[11]=LoadBMP("Data/saturn_ringe.bmp")) &&
(TextureImage[12]=LoadBMP("Data/korona.bmp")) &&
(TextureImage[13]=LoadBMP("Data/button.bmp")) &&
(TextureImage[14]=LoadBMP("Data/button2.bmp")) &&
(TextureImage[15]=LoadBMP("Data/button3.bmp")) &&
(TextureImage[16]=LoadBMP("Data/light2.bmp")) &&
(TextureImage[17]=LoadBMP("Data/mond.bmp")) &&
(TextureImage[18]=LoadBMP("Data/flare.bmp")) &&
(TextureImage[19]=LoadBMP("Data/erde2.bmp")) &&
(TextureImage[20]=LoadBMP("Data/wolken.bmp")) &&
(TextureImage[21]=LoadBMP("Data/white.bmp")) &&
(TextureImage[22]=LoadBMP("Data/satring.bmp")) &&
(TextureImage[23]=LoadBMP("Data/s1.bmp")) &&
(TextureImage[24]=LoadBMP("Data/s2.bmp")) &&
(TextureImage[25]=LoadBMP("Data/s3.bmp")) &&
(TextureImage[26]=LoadBMP("Data/s4.bmp")) &&
(TextureImage[27]=LoadBMP("Data/s5.bmp")) &&
(TextureImage[28]=LoadBMP("Data/s6.bmp")) &&
(TextureImage[29]=LoadBMP("Data/satri.bmp")))
{
Status=TRUE; // Set The Status To TRUE
glGenTextures(30, &texture[0]); // Create Five Textures

for (loop=0; loop<30; loop++) // Loop Through All 5 Textures
{

glBindTexture(GL_TEXTURE_2D, texture[loop]);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR_MIPMAP_NEAREST);
gluBuild2DMipmaps(GL_TEXTURE_2D, 3, TextureImage[loop]->sizeX, TextureImage[loop]->sizeY, GL_RGB, GL_UNSIGNED_BYTE, TextureImage[loop]->data);

/* // Create Linear Filtered Texturez
glBindTexture(GL_TEXTURE_2D, texture[1]);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, 3, TextureImage[0]->sizeX, TextureImage[0]->sizeY, 0, GL_RGB, GL_UNSIGNED_BYTE, TextureImage[0]->data);

// Create MipMapped Texture
glBindTexture(GL_TEXTURE_2D, texture[2]);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR_MIPMAP_NEAREST);
gluBuild2DMipmaps(GL_TEXTURE_2D, 3, TextureImage[0]->sizeX, TextureImage[0]->sizeY, GL_RGB, GL_UNSIGNED_BYTE, TextureImage[0]->data);

// Create MipMapped Texture
glBindTexture(GL_TEXTURE_2D, texture[loop]);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR_MIPMAP_NEAREST);
gluBuild2DMipmaps(GL_TEXTURE_2D, 3, TextureImage[loop]->sizeX, TextureImage[loop]->sizeY, GL_RGB, GL_UNSIGNED_BYTE, TextureImage[loop]->data);
*/ }
}
for (loop=0; loop<30; loop++) // Loop Through All 5 Textures
{
if (TextureImage[loop]) // If Texture Exists
{
if (TextureImage[loop]->data) // If Texture Image Exists
{
free(TextureImage[loop]->data); // Free The Texture Image Memory
}
free(TextureImage[loop]); // Free The Image Structure
}

thanks for this tip but i dont know how to make a compatiple bmp loader


and i dont understand tip 3



thanks

tne reason glumipmaps is slow is cause it rescales the images with a slow rescale image function.
solution. rescale the images with a faster method i believe theres a new mipmap function out there that is much faster sgis_mipmaps or something or write your own optimized rescaling function or do as AH saiz + rescale the images say with gimp and save those as well thus u read the original size texture + copies of it all the way down to 1x1 off the harddisk

http://uk.geocities.com/sloppyturds/gotterdammerung.html

Also, are you binding the textures? Or are you just loading them all one at a time?

can you just save each scale of the mipmapped textures as seperate images (jpegs preferably) and load them like that?

// God.c
void main() {
WORLD Earth;
LIFE People = Earth.CreateLife(HUMAN);
GiveHope(&People);
delete Earth;
EvilCackle();
}

when i mipmap the textures in this way it takes 2 min at a system what took 20 seconds before

i think thats logical because now i''m loading effectly 30*10 =300 textures

no it doesnt work but i thank you very much for these tips

i''ve a geforce 3 ti 500

it shold work but i''m a bit blemblem

the last possibility:

may somebody post a whole fast bmp loading code with an loading exemple that is not compiled that i can see the system and when i compile it in vc ++ 6.0 it should work allone (please for direct compile) i can better see the system when i can change something and see what happens.

sorry

thanks

Hmm...

One time I made a replacement for auxDIBImageLoad...
I don''t know how efficient it is--seeming I''m a win32 app coder, primarily, and I only play around with OGL in my free time--but it seemed to work good for me.

Here goes:

//this replaces auxDIBImageLoad static BMPINFO *LoadBMP(char *filename) { BMPINFO *bmpinfo; HBITMAP hbitmap = NULL; UINT32 ret; BITMAP bitmap; UINT32 x; BYTE tmp; //load the image from file hbitmap = (HBITMAP) wec_LoadImage(NULL, filename, IMAGE_BITMAP, 0, 0, LR_DEFAULTCOLOR | LR_LOADFROMFILE); #if (err_DEBUG) if (hbitmap == NULL) { DERROR(castle_BADARG, "Invalid filename for bitmap"); } #endif //get descriptor, including width/height wec_GetObject(hbitmap, sizeof(bitmap), &bitmap); ret = ecmem_Alloc(sizeof(BMPINFO), &bmpinfo); if (ret == 0) { UERROR(castle_BMPERR, "Could not alloc memory for bitmap information"); } bmpinfo->width = bitmap.bmWidth; bmpinfo->height = bitmap.bmHeight; ret = ecmem_Alloc(bmpinfo->width * bmpinfo->height * 4 + 1, &bmpinfo->data); if (ret == 0) { UERROR(castle_BMPERR, "Could not alloc memory for bitmap raw data"); } //zero memory space memset(bmpinfo->data, 0, bmpinfo->width * bmpinfo->height * 4); //receive DIB bits into bmpinfo->data wec_GetBitmapBits(hbitmap, bmpinfo->width * bmpinfo->height * 4, bmpinfo->data); //now we begin a 2 step process of changing the data into GL_RGB format //first, swap the order of the image, top to bottom, bottom to top for (x = 0; x < bmpinfo->height * bmpinfo->height * 2; x++) { tmp = *(bmpinfo->data + x); *(bmpinfo->data + x) = *(bmpinfo->data + ((bmpinfo->height * bmpinfo->width * 4) - x)); *(bmpinfo->data + ((bmpinfo->height * bmpinfo->width * 4) - x)) = tmp; } //next, get rid of the "zero" padding that''s included in windows color data for (x = 0; x < bmpinfo->width * bmpinfo->height * 3; x++) { *(bmpinfo->data + x) = *(bmpinfo->data + x + (x / 3) + 2); } wec_DeleteObject(hbitmap); return bmpinfo; }

Then here''s how you''d use it, similar to nehe''s code:

static void LoadTextures(void) { UINT32 x; BMPINFO *textureimage[1]; memset(textureimage, 0, sizeof(void *) * 1); textureimage[0] = LoadBMP("data\\wall.bmp"); if (textureimage[0] == NULL) { UERROR(castle_BMPERR, "Unable to load textures"); return; } for (x = 0; x < sizeof(texture) / sizeof(texture[0]); x++) { glGenTextures(1, &texture[x].texture); } //create GL_LINEAR (high quality) texture glBindTexture(GL_TEXTURE_2D, texture[0].texture); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR); gluBuild2DMipmaps(GL_TEXTURE_2D, 3, textureimage[0]->height, textureimage[0]->width, GL_RGB, GL_UNSIGNED_BYTE, textureimage[0]->data); texture[0].width = 1.0f; texture[0].height = 1.0f; if (textureimage[0]) { if (textureimage[0]->data) { ecmem_Free(textureimage[0]->data); } ecmem_Free(textureimage[0]); } }

That might help you out...it''s just basically generic win32 code to load textures, into the OGL format, and setup the mipmaps, etc.

Umm, a few notes about the code:
1) "wec_"''s are just win32 api calls...delete the wec from the beginning of the function call, and it''ll be just like win32 api.
2) UERROR is sorta like an ASSERT, in my coding style...it''s for error reporting purposes...you''ll have to modify those portions of code to your own error-catching style
3) #if (err_DEBUG) and DERROR are for debug-time error checking...you can basically just delete all this code, for release build purposes.

That might help you understand how to load textures w/o using auxDIBImageLoad.

Any questions: duck0026@tc.umn.edu

-Rob

it looks like i must load all textutes at the beginning in the same way i loaded before and i can cuse the same funktion to loade the textuter before i call an object ok ?

actually, anony, I think that''s how auxDIBimageload works. But I''m not sure.

Cause the bmp file format is, I believe, "backwards" (little endian) B-G-R with a zero badding at the end...and yet, when taking auxDIBimageload, it returns a handle w/o the zero padding as R-G-B.

So, through my logic, they have to be about just as efficient.

But I''m not claiming to be an expert. By all means, if there''s some more-efficient way to convert BGR0 to RGB that I don''t know about, then let me know.

I wouldn''t be surprised if my code was less efficient. But try running each through a profiler to find out. I also wouldn''t be surprised if my code was more efficient.

Oh, I think if you wanted to just load the handle through windows directly, and access the raw data (like I did above), to save the conversion time, you could just use:
GL_BGR_EXT instead of GL_RGB in the gluBuild2dMipmaps call.
Once again, I''m not sure if that''d work or not...but if it did work, it''d get rid of a lot of the "copying, swapping, and converting" stuff.

Yes, instead of openning it through windows and then accessing the raw data from win32 api calls--instead, you could have fopen()''ed the bmp file, parsed through the bitmap header, and accessed the raw data that way. Both are different ways of acheiving the same thing.

One side effect of your way appears to be a lot of unused space in bmpinfo->data, since you''re doing the BGR0 to RGB conversion in place.

If I had to write this function, I''d probably just walk the source bmp line-by-line backwards, filling in the dest bmp with only the RGB, thus losing the need for the second loop...(or fill in the dest buffer in reverse order...whichever)

-scott

scaught:

Yup, that''s completely correct. There''s a bunch of unused space in bmpinfo->data after my code. I noticed that while writing it.
(It''s allocated for 4 bytes per color, but in the end, only uses 3 bytes per color.)

That''s actually a very good suggestion, thanks.

The reason why I did it that way:
Doing it my way eliminates the need for two seperate allocated chunks of memory for source and destination--how I''m doing it, the source memory space *is* the destination memory space.

I can''t think of anyway to do it as you''re suggesting, unless you allocate a 4byte-per-color source space, call GetBitmapBits(), and then allocate another 3byte-per-color destination space...do the convertion...and then free the source.
So, there''d be some extra memory allocation/freeing, unless there''s a more efficient way of doing it.

I also thought about calling realloc() with the space, after it''s been converted--but that seems like a waste of cpu cycles.

Ja, my method involves two buffers - a temporary one to hold the incoming data, and the final one to hold the outgoing data.

I''d just be worried doing it in-place because of how the system is going to handle that extra bit of garbage - if it ignores it, then you may not have too much of a problem - the excess isn''t too much even for large bmps - it''s just untidy, and I don''t like untidy.

(and you''re right - stay away from realloc() )

Cheers,
-scott

Well, I''ve used my code in actual programs--and the textures load and work perfectly.

So, the code *works*, as is.

But you''re right. Your way of doing it is more tidy, has less looping, and is better.

Thnx...I think I''ll try to modify it sometime in the future.