flipcode - Cool, It Works!

Cool, It Works! - Issue 05 - 32-Bit GL Textures & Log Files
by (09 November 1999)

Introduction

Yeah, it's been a while. But now that Wheel of Time is finally gold, I finally have some free time. A few choice nuggets for you this time 'round...

True 32-bit Textures In OpenGL

In a newsgroup there was a recent discussion of OpenGL seemingly converting textures to 16-bit when being uploaded ... even though you specified a 32-bit rendering context and are uploading RGBA textures ... I was noticing this in my app as well, but I thought it was just "the way it was". Until someone mentioned that this is something specific to certain video cards (including the TNT and TNT2, which is what I use). Basically the fix is as follows... If you have a function call like this...


glTexImage2D(GL_TEXTURE_2D, 
	0,
	4,
	,
	,
	0,
	GL_RGBA, 
	GL_UNSIGNED_BYTE, 
	);

See where it has the "4"? If you replace that with...


glTexImage2D(GL_TEXTURE_2D, 
	0,
	GL_RGBA8,
	,
	,
	0,
	GL_RGBA, 
	GL_UNSIGNED_BYTE, 
	);

...your textures will be full 32-bit, as you wanted them to be. BTW, GL_RGBA8 is not even documented in Microsoft's help files, so I thought I would be a good Samaritan and pass it along here. Enjoy!

Using A Log File

This will help you. A lot.

Basically, what this involves is just having your engine/editor/whatever open up a text file when it starts up and spit useful information into it. This can include stuff like initialization results, information about the users computer, capabilities of their graphics card, etc... You should also mirror all error messages that you display on the screen, into the log file.

What does this do for you? Well, for a little bit of work on your part, you get an invaluable file full of useful information. When your user tells you, "I did and it crashed.". You say, "Send me the log file.". Chances are all the information you need to diagnose the problem is in there ... depending on how much information you capture.

Of course, there's tradeoff's ... you don't want to log so much information that it bogs the program down.

But in any case, I've found it extremely useful in many cases. Here's some source for my TFileLOG class...

Download the source code package (1k)

(NOTE : there's some specific stuff to my code architecture in there ... like the mPERF macros ... just remove whatever doesn't compile on your system. ;)

A very important element in that source file are the calls to "m_pcsf->Flush();". This flushes the data out to the file immediately. Why is this important? Because if you don't do that, and the program crashes ... the log file will be empty. By including that function call, you are forcing the data to be committed to the log file every time and therefore will have the information that you need in it when you load it up following a crash.

A quick example of how I use the log file would be when I log the OpenGL version and renderer...


[log_file_variable]->WriteString("OpenGL : %s V%s (%s)",
	glGetString(GL_VENDOR),
	glGetString(GL_VERSION),
	glGetString(GL_RENDERER));

As you can see, it allows you to construct strings which are then passed into the write function. This is more useful than I can put into words.

Next Time

I'll probably talk a little about the terrain feature I just added to my engine. There was an image of the day here about it a while back ... it basically reads in a black-and-white PCX file, converts it to height data and then creates custom textures to cover it. It's pretty spiffy.

See ya then!

Article Series:

Cool, It Works! - Issue 01 - Introduction
Cool, It Works! - Issue 02 - Linked Lists, Overloading Operators, Sprites, & More
Cool, It Works! - Issue 03 - Files, Texture Effects, Coronas, & More
Cool, It Works! - Issue 04 - Handling Textures & Effects
Cool, It Works! - Issue 05 - 32-Bit GL Textures & Log Files