InsideQC Forums

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...

Haha ... well I do understand your point of view and what you are saying there.

However, I set a breakpoint in a couple of different engines and not all of them handle the lighting the same so at that point I was no longer quite so sure of anything and wanted to see for myself.

As an example, in JoeQuake derivates commenting out the code quoted in the first post has no effect like what Reckless suggests.

FitzQuake appears to ignore the lower bounds of 8 and instead opts for 24 as the minimum.

I know I don't often pull up the old GLQuake to check exact original behaviors. I'm not saying I didn't trust MH's answer, rather that with the codebase I was working with I was getting Reckless style results where commenting the code out did nothing.

These kind of things bother me and I'm stubborn and wanted to test it since I began to have some doubt.

cl.viewent is a placeholder entity_t struct that has nothing to do with anything in the cl_entities list. The only real reason for it to exist appears to be to enable the same drawing code to be used for the viewmodel as for other MDLs. It could have just as easily been done with globals otherwise.

cl.viewentity is (typically) a number between 1 and 16, and is an index into cl_entities. This is the real entity representing "you" in the game.

cl_entities[0] is the world.
cl_entities[1] to cl_entities[16] (assuming 16 players) are you and other players. The slot in here representing you isn't drawn unless chase_active is 1.

Software Quake just minlighted everything to LIGHT_MIN, which was 5. It didn't make any special distinction between players, the gun model or any other entity type.

GLQuake minlighted the gun to 24 (before dynamic lights are added) and other players to 8 (after dynamic lights are added). No idea why the change was made; it might be experimental code (GLQuake was never anything more than experimental in intent), it might be the Way Things Are Meant To Be From Here Onwards, it might have been because of no fullbrights or overbrights, it might have even been a mistake. The only hint we have is that the minlighting of other players to 8 was added by Zoid after he took over maintenance of the codebase, so that would be sometime in mid 1997 when Carmack had moved on to Quake II. It's definitely not original code and shouldn't be seen as Word Of God.

FitzQuake uses 24 because it's 3x8 - one for each channel in RGB. It also scales things a little differently, but the intention seems to be to preserve the colour balance while minlighting. (It uses 72 for the gun model - 3x24 - for the same reason.) It does however get the order different from the way GLQuake did it, applying both minlights after dynamic lights are added (remember that GLQuake did the gun before).

The only reason for software Quake's minlighting to 5 was a performance optimization: It seems reasonable to assume that if this optimization wasn't needed there would have been no minlighting, although other factors may have then come into play.

Concerns about fairness in multiplayer shouldn't come into this. It's client-side, so everything is wide-open for exploitation. The only half-way reasonable solution would be to move MDL lighting to the server and make it part of the protocol, but a malicious client could just read the data and ignore it. This is a battle that can't be won.

and for a moment there i thought i was going insane

had a few goes with different quake engines and surely not every engine had the same results i was getting so sorry for any misconception.

the reason i thought this would apply to any engine was that if minlight was allready clamped to 24 before checking for players then minlight would newer go below 24 even if it was a totally different entity all together (not allways true as i found out).

but in some engines it is...

Personally, on a player standpoint, I would like the gun model and the player model to be the same. This helps you look at your gun and know how dark it is for others to see you as (ie corner lava-room on dm2)

FitzQuake uses 24 because it's 3x8 - one for each channel in RGB. It also scales things a little differently, but the intention seems to be to preserve the colour balance while minlighting.

I just looked over this code again, it looks like i didn't do the math right. I should have multiplied each channel by the same amount instead of adding the same amount.

well atleast it helped you to squash a bug comming here

and agree with rook i think it would look mighty funny to have a white man carrying a black gun

btw just to nag on try running cppcheck on the quake source the result will undoubtly scare you a bit

result from a pass i made on cleansrc was 500 unused or uninitialized variables so i removed them and guess what it still runs just a load smaller now hehe.

and heres a version of TQ148 which i did the same on.

btw this is not the standard TQ148 from tomaz i made certain changes...

http://www.2shared.com/file/rDcZTCjl/TQX.html

let me hear your thoughts.

Makaqu style entity lighting (modded software Quake) looks good in darkish maps. Simple directional/ high contrast

indeed

qbism wrote:Makaqu style entity lighting (modded software Quake) looks good in darkish maps. Simple directional/ high contrast

However, it does bug out in some extreme circumstances, like when using chase_active 1 and walking with the camera looking upwards while semi-entering the player's model. I've got a screenshot of this somewhere, showing parts of the skin with the wrong colors, most probably due to color indexes being wrapped around the colormap.

Its directional lighting algorithm is also crap. I've tried through trial and error to get it working with multiple light sources, but it only works with the nearest one.