An update on the problem, if you played the Warp demos before starting up, then the grunt/player skins would be messed up. 

have you tried increasing heapsize? i've had texture and skin corruption problems in the past which went away after allocating more memory. 

DirectQ doesn't use heapsize so it's not that. I suspect it's more likely a texture caching bug which I haven't seen yet - the symptoms certainly match. 

OK, I've checked this about 3 or 4 times with Fitz, DP and Aguirres as well as DirectQ and it happens in all of them. It's a content bug rather than an engine bug I'm afraid. 

What is it? 

There seems to be a small issue of sometimes not getting the green armor at the beginning of the Map "Return to Dust" with directq. (you have to jump to get it Has anybody else encountered this? 

I have an animated lavafall texture on a func_illusionary which I had to light quite heavily to make it look right in Glquake (as bright as the regular lava). But now it's totally overbright in DirectQ (and one or two ports from the Proquake pack, for example): screenshot. Even the latest version (1.8.666a) doesn't display it correctly - the first frame of the animation is fuglified like that while the others are fine, so it flickers. What's going on there? 

... you didn't applied Quake palette to the first frame of the moving texture... Export your image from wad, apply quake palette and then import it back to wad.
It should solve you issue 

It's the engine, not the texture. 

I don't understand why the engine would crap the first texture frame only... hence my answer :P 

Neither do I... hence my question :) 

I'd guess the excessive brightness is because of overbright lighting. The same would happen in software Quake if so, so that's a useful test. (Also FitzQuake and any other engine that supports overbright lighting). gl_overbright 0 will revert DirectQ to GLQuake lighting if necessary.

I don't understand why the first frame would act strange either. Cross-checking with other engines might also be a useful test there. 

I tested it with Winquake, Fitz, and DP (all of which support overbright lighting). The texture looks right in all of them. 

What's the map? I'd like to test this in the debugger to see if I can figure what's going on. 

http://negke.quaddicted.com/files/mappi.zip 

Fixed it. Your frame 0 texture was generating the same checksum as the standard lava texture which caused animation cycles to get messed up when both were visible on-screen at the same time. 

I thought unique file names were enough. Cheers for fixing it. 

I was comparing checksums though, not filenames. I just added a check for filenames too and it worked. :)

Just waiting to see if I can fix one more thing and I'll release a patched version for this. 

I have a question regarding Directq, when I use 1.866b, I can see the fog fine, but I thought Directq didn't support fog since 1.8.3? 

 

then's what with the "getting fog back in 1.9"? 

I lied. :)

I actually restored fog a few versions ago; it only works with shaders (OpenGL vs D3D differences here) but it's there. 

I noticed although fog works, it is not loaded automatic in some maps, such as neh2m5, I have to manually set the fog value in the console. Why does it load for some maps and not others? 

For the same reason as it behaves this way in Fitz. It only loads automatically if the mapper has set a worldspawn key, and is cleared between maps (and the reason for that is because apparently that's the way mappers prefer it).

I did write about this back in October... http://mhquake.blogspot.com/2010/10/questions-about-fog.html 

I am not a mapper so the technical stuff is beyond me, but basically what you're saying is that the mapper didn't intend for that nehahra map to have fog by not setting a worldspawn key?