GZDoom Texture Handling

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

Locked
QBasicer
Posts: 22
Joined: Sun Nov 13, 2005 23:18

GZDoom Texture Handling

Post by QBasicer »

Face it, the source is huge. How does GZDoom extract a texture out of a wad and put it into OpenGL? This is what I assume happens:
1. The texture is loaded into the heap along with the pallette
2. DevIL does some voodoo to turn this memory into a texture
3. Use texture as regular OpenGL.

How do you get DevIL to return a proper OpenGL texture reference? I havn't been able to find any good example on how exactly this is done.

Here's my hunch:
Use ilLoadL() to load the image from memory
Use ilutGLBindMipmaps() to return a texture reference and build mipmaps?

I'm not sure of the use of ilGenImages(), and ilBindImage(). The docs talk about "a named image", but I'm not really sure what they're going on about, because I see no "names" involved. I'm not really following how DevIL processes images, and if you can store them later on in DevIL's internal format (I assume converting from memory to it's own format is taxing), and if I can, how do I reference to it?
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Post by Graf Zahl »

It is much more complicated. ;)

There are 2 different mechanisms. For regular textures I don't use DevIL but instead slightly modified versions of ZDoom's texture handling code. I don't use DevIL at all to do anything more than load a graphic into memory. I also don't keep the images maintained by DevIL because in that format they are of no use. I have been thinking avbout caching the data for warped textures but the time needed to warp it is so much longer than loading them that it isn't worth it.

The starting point for everything is the method FGLTexture::CreateTexBuffer. It either calls LoadHiresTexture (which uses DevIL to load the graphic) or the virtual CopyTrueColorPixels method of the texture class which handles the formats ZDoom understands as well.
This step also takes care of invulnerability remapping etc.

Then the low level GLTexture class is called. This has to do some maintenance for translations and other remappings but in the end it calls the method GLTexture::LoadImage which is performing the actual upload of the texture into OpenGL.
I'm not sure of the use of ilGenImages(), and ilBindImage(). The docs talk about "a named image", but I'm not really sure what they're going on about, because I see no "names" involved. I'm not really following how DevIL processes images, and if you can store them later on in DevIL's internal format (I assume converting from memory to it's own format is taxing), and if I can, how do I reference to it?
There are no 'names'. The only identifier is the ID you get from ilGenImages. If you want to keep an internal DevIL image you must save this ID and not delete it. If you need to work with the image again you have to bind the ID again.
Locked

Return to “GZDoom”