Marathon OpenGL Texture Problem

[lpetrich]

First, some background. I am one of the developers of improvements to the recently-opened source code to Bungie's Marathon 2 engine (for more, check out http://source.bungie.org).

And recently, I have been adding OpenGL support to it, utilizing the engine's visibility, transformations, and clipping calculation. However, I'm now having problems with some of the textures. The wall textures work perfectly, but the landscape textures often look bizarre, and the sprite textures are often mangled in various ways (Marathon has rather Doom-like geometry).

For example, one of them is missing every second scanline and has part of one of the wall textures appended to it.

What might be causing this misbehavior?

For the record, here's what I have:

PowerTower Pro 250 (604e; 160 MB RAM)

ATI Rage Orion (Rage 128; 16 MB VRAM)

MacOS 9.0

Apple OpenGL 1.1.2

Also, OpenGL is running in windowed mode instead of full-screen mode, because some of the Marathon-engine display is 2D rendered (HUD, overhead map, terminals).

[Hude]

Originally posted by lpetrich:
Also, OpenGL is running in windowed mode instead of full-screen mode, because some of the Marathon-engine display is 2D rendered (HUD, overhead map, terminals).

Can't see why you should use windowed mode for 2D rendering.

[FATBUDDHA]

It sounds like the problem is that you are reading in the texure data (from a bitmap or whatever) assuming that each pixel is in (say) an 16 byte RGBA structure, when the data actually in a 8 byte RGBA structure.

What you then get, is OpenGL creates your texture map using the array of RGBA data, but because it is looking for twice as much data as is actually there, it reads whatever data is occupying the space in memory after this array as well (say, another array containing texture information).

In other words - check that the bit size of the data being read in, is the same as the bit size that your are telling OpenGL to expect (when you are creating the texture map, and mipmaps.)

Hope this helps...

[lpetrich]

Actually, the data is in a structure the right length, because the setup call works fine. Also, this seems to be a problem only for small sprites, usually those smaller than 64*64. However, bigger sprites are almost always OK.

The trick that worked was to make the sprites have a minimum size of 128*128; I find it very curious that this trick has managed to work. I wonder what experience the OpenGLifiers of Doom, Hexen, and Wolfenstein have had with sprites; have they had similar troubles and odd behavior?

A further question I have is whether the firmware of a 3D-accelerator video card can get corrupted, and if so, how could it be restored. I ask that because I wonder if that had happened to my card, a Rage Orion in a PowerTower Pro Mac clone.

Finally, for more on Marathon: Open Source, check out http://source.bungie.org