Looks like FitzQuake isn't the only engine with the dlights issue.

I do see that Qrack doesn't have that issue, it is commented "//MH: robust support for increased dynamic lights" 

Oh boy, that's a nice one. What is the solution? changing dlightbits to long long type? 

int dlightbits[MAX_DLIGHTS >> 5];

if (!(surf->dlightbits[lnum >> 5] & (1 << (lnum & 31)))) continue;

surf->dlightbits[num >> 5] |= 1 << (num & 31);

Exact same code is as used for vis; that should work for everything. 

I see. and the int should possibly be changed to unsigned, too. 

Fixed in the quakespasm svn, rev. 694
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=694 

Good catch on the "dlightbits[(MAX_DLIGHTS + 31) >> 5];" part - I'd missed that. 

I keep getting this error when reload my map, it is not always happening but I am not sure why. I have searched for any solution but could not find any. Using Fitz 0.85 engine, I have not generated any coloured lighting and not using a LIT file.

TexMgr_ReloadImage: can't colormap a non SRC_INDEXED texture: lightmap027
TexMgr_ReloadImage: can't colormap a non SRC_INDEXED texture: lightmap027

When I wander around the map, certain parts (always random as far as I can tell) seem to be missing all colour information and look greyscale. If I reload the map again, it often goes away or just moves around to another texture.
Any clues what this is? 

sounds like a code bug; somewhere the pointers are getting messed up i think. I don't think there is anyway for data to cause that error.

FYI: what's happening is it is trying to set up the player texture (which has swappable colors i.e. "colormapping") but the data pointer is referencing a lightmap instead. 

I initially thought it affected only certain textures (X/Y) sizes, but it happened on a 64x64 pixel texture last night. I was using a fast compiled map to do some testing, so I did a full compile and still got the problem, just not as frequent as before. It also gets worse the more times I use quick save/load. It does not affect the game besides being a visual glitch that goes away if I reload the map.

My config settings are mostly standard, I have 2048 edicts but the rest is default. (well as far as I know!) I don't use extra heapsize, zones or any extra command line parameters besides -game and +map. The BSP I am using breaks a couple of standard limits and produces warning, marksurfaces are above 32k and I am using 98 textures. 

it's probably heapsize then. You should use at least 128000 but i use 256000 in my quake batch file to just save myself the trouble.

I was getting odd corrupted textures until I upped heapsize. 

in the gl_texmgr.c where it reloads the entire file that a texture was found in.

In a lot of cases, a texture is in the map or model. And many times, the .mdl or .bsp in a .pak.

So in that case, it is going to load the entire .pak into memory. So, for instance, to reload a grunt's skin, it will load the entire pak0.pak into memory (17MB). For a Quoth Pyro, it will load the entire quoth/pak1.pak into memory (81 MB).

It will do this on any video mode change. I'm not sure if this how/why the described issue is happening, but this mean you need a substantial -heapsize allocation (probably at least 128 MB).

One way to test if this is the likely origin of the problem would be if Quakespasm/RMQ engine/Fitz Mark V don't have the issue [Quakespasm fixed it, fix was inherited to the other 2]. If you don't have the issue, this could have something to do with the problem. 

hmm, strange that it's loading source files onto the heap when normally textures are loaded with a file pointer. I guess I'm using the wrong method to re-open files in that case. I was not aware of this bug; do you know which quakespasm version introduced the fix? 

is it this?

Changes in 0.85.7
...
Reduced memory usage during reloading of textures 

and the Quakespasm changelog I think this falls under "video bug fixes" so maybe 0.85.5?

The fix is simple and mostly goes like this ...

FILE *f = NULL;
int datasize;
COM_FOpenFile (glt->source_file, &f);

if (!f) goto invalid;

datasize = glt->source_width * glt->source_height;
if (glt->source_format == SRC_RGBA)
datasize *= 4;

data = Hunk_Alloc (datasize);

// need SEEK_CUR for PAKs and WADs
fseek (f, glt->source_offset, SEEK_CUR);
fread (data, datasize, 1, f)

Where the above instead of loading the whole file, does an fseek to the right source_offset and loads <width x height x appropriate bpp> bytes.

You know ... looking at the above code, I'm not convinced offhand that is going to work right for a .tga or .pcx in a pak file.

