Ok, the text vs. numeric. I was thinking that would be required and you validated that. Well, the better compatibility with existing engines ...

Numbered tracks are what Quake expects and built into the pipeline. I think working with them sucks. I'd almost suggest a wordspawn key, but I fear a drastic proliferation of them. 

Well, I am glad the Direct X version is working for you.

Does current Quakespasm work properly for you?
What about a previous Mark V or Fitz 0.85? I'm trying to determine issue.

The current Open GL Mark V uses non-power of 2 (July 2014), uses stencil operations more (this one), varies from Fitz 0.85 by using the texture matrix instead of the mesh alterations (been that way since 2013).

The Direct X version of Mark V uses neither the texture matrix nor the Fitz 0.85 meshing alterations so the model textures will look like --- well --- JoeQuake/GLQuake/Requiem --- which are stretched and not crisp like FitzQuake.

It is done like that to support external textures for models in a straightforward way.

I had intended to revisit it in the Direct X version, but that time won't be coming soon. I don't think, at least.

I'm trying to mentally picture whether or not non-power of 2 would solve that and if the Direct3D 8 wrapper supports that. 

Would be great if this got fixed

It can't be fixed because D3D doersn't support it.

What D3D offers for filter modes is one of three options (for each of min/mip/mag):

- Point
- Linear
- Anisotropic

Various combinations of Point and Linear then correspond to the GL filter mode names, but the important thing here is that Anisotropic is also it's own filter mode, and anisotropic filtering is only enabled if you select that filter mode.

So in other words you can't combine point filtering (what GL calls nearest) with any form of anisotropic filtering.

This restriction still exists in D3D11 where the options (excluding shadow map comparison states) are:

D3D11_FILTER_MIN_MAG_MIP_POINT
D3D11_FILTER_MIN_MAG_POINT_MIP_LINEAR
D3D11_FILTER_MIN_POINT_MAG_LINEAR_MIP_POINT
D3D11_FILTER_MIN_POINT_MAG_MIP_LINEAR
D3D11_FILTER_MIN_LINEAR_MAG_MIP_POINT
D3D11_FILTER_MIN_LINEAR_MAG_POINT_MIP_LINEAR
D3D11_FILTER_MIN_MAG_LINEAR_MIP_POINT
D3D11_FILTER_MIN_MAG_MIP_LINEAR
D3D11_FILTER_ANISOTROPIC

Again you'll see that most of these modes correspond to the GL modes (D3D11 has a few extra ones) but that D3D11_FILTER_ANISOTROPIC is it's own mode and can't be combined with point/nearest filtering.

This isn't the kind of engine bug that you can fix in code, it's a limitation of the D3D specification. That's a difference between GL and D3D - GL keeps things loose and floppy and allows implementation-specific wriggle-room, D3D doesn't.

I'm trying to mentally picture whether or not non-power of 2 would solve that and if the Direct3D 8 wrapper supports that.

Non-power-of-two is the ideal solution but I don't remember if the wrapper supports it. D3D8 does support non-power-of-two textures so it would be easy enough to add a pseudo-extension check and code up the loader (be careful when reducing miplevels for non-power-of-two textures though). 

Thanks MH. I think npot solves the problem in a way that won't interfere with external textures, when I rebuild I'll tell the wrapper to say it has npot texture support. 

(be careful when reducing miplevels for non-power-of-two textures though).

Whoa ... what's this? Is there a size limitation of the mip textures of some sort? 

I had been using Mk V r15 before on the same machine without problems. Quakespasm 0.90 also works.

Strangely enough, the WinQuake build works on my Samsung NP-NC10 netbook (Intel Atom N270, 1.6 GHz, 2GB RAM).

The sad thing is that right now, I am stuck with DX8 since the OpenGL build (vs2008, I assume) doesn't work, either. When I load the start map for example, huge chunks of textures are missing. In the "Welcome to Quake" hall with the three skill selection gateways, it cuts away pretty much half of the screen. Never had any problem like this. 

Whoa ... what's this? Is there a size limitation of the mip textures of some sort?

No, no limit. You just need to be aware that the standard for both GL and D3D specifies round-down (so for a dimension of, say, 63, the next miplevel would become 31, not 32).

A simple way is to check "if ((width & 1) || (height & 1))" for a miplevel, then send it through GL_ResampleTexture instead of GL_MipMap. IIRC the stock Fitz code does some funky stuff with miplevel reduction (reducing each dimension separately) so you'll have some fun there.

I believe that the latest Quakespasm has non-power-of-two support so it'll probably be useful to cross-check with that.

For D3D9 the check is "if (!(d3d_DeviceCaps.TextureCaps & D3DPTEXTURECAPS_NONPOW2CONDITIONAL) && !(d3d_DeviceCaps.TextureCaps & D3DPTEXTURECAPS_POW2))" for full non-conditional support, and if memory serves it's the same in 8, so you can report that GL_ARB_texture_non_power_of_two is supported if they're met (everything else is done outside of the wrapper).

