Cleaning up some code that newer worked.

[revelator]

the idea hit me after trying to get tochris GL renderer to accept colored LIT.

Code: Select all

   // ZOID: never allow players to go totally black
        if (e - cl_entities >= 1 && client_no <= cl.maxclients)
   {
      if (ambientlight < 8)
                        ambientlight = shadelight = 8;
   }


i still see this code piece in many engines in one form or another the problem is it newer worked

so why did it not work you might ask. well have a good hard look at the code above.

the lowest value light can have at any time before this is calculated
is 24 for the gun model which is set before we ever do the calculation above so the light amount the player gets is actually exactly the same as what the gun gets which is atleast 24 but newer below that comprende .

[Baker]

What about multiplayer?

Player #5 won't be the view entity. So the light on player #5 won't receive the minimum value of 24.

I'm thinking that the code you referenced above is that piece of code where WinQuake and GLQuake vary on player lighting in multiplayer.

In multiplayer in DOSQuake or WinQuake, a player standing in total darkness is absolutely dark. In GLQuake, some other player standing in darkness is visible ... even if a bit dim.

Code: Select all

   // allways give the gun some light
   if (e == &cl.viewent && ambientlight < 24)
      ambientlight = shadelight = 24;

.
.
.

// clamp lighting so it doesn't overbright as much
   if (ambientlight > 128)
      ambientlight = 128;
   if (ambientlight + shadelight > 192)
      shadelight = 192 - ambientlight;

   // ZOID: never allow players to go totally black
   i = currententity - cl_entities;
   if (i >= 1 && i<=cl.maxclients /* && !strcmp (currententity->model->name, "progs/player.mdl") */)
      if (ambientlight < 8)
         ambientlight = shadelight = 8;


[revelator]

trust me it works just fine removing it ill even upload some screenies if you want (from multiplayer also)

i cant say if the same goes for software quake though.




Uploaded with ImageShack.us

[revelator]

heres one from multiplayer.



Uploaded with ImageShack.us

[revelator]

darkest spot i could find in the standard multiplayer maps.



Uploaded with ImageShack.us

[revelator]

it also had me stumped for a while but thinking about it and if you notice the code above the piece where it should give players a minimum amount of light you might notice that the amount is allready clamped before checking for the player model any subseeding code with a value less than what its allready clamped at will just do nothing .

heres the entire funtion i use in realm atm. you might notice some strange flags like EF_MINLIGHT well i moved the minlight check clientside.

Code: Select all

void R_SetupAliasModelsLight (entity_t *ent)
{
   int      i;
   float   ang_ceil, ang_floor;

   // set to NULL initially - if R_LightColor fails then we can do a test
   ent->lightplane = NULL;
   lightplane = NULL;

   // always do this cos we need lightspot for shadows
   R_LightColor (ent->origin, shadelight);

   // save out lightspot and lightplane for shadows
   ent->lightspot[0] = lightspot[0];
   ent->lightspot[1] = lightspot[1];
   ent->lightspot[2] = lightspot[2];
   ent->lightplane = lightplane;

   // always give some light (btw all the other crap is not nessesary trust me)
   // the EF_MINLIGHT i based on an idea from tochris.
   if (ent->flags & EF_MINLIGHT)
   {
      if (shadelight[0] < 24) shadelight[0] = 24;
      if (shadelight[1] < 24) shadelight[1] = 24;
      if (shadelight[2] < 24) shadelight[2] = 24;
   }

   // rotating objects (i.e. pick-ups) will always have some constant light in order to
   // make them noticeable... (added from the last mhquake with opengl support)
   if (ent->flags & EF_ROTATE)
   {
      // set rotating objects to the largest of r/g/b
      float largest = shadelight[0];

      if (shadelight[1] > largest) largest = shadelight[1];
      if (shadelight[2] > largest) largest = shadelight[2];

      shadelight[0] = shadelight[1] = shadelight[2] = largest;
   }

   // clamp lighting so it doesn't overbright as much
   if (shadelight[0] > 192) shadelight[0] = 192;
   if (shadelight[1] > 192) shadelight[1] = 192;
   if (shadelight[2] > 192) shadelight[2] = 192;

   // light interpolation
   lightLerpOffset = (ent->angles[1] + ent->angles[0]) * (SHADEDOT_QUANT / 360.0);

   ang_ceil = ceil (lightLerpOffset);
   ang_floor = floor (lightLerpOffset);

   lightLerpOffset = ang_ceil - lightLerpOffset;

   shadedots1 = r_avertexnormal_dots[(int) ang_ceil & (SHADEDOT_QUANT - 1)];
   shadedots2 = r_avertexnormal_dots[(int) ang_floor & (SHADEDOT_QUANT - 1)];

   // set to a 0 to 1 scale, and reduce a little
   shadelight[0] = shadelight[0] / 224.0f;
   shadelight[1] = shadelight[1] / 224.0f;
   shadelight[2] = shadelight[2] / 224.0f;

   // interpolate and store for the next frame
   for (i = 0; i < 3; i++)
   {
      if (ent->lastShadeLight[i])
      {
         shadelight[i] = (shadelight[i] + ent->lastShadeLight[i]) / 2;
      }
      ent->lastShadeLight[i] = shadelight[i];
   }
}


