Ned help: buggy textures positioning or textures offsets?

See this topic, answer here or on quake one
http://quakeone.com/forums/quake-talk/o ... #post76429
this affect all textures not only status bar.

First problem: I see Spike mentioned GL_CLAMP_TO_EDGE on the other thread.

I'm totally guessing that "scraps" means that the engine is putting a lot of small images onto one big "quilt" texture to save on glBindTexture calls, which I think GLQuake did too. It must not be adding any padding around the images, so adjacent images on the big quilt texture are bleeding through.

It won't be easy to fix if you're new to this stuff. You'd have to figure out how to add a couple pixels (one or two) of padding around each "sub-image" in the "quilt". You should probably pad with transparent pixels. That still won't look perfect, but it'll be an improvement...

I'd be surprised if GLQuake/Hexen2 didn't already add at least one pixel of padding around each image, but I have no idea.


As for disabling the alpha test, I take it you're new to OpenGL? Here's a start (do this instead of enabling alphatest):

glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

// draw image

glDisable(GL_BLEND);


Also, have you heard of jpegs? I think I used up my month's bandwidth allotment downloading that screenshot.

GL_CLAMP changed to GL_CLAMP_TO_EDGE this doesnot help.

All scraps commented. It makes GL work a little fast, and some pixels looks like in original image. But it not help too (.

Did you know quake/hexen2 engines where this bug fixed?

Yes, i am new to OpenGL =). Thank you very mach, now i have blending, alpha test completely removed. And after that, EDGE lines (one pixel of padding? ) become less visible, but not fully it fix problem, lines Thinned.

I am sorry about your traffic, i am know jpeg, but i am not used it in this case because jpeg can loss these buggy lines. (My bad i should first try)

EDGE lines (one pixel of padding ) presented not only in 2d HUD's etc.
but in 3d world itself, some textures have bad alligment, this is not happen when i use software mode, or i open this image/texture in viewer or in photoshop.

I am post later new screens in jpeg of course

Texture sizes need to be a power of 2 (2, 4, 8, 16, 32, 64, 128, etc) and the engine will resample them if not. Look at FitzQuake for a way around this; it pads HUD textures out to a power of 2 size so that the quality doesn't degrade.

Ok, thanks. I am look on it.
I forgot to say.
I am already added GL_TEXTURE_NON_POWER_OF_TWO support, maybe i am makes some mistakes? I upload source code and my hexen2.exe compiled file.

Even GL_NPOT doesnot help to remove (bad padding of textures, positions, offsets?), this makes textures looks like original (no resize operations, and way less pixilated), and decrease memory usage.

npot obsoletes what mh suggested, yes. At least for cards that properly support npot.
clamp-to-edge will not work correctly on scrap images, as the edge isn't where it ought to be.
gl_texturemode gl_nearest? ehe
Failing that, you can adjust your texture coords in by half a texel, depending on resolution.

There's actually two types of non-power-of-2 support. The older type is conditional and you need the texture to not be mipmapped and have the wrap mode set to clamp (corresponding to GL_EXT_texture_rectangle) and the other being fully non-conditional (GL_ARB_texture_non_power_of_two). To further complicate matters, some older cards (like the GeForce FX series) support GL_ARB_texture_non_power_of_two but will go through software emulation.

Because of this mess, it's probably simpler to just use padding and scrap textures.

I wouldn't worry too much about memory usage in an old game like Quake or Hexen II; these were designed for a 4 MB Voodoo 1 so I think that fighting to keep memory usage down is a waste of your time and effort (unless you're still interested in targetting that kind of hardware).

Sometimes it's a case of "memory usage - performance - pick one".

And if you have funny seams on world textures too, like in that grassy area with the path, there probably isn't much you can about that...

I assume whole all textures in hexen2 have this problem, even if i disable NPOT. All textures shifted to right and down with +0.01 ?
must be
1234
5678
9abc
defg
i take this
6785
abc9
efgd
2341

Here is source http://heretics-hexens.ucoz.com/H2MP.7z 6 mb
And Screenshot http://heretics-hexens.ucoz.com/hexen20.jpg 200 kb

Thanx a lot for helping now i am done it

http://heretics-hexens.ucoz.com/temp/hexen21.jpg

I wouldn't worry too much about memory usage in an old game like Quake or Hexen II; these were designed for a 4 MB Voodoo 1 so I think that fighting to keep memory usage down is a waste of your time and effort (unless you're still interested in targetting that kind of hardware).

Hexen II's models are all inefficient and ugly, the programmers had to work hard to compensate for the worst planar UV maps in the world. I don't think there IS a model skin that is a power of 2.

Not only that : the gameplay is bad (lowest point in the whole damn Raven magic series including Shadowcaster and Mage's Layer), but that is another story.

For some reason I do want to take the improvements I made on Q/Q2 so far onto Hexen II... probably as patches for HoT since it's the only h2 engine I can even trust... and it has a dos version lol

There are several noticeable seams in that HUD.

That's because the HUD uses another lump for pieces drawn above the view. You'd have to work out some clamp/merge black magic to fix that one.

If you interest to know more engines for Hexen II
Read this -> http://quakeone.com/forums/quake-talk/o ... -post.html