Conditional support means that the address mode must be clamp and you can't use mipmaps which is broadly equivalent to GL_ARB_texture_rectangle (although the GL extension is weird in that it uses integer texcoords). You'll want full non-conditional support in the general case, although conditional might be OK for MDLs (provided you're still doing the Fitz thing of not mipmapping them).

D3D should also not suffer from crap like "we'll say we support non-power-of-two textures but will emulate everything in software if you try to actually use them". 

Here is a screenshot of what the game looks like for me with the vs2008 build. Skyboxes, liquids and teleport surfaces are totally screwed.

http://i.imgur.com/Q3KPRbA.jpg 

That gives me something useful to work with.

I use a stencil operation to draw the sky. All my computers even my Mac are ATI/Intel, apparently Nvidia does not like. 

Why not just draw the sky, clear the depth buffer, and move on? I understand it's probably an optimization thing, but ... 

r_mirroralpha support. Has to draw the sky twice. 

Also sky needs to draw on top of other things depending on the map 

 

In Mark V r15, what happens if you do r_shadows 1 (do the shadows look right?)? Mark V uses the stencil for shadows and has since 2013.

Although stencil operations seem the prime suspect to the Open GL compatibility, it might not be the case. 

I was using r15 just before I switched to the new builds of yours. No problems there at all.

Proof (screen taken with r15):
http://i.imgur.com/LiAxUXb.jpg 

That's helpful. I'm sure I'll figure it out, I see from my sky drawing function I had some varying opinions about the drawing, which since it worked fine on my graphics card I have since forgotten ...

Maybe if I reflect on this a bit, I can come up with a resolution.

void Sky_Stencil_Draw (void)
{
int i;
msurface_t *s;
texture_t *t;

// Baker: Direct3D doesn't have stencil at this time
if (!renderer.gl_stencilbits || vid.direct3d)
return;

// Baker: No sky to draw
if (!level.sky /*|| !frame.has_sky*/)
return;

// Baker: Where drawn (doesn't z-fail), replace with 1
// in the stencil buffer.
eglStencilFunc (GL_ALWAYS, 1, ~0 );
eglStencilOp (GL_KEEP, GL_KEEP, GL_REPLACE);
eglEnable (GL_STENCIL_TEST);

// Baker: A no draw pass of the sky brushes, does not even
// write to depth buffer (maybe it should?) that writes
// our stencil overlay.

eglColorMask (0,0,0,0);
// eglDepthMask (0); // Don't write depth to buffer
eglDisable (GL_TEXTURE_2D);
for (i=0 ; i<cl.worldmodel->numtextures ; i++)
{
t = cl.worldmodel->textures[i];

if (!t || !t->texturechain || !(t->texturechain->flags & SURF_DRAWSKY))
continue;

for (s = t->texturechain; s; s = s->texturechain)
// if (!s->culled)
{
DrawGLPoly (s->polys, 0); // Not here.
rs_brushpasses++;
}
}
eglEnable (GL_TEXTURE_2D);
eglColorMask (1,1,1,1);
// eglDepthMask (1);

// Baker: Keep any pixels where stencil wasn't drawn
// for this drawing pass.
eglStencilOp( GL_KEEP, GL_KEEP, GL_KEEP );
eglStencilFunc( GL_EQUAL, 1, ~0 );

// Baker: Now draw the stencil
Sky_DrawSky ();

// Turn it off
eglDisable (GL_STENCIL_TEST);
eglClear (GL_STENCIL_BUFFER_BIT);
} 

Transparent textures on worldbrushes arent handled correct. This screenshot is not what it looks like ingame, there you actually see the pink color.

When doing this with func_illu/wall whatever, all is good. 

Transparent textures on worldbrushes arent handled correct. This screenshot is not what it looks like ingame, there you actually see the pink color.

When doing this with func_illu/wall whatever, all is good. 

http://imgur.com/ML7nVBh 

ignore me as usual.. 

QS 0.90 draws this "correct"
http://imgur.com/JYx8dDG 

Will fix.

I was going to remove alpha masked (fence) texture support on world brushes because it is technically wrong and leads to mapper newbie pain (a mapping newbie guy always says "I see void").

Then you guys made a map using it and then Quakespasm copied the Mark V implementation.

So now my "correction" becomes "bug".

Anyway, when I revisit I will "re-add" that back in. 

Its all cool Baker, i was trying to not overuse func_illusionaries for performance reasons, but yeah, its wrong to do it like this i know..
Thanks for your precious work anyway, it is very appreciated! 

I would just make them func_wall/func_illusionary on new maps, and consider the fences-as-world-geometry support in qs deprecated / not recommended for future use.

arguably I shouldn't have added that to qs 0.90, because you'll get HOMs/a view in to the void if the brush touches the rest of the world, plus vis might cull stuff behind the fence texture because it thinks they are opaque. 

Anyways, sorry for this Baker, I take responsibility for spreading the mis-feature :P

mfx, it should be safe to go crazy with a lot of func_illusionary, unless you're measuring a performance hit.

In glquake/fitzquake the brushmodel drawing does a bunch of setup per-poly of the model, so you want to avoid a single very complex func_wall (this is fixed in qs 0.90 though, and probably engines with more advanced renderers). But on the other hand, I'd expect drawing a lot of simple func_walls/illusionaries should be fairly fast on all engines. They're vis-culled too, so even having several hundred spread around the map should be fine. (famous last words.. )