August Lab Report #4 of 12 news - Zircon Engine - a "DarkPlaces Mark V" project mod for Quake

Aug 30: Linux Compile Issues Reportedly Fixed:

There were Linux users reporting that Zircon would not compile for them. In v 36, made some changes to the source to try to address this. Most of the users who had compile problems on Linux seemed to have the same exact error. Today: One user that previously had compile errors has stated that the version 36 compiles fine on their system (Ubuntu latest LTS).

Update of the Update: Compatibility Issues? Nevermore.

I have been coding a solution to entirely eliminate the "DarkPlaces compatibility problem" and without a shadow of a doubt it will. The first version will do all maps that classic Quake could run which covers most maps pre-Arcane Dimensions. Releases like Travail, Nehahra, Insomnia, Marcher Fortress.

The second add in protocol 999 support, which DarkPlaces does not have, which should cover 99.99% of existing maps (anything not hard locked to an engine target). Then do the Quake Re-Release fix update. Occasional visual differences will remain possible, they won't/can't affect gameplay.

The angle is that never knowing if DarkPlaces will play X, Y or Z correctly is something that must be resolved once and for all.

"It just works!" is what everyone wants when playing a map.

DarkPlaces has tons of great features and is quite remarkable and it is quite an amazing engine. I don't believe they knew how to address this, but a 9 year old experiment sitting on my hard drive knows exactly how -- which is funny because I never figured out anything to use that experiment on.

Update: Tried the Quake Re-Release In DarkPlaces to assess issues.

Diverting attention to that. I would suspect Zircon will have a fix in 24, 48 or 72 hours. I want to do them all at once to have a single update that the DarkPlaces developers could use to do the same to DarkPlaces if they wish. I would think 24 hours is the most likely (only because I think due to a lack of an obvious font for broad localization, I'll do English only).

Roundwave Water

"Roundwave" is a vertex deformation added to Zircon version 31 from Blood Omnicide DarkPlaces. A red light was added to the scene. Roundwave has an origin that ripples outwards. Pictured: 2012 Intel Integrated Video 72 fps with cl_maxfps 72.

(Update: Wanted to see how DarkPlaces without roundwave would react to "roundwave" deform ... it is silently ignored. Compatibility with official DarkPlaces is important.)

Bad video card, old computer --> high frames per second.

Water Experiments (R_Water 1 Version)

The above water is rendered with a a 2012 laptop with Intel Integrated Video with r_water 1. It is about 32 lines of code different than DarkPlaces.

A week or 2 ago, I found some quality DarkPlaces shader documentation on Blood Omnicide's wiki. A couple of keywords on the wiki didn't exist in DarkPlaces. I decided to look through Blood Omnicide's source code and added 2 shader keywords to Zircon to test them out.

And they provide some of the effect that gives the above water the feel it has. In the above image, the Q3 "bulge" deformation is used for the wave effects. In DarkPlaces, this seems to be 75% implemented but without the missing 25% it does nothing as far as I can tell.

The important part to me that it will not error in DarkPlaces, any use of the effect will degrade nicely in the current form of DarkPlaces without the wave effect.

R_Water 0 Version (Immediately Above)

Looks so similar to the r_water 1 version that it is hard to tell a difference, a close look will reveal this one does not show the ceiling lights reflected in the water.

On my 2012 Intel Integrated Video, the r_water 1 version runs at 40-50 fps since r_water 1 renders an extra reflection scene -- the r_water 0 version gets 72 fps with cl_maxfps 72.

I like an engine and maps to run smooth and fast on even bad hardware.

Q3 Map Format "Lit Water" (Supported, Verified)

There is a red light next to the water. This water does not have "nolightmaps" in the shader. The red light to the right is affecting the water.

Common/MonsterClip (Shambler In Box of MonsterClip Walls)

While looking through the Blood Omnicide source code, I saw some monsterclip code (I didn't need it). I did not see any shader keyword support in DarkPlaces for "monsterclip" and wanted to know if it works.

It does. The Q3 map compiler handles it and flags a surface.

In Q3, "common/playerclip" is similar to Q1 "noclip". The "common" is just the folder where all these textures live like "common/trigger" and such. Monsterclip is not in the original Quake 1 map compiler, but may well be in modern ones and some mods added "monsterclip" to the Q1 map compiler, as monsterclip is a Quake 2 feature.

In the above, notice the monsterclip blocks the Shambler's view. Monsters cannot see through monsterclip.

Note:

• I first built a box of "common/botclip". The monsters walk right through it. It does nothing!

r_fakelight 2

I saw this in the DarkPlaces source. It lights a map ignoring lightmaps. The effect is interesting, it is brighter where the player is and in the distance it starts to get darker. r_fakelight 1 can light a map with no lights, r_fakelight 2 is to force it to light a map that is not missing light data.

(Update: I was looking through current betas of DarkPlaces, in particular the glsl shader text. I noticed the shader text seemed to lack r_fakelight. Started the 2023 beta, r_fakelight is available but does not work.)

Q3 shader - autosprite2 (brush in map renders as sprite)

A brush that uses this texture will always face you, rotating along its longest axis. Wanted to know if it worked and see it in action.

Notes:

• Lit sprites in DarkPlaces did not seem to react to vertical lighting. For instance, a light pointing above or below seemed to have the same effect on a lit sprite. Code in the engine said "sprites lit by lightgrid" -- need to find out if this means lit by the lightmap for the surface below it or if it is similar to the Q3 lightgrid where the vertical granularity can be specified to the map compiler with "_gridsize".