and the flag in CL_ParseUpdate just after

R_TranslatePlayerSkin (num - 1);

// do not allow players to go totally black
ent->flags |= EF_MINLIGHT;

btw theres two of these so i set it on both.

the idea is partially from tochris.

[mh]

cl.viewent is not the same as cl_entities[cl.viewentity]

[Baker]

heres one from multiplayer.



Uploaded with ImageShack.us

You are using chase_active 1 ... which still is going to hit the following code ...

// allways give the gun some light

Baker --> cl.viewent is "you" This if statement is never true for a player that isn't you, so a "non-you" player never receives this minimum lighting of 24.

if (e == &cl.viewent && ambientlight < 24)
ambientlight = shadelight = 24;

Because "you" are the view entity, regardless of whether or not chase_active is 0 or 1.

But player #5 isn't your view entity. To test this offline, you'd have to add some bots or load up 2 clients and connect them.

So player #5 would be all black if you remove the code you are suggesting, as far as I know. DarkPlaces modified the lighting works the same as DOSQuake/WinQuake and the player would be all black in places.

[revelator]

i know cl.viewent = gun while cl.entities[cl.viewentity] = player if i got that correctly.

unfortunatly i dont have any bot code in realm atm so id have to see if i can load up 2 clients to check this out or get someone to join a game.

[revelator]

couldnt find anyone on the servers heh but i tried some time back and it worked there.

i think i know why my special version works though

the flag im setting for minlight is set like this.

Code: Select all

        if (num > 0 && num <= cl.maxclients)
        {
            // tranlate the player skins
            R_TranslatePlayerSkin (num - 1);

            // do not allow players to go totally black
            ent->flags |= EF_MINLIGHT;
        }


so basically it does exactly the same as the old code in R_DrawAliasModels doh only difference is not having to calculate the same thing twice so in that regard it could be considered an improvement at least (small one but hey).

[Baker]

I'm unusually aware of how the model lighting code minimums and maximums work because I consider the pitchness in DOSQuake/WinQuake but not in GLQuake an unfair disadvantage.

DarkPlaces, likewise, will pitch black players when the other clients being faithful to GLQuake don't ... making DarkPlaces, likewise, on disadvantaged terrain not only due to minimum lighting but what seems to be a cap on maximum lighting --- overbrighting players so intensely that you cannot easily tell what color they are --- a disadvantage in a team game against other NQ (and QW) clients.

These aren't "huge" issues in the scheme of things, but I am very aware of the subtle differences between clients in features in regard to fairness.

[mh]

Differences go a little deeper. Software Quake actually minlight's everything, for performance reasons:

Code: Select all

#define LIGHT_MIN   5      // lowest light value we'll allow, to avoid the
                     //  need for inner-loop light clamping
.
.
.
// guarantee that no vertex will ever be lit below LIGHT_MIN, so we don't have
// to clamp off the bottom
   r_ambientlight = plighting->ambientlight;

   if (r_ambientlight < LIGHT_MIN)
      r_ambientlight = LIGHT_MIN;

[revelator]

latest compile.

video menu still not working to great so dont use it but else pretty stable.

http://www.2shared.com/file/UseQ_mNp/realm.html

source code.

http://www.2shared.com/file/l6Zu44Xn/Realm-src.html

[Baker]

Just for illustrative purposes:

GLQuake compiled with the suggested lines of code commented out with 2 players (note that the other player is pitch black):



Original:



In the latter screenshot, the player does have some lighting. In the former screenshot, the player is pitch black.

And I was wrong ... the viewent isn't always you. With the minimum lighting of 8 commented out, even with chase_active 1 the player that is "myself" is still pitch black and not receiving the viewent minimum lighting of 24.

[Spike]

cl.viewent is not the same as cl_entities[cl.viewentity]

You did actually read that, right?

oh look, 8 is really dark.
oh look, the gun is more visible than the player. I wonder what its light level is. I'm almost willing to bet that its somewhere around 24.
humm...

:P