Smith

---

Where is this in the header? I have been using the ancient jkspecs as reference

BinaryReader br = new BinaryReader(s); br.ReadBytes(8); bool transparency = (br.ReadInt32()!=0); br.ReadBytes(52); for (int x = 0; x < 256; x++) {     RGB rgb = new RGB();     rgb.R = br.ReadByte();     rgb.G = br.ReadByte();     rgb.B = br.ReadByte();     Palette[x] = rgb; }

---

The first 12 bytes before the padding are 3 floating point values denoting the color tint. So instead of skipping over 52 bytes, read 12 and then skip 40.

struct Header {    int8_t  magic[4];    int32_t version;    int32_t transparency;    float   colorTint[3];    int32_t pad[10]; };

Still haven't looked deeply into what that padding is. Might just be to pad the size of the struct to 64 bytes. Or maybe it's unused in shipped CMPs but does something... never tried messing with it tbh.

Surprisingly, if the color tint is 0, it doesn't seem to do anything. Neurotic (MLP4) has a custom palette that was likely created with community tools, which means the color tint is 0,0,0 due to them thinking it was padding. I'd expect this to darken the entire level, but it seems that's not the case. Rather, it seems that the original color and the tinted color are lerped based on the luminosity, like so:

color = lerp(color, color * tint, sqrt(dot(tint, tint));

This seems to reproduce the look found in the original game, so I assume that's the right way to do it. Obviously using the length of the tint means the value can go above 1, which seems... wrong? But I haven't dug into JK to see what it's really doing in that regard. Will let you know when/if I do.

Also, technically, since this is a float, it can be negative. I'm really curious about what JK does with negative tints...

LibSa Norec wrote:

glad to know I was helpful with the 3do lightning stuff. Hope I'll be able to further help somehow.

Seconded, glad we could help regarding the 3do lighting.

Not sure if you ever got to it since your shader pipeline isn't done, and maybe you already plan to, but you can generate emissive/glow maps from the 8-bit light palette and max(emissive, color) with them to get the 8-bit lights working again (or use 8-bit texture/alpha packing to max(light, glow) * color instead).

---

Notes regarding your research:

On the physics/thrust part, more specifically on how thrust is used to determine AI movement, it should be noted that the CircleStrafe AI instinct seems to modify how much thrust is actually passed into the actor as their movement speed is significantly decreased once that instinct is triggered. This effect can be seen in action in the JkGR DevLevel I've released some time ago. The friendly AI sometimes won't follow you at full speed after being engaged in combat, and I found that to be related to CircleStrafe.

Insertion offset is also used by CreateThing verb, with the thing being created at insert offset*-1 relative to the origin thing. This can be confirmed by changing the player model's X/Y insertion offset and jumping into water. I speculate the X/Y insertion offsets might also be used when attached to a wall the same way the Z offset is used for the floor, but I don't think there's any way to confirm this.

The Z variation from standing and crouching with an insert offset of 0 (or any low enough value) is of +0.005. Oddly enough, with an insert offset of 0 the player is not positioned at a distance equal to collidesize from the floor when standing but rather to collidesize+0.005, so if the floor is at Z=0 a player with a collidesize of 0.065 will stand at Z=0.07. An extra 0.005 is added to this value (to a total of 0.01 extra height) when crouching. Note that crouching seems to "force" a thing model's insert offset Z to 0, so it should be positioned at Z=floorZ+thingsize+0.01. I don't believe there's any relation whatsoever between these values and keyframes but rather that this value is hardcoded. None of these values or offsets apply when the floor is not flagged as such, with the thing being positioned at exactly Z=0.065.

Do you have any research made on the "maxvel", "maxrotvel" and "maxrotthrust" properties? From what I've gathered, 0x1000 Physics flags seem to cap a thing's maximum rotational speed at maxrotvel. I do not know however if that cap is applied in each axis individually or to the total rotational velocity. I don't remember ever seeing a thing's maximum velocity being capped by anything other than it's drag coefficient, so maybe some of the unknown physics flags might be used by maxvel in the same way as 0x1000 is used for maxrotvel. Maxrotthrust appears to be an actor's maximum "spontaneous" turning rate, and for the player, it seems to only have an effect on the turning rate if turning via keyboard, as mouse turning sensitivity appears unchanged.

While it's not on the subject of physics, I also have gathered info on template properties error, fov and chance which might be useful to you.

Now at the color effects session, you mentioned "jedi_rank" as being used by force powers to calculate the intensity of their effects. It should be noted that the rank used by force powers is not the jedi rank (bin 20, ranging from 0~8) but the rank for those powers themselves (or how many stars are assigned to them, ranging from 0~4). This means the maximum "Add" used by Force Blinding (and therefore by JK) is 250, not 290. Of course, this makes no difference on what is the actual maximum value, as your research points to a number closer to 290.

Regarding IR Mode, EnableIRMode forces the light values for the world and things, the first value being a 0~1 flex for the world light intensity (including things with 0x8 thing flags and excluding transparent level surfaces) and the second a 0~1 flex for thing light intensity (including sprites). A curious thing to note is that this forces a change in 3do lighting mode from Gouraud to Diffuse, which might be a hack used to improve framerate on ancient machines. Dynamic lights have no effect whatsoever in world lighting.