[Then again, maybe it does for reasons that aren't immediately obvious to me ...] 

I'm thinking the fix isn't 100%

PCX data is generally (always?) compressed and TGA data can be RLE compressed or might be 8-bit expanded and then expanded to 32 bit.

Then again, I might not be seeing in the code where that is addressed.

[+1 to list of things to check out ...] 

Yes, the fix was done in v0.85.7:
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=633 

I'm pretty certain that code originated with me, but memory is hazy. The comment on the code you quoted is in my style anyway, and I'm in the habit of always initializing pointers to NULL, but I note that the current QS version is a little different (different comment, uninitialized FILE *f).

Anyway, TGAs and PCXs will fall through to the second condition as external texes use offset 0: "else if (glt->source_file[0] && !glt->source_offset)" - the "read the full PAK file into memory" problem should only happen with native textures inside BSPs or MDLs, where the offset is an offset into the BSP or MDL file, not into any PAK that may contain it (COM_FOpenFile will set up the file pointer correctly for the base file whether it's a loose file or a PAKed file, then we fseek from there).

There was a hack I did for DDS files where I added a SRC_DDS format and put the full file size into width, but with hindsight and in light of the above that wasn't even necessary.

Nowadays I'd probably be more inclined to glGetTexImage into an array of system memory buffers (malloc, not hunk) and delete each texture from GPU memory as it goes in. Then glTexImage from that array and free each buffer immediately after restart. Since textures are backed up by system memory copies anyway that wouldn't be any extra overhead that wasn't there to begin with. Would be much simpler and cleaner, and should also reload faster (no file I/O). 

Possible location of issue:

sv_main.c -> SV_ConnectClient ...

strcpy (client->name, "unconnected");
client->active = true;
client->spawned = false;
client->edict = ent;
client->message.data = client->msgbuf; <---- HERE
client->message.maxsize = sizeof(client->msgbuf);
client->message.allowoverflow = true;

Because ... server.h ...

byte msgbuf[MAX_MSGLEN];

And quakedef.h ...

#define MAX_MSGLEN 32000 // max length of a reliable message //johnfitz -- was 8000

And ...

sv_main.c SV_SendClientDatagram ...

qboolean SV_SendClientDatagram (client_t *client)
{
byte buf[MAX_DATAGRAM];
sizebuf_t msg;

msg.data = buf;
msg.maxsize = sizeof(buf); <--- Here

Because server.h

#define MAX_DATAGRAM 32000 // max length of unreliable message //johnfitz -- was 1024

Maybe ... not a sure thing but looks very likely right now. Not that anyone is going to be using GLQuake ...

I also kind of wonder if sv_protocol 15 demos will play back on GLQuake.

Knowledge pile +1 

Ok this is bloody wierd because I'm pretty sure it didn't happen before...

You know mods that replace start.bsp? (e.g. czg's czg07, or honey)

Well, I'm finding now that when running these mods it only ever loads the ID1 start.bsp

Anyone else had this problem? 

ignore the above I was being being a 'tard. 

 

I was playing apsp1 in quakespasm last night and noticed the mis-positioned elevator that mfx mentioned seeing too:

http://www.quaketastic.com/files/misc/apsp1_plat.jpg
http://www.quaketastic.com/files/misc/apsp1_plat.sav.zip

The bounding box is fine, so it doesn't affect gameplay, but it's just rendered in the wrong place.

I tried some different engines, and the problem started in Fitz 0.85. Fitz 0.80 is fine, as well as glquake/winquake. The lastest Darkplaces has the problem too though.

This is the entity text, from opening the bsp in a text editor:

{
"classname" "func_train"
"angle" "-1"
"sounds" "4"
"speed" "184"
"target" "3f_lift_p1"
"dmg" "5"
"noise" "plats/plat2.wav"
"noise1" "plats/plat1.wav"
"targetname" "tllift"
"model" "*10"
}

If I put a breakpoint in R_DrawBrushModel, e->origin is (0, 0, 0) and e->angles is (0, -1.40625, 0). The second component of e->angles seems to be related to the problem, if I zero it before the R_RotateForEntity call, the plat appears in the correct position. (I don't understand why adding a rotation to the OpenGL matrix shows up visually as the plat translated diagonally.) 

I have seen this before. The root cause is that func_train should not have an "angle" set. So I could blame it on the mapper. But, under most engines the -1 is rounded to 0, causing no visible problem. Therefore it's hard to blame the mapper when the engine came out years after the map!

Fitzquake (and apparently Darkplaces) round the angle to the nearest representable value instead of flooring it towards zero, resulting in more accurate angles for rotating entities. However as you can see, -1.4 may be closer to -1 than 0 is, but -1.4 results in the mapper's harmless error now being highly visible.

As to why the small rotation appears to be a diagonal translation, remember that bmodels have their origins at the world origin, so a small rotation around the world origin would result in a large lateral move for the visible geometry of the lift.

The solution may be to disable the "improvement" of better rounding for angles. 

I remember seeing this with a lift in A Desert Dusk too, and, checking the bsp, sure enough it has a func_train with "angle" "-1". 

Rounding toward the nearest value is actually what the Quake code attempted to do, but did it wrong (due to an int cast of a float rounding toward zero, but the Quake code assumed it rounded down consistently).

So I'm both a little unnerved by the error, and inclined to blame it on the map rather than the engine, I could do a spot-fix for this specific map name but I don't normally do any spot-fixes for anything in the engine as I believe in having no map-specific or model-specific logic anywhere in the engine.

A .ent file could easily fix this...

sv_saveentfile while playing it, and then edit that one entity in there and any future loads will use the modified .ent file instead of the data in the .bsp.

A more important issue is that this angles is going to affect the MOVETYPE_PUSH directly because darkplaces supports rotated (and rotating) plats, so there is a physical difference here.

An alternative - however with unknown side effects - what if the engine chose to ignore incomplete vectors when parsing the entities? Because angles is a .vector field in the progs.dat, it is being parsed as a vector, it is an incomplete vector whose value is just "-1", right now this gets expanded to "-1 0 0" but perhaps it should expand to "0 0 0" due to incompleteness?