@Baker, you should consider just using 'cd remap' instead of your 'setmusic' command, that is if you want consistancy with DP+FTE too. 

In FTE/DP would "cd remap 04 sometrack.mp3" be the equivalent of what I posted above? 

Apparently a similar issue as the one described above (#519) happened during development of Quakespasm 0.90. According to bogworth, it was related to anisotropic filtering.

Quote bogworth:
"The combination of GL_TEXTURE_MAX_ANISOTROPY_EXT with values greater than 1 and GL_NEAREST appears to have vendor-specific behaviour - in my case, GL_NEAREST is ignored." and
"The problem appears for textures that are mipmapped (eg, not models), when gl_texture_anisotropy is greater than 1 and gl_texturemode is 1, 2 or 3."

I dunno if all of this applies (probably not, as I also had models with filtering changes being ignored), but maybe it helps with detecting and eliminating the problem.

Would be great if this got fixed since the DX build seems to be the only one properly working on my system right now (Winquake crashes and the vs2008 build shows weird texture issues). 

aye, in FTE, if its numeric then it goes and plays track%03i.mp3, otherwise it goes and plays the named path (with the same optional prefixes as other fake-tracks).
the same as 'cd play' and 'cd loop' commands.
the only catch is that you can only remap numbered tracks, not named ones.
I'm not entirely sure on which paths that DP assumes it might be in (if any), but the rest is the same as far as I am aware (for supported file formats).

what annoys me, is that world.sounds is a float. I'm tempted to add a hack and specially parse the entity lump to read it as a string, and update the server's svc_cdtrack generation to just play that string instead somehow. numbered tracks are so old fashioned!
plus, they get in the way of map compilations.
of course, this assumes mappers would use it. 

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