What's wrong with Unreal engine games? With previous versions I would get white textures. With this latest version they look fine.

DosFreak wrote:

What's wrong with Unreal engine games? With previous versions I would get white textures. With this latest version they look fine.

That's mipmapping. You probably had different mipmapping settings when you tried the two versiond. Mipmapping for some of the texture types works only for square textures. I think its my fault: I first noticed it when I put in a mipmapping routine for paletted textures; trouble is I can't see anything wrong with the code.

Hummm, do you know in what textures they do that?
So I can look at the code, is it only palette textures or in all?

GoldFinger wrote:

Hummm, do you know in what textures they do that?
So I can look at the code, is it only palette textures or in all?

I think its just the paletted textures. When I added the paletted texture support, I first tried gluBuild2DMipmaps but it seemed to
filter the palette indexes and thus gave weird results. So I coded my own mipmap generater (just decimating). That seemed to work fine with RB3D, but then I noticed other games lost textures
in places, and it seemed to be only if the textures weren't square.

008a1

Tomb Raider: Perfect

Descent II: Perfect

Redguard: Perfect, except for the sun, which is a known problem

Extreme Assault: Perfect

Grand Theft Auto: Perfect

Dreams to Reality: Perfect

Blood: No worse than before, in my experiments

Glidos wrote:

I think its just the paletted textures. When I added the paletted texture support, I first tried gluBuild2DMipmaps but it seemed to
filter the palette indexes and thus gave weird results. So I coded my own mipmap generater (just decimating). That seemed to work fine with RB3D, but then I noticed other games lost textures
in places, and it seemed to be only if the textures weren't square.

BTW, my mipmap generator is called genPaletteMipmaps, and
is in PGTexture.cpp

Ok, I will take a look at the code and see if I find anything strange.

And what about speed? did anyone notice any speed gain?

Well Paul, I changed the code and commited to sourceforge, can you generate a build and test it in the games that use the Palette textures, enable mipmapping and test it please.

GoldFinger wrote:

Well Paul, I changed the code and commited to sourceforge, can you generate a build and test it in the games that use the Palette textures, enable mipmapping and test it please.

Sure, no worries, but Unreal is an example of a game that loses textures when mipmaping is enabled, so you can test also... makes me wonder if I'm wrong about it being paletted textures, because I didn't think Unreal would use palettes.

That's fixed Redguard and Unreal, which are the two games where I saw the texture drop out. Nice one. So you have
to take mipmaps past the one-pixel-wide-line stage right down
to a single point. I didn't realise that.

Great news, we are really getting to a good point... 😀
I am glad it fixed the mipmaping bug, OpenGLide and consequently Glidos is increasing greatly its support for games, do you guys have any wish of a game to make it work?
I can concentrate on Descent Freespace, or others. Maybe fixing one thing in one game will fix a lot in others, who knows?

Hind. I want Hind. Please make Hind work. Pretty please. 😁

Ok, I will focus on Hind, I will install it and try, do you have any suggestion? what is the exact problem with Hind? do it run in any way?

I've got the 1.0 and 1.2 CD vers of HIND and I downloaded the patches 'bout 3 weeks ago.

I think we can do it. 😀

As I've said before, I really want to see POD working. 😀 (Craig wants it too.)

But first, we need to get the non-Glide version working in Windows 2000/XP. And there's not a whole lot of directions on that.
We may need an ACT/QFixApp guru to take a look at it.

But by all means, go work on the game Paul wants first. 😀

*silence*
Hm, I guess we're all waiting on Craig to post pics. 😉

When I tried Hind I got a log file full of errors. As far as I could see no OpenGL calls were working; all returning errors. My guess is that it sets up some nasty fullscreen DirectDraw mode, and that stop OpenGL initialising. See, that would be okay with a voodoo pass through card, but not so hot for a wrapper.