Zero Ping Movement Version 1 (Quake Re-Release Support Improved) news

March 9: Flashlight For Almost Any Mod (Zircon Beta #40 - Win64 / Linux)

Flashlight Mod: Flashlight Mod Download. You can also set the flashlight color (red or whatever, instructions on download page).

I turned the KleskBY/Baker flashlight modification into a csprogs.dat that can be used with standard Quake and almost all single player releases, so you can play almost any single player release with a flashlight. jakub1 prompted this.

March 8: Release #40

March 7: Refinements

Needed to add some extra engine support to have countdown clocks for a "race against time" in the Intermap Demo.

Modified "shaderprint" with "showtex 1" active to print the shader of the texture looked at.

AND: What .shader file has the text of the shader and where is that .shader file located -- like the pak/pk3 or directory.

March 5: Switchable Lights Q3

Trying to wrap up the Intermap Demo, an actual article soon ... made switchable lights in Q3 map format easy to do in the map editor. Several other wrap ups done, some more to go.

March 3: Release #39

"shaderprint textures/mytexture" will print the shader text to the console immediately for selected texture.

"pak_this_map" will display texture and shader dependencies for the current Quake 3 map including skybox, dpreflectcube, animmap (animated textures directive for Q3) and any other texture dependencies.

"pak_this_map yourfolder" will copy those files to "yourfolder". (Type "folder yourfolder" in the console and Zircon will open that folder in Explorer).

"pak_this_map yourfolder overwrite" will cumulatively update yourfolder with a new map and update the shader text to add the new shaders to the existing file. This is to pak up 2 or more maps that use common textures etc.

March 2: Pak This Map

The next Zircon will have a command that will print the text of a shader to the console and say what file it was in, it does not have a name yet -- maybe "shaderprint".

And the magical "pak_this_map <name your folder>" command which will copy every map texture and dig through shaders and find cubemaps and all the other glorious hobgoblins that come together to form a Q3 BSP --> and throw them in a folder with .shader file that contains all the shader text for the map in one file.

It was not fun writing this process, but will be a lot of fun having it done automatically with a single command. I might make the command "cumulative" so the command can be repeated for multiple maps and it accumulates only new shaders in the text file.

March 2: Quake 3 BSP Packaging

End: I'm going to turn this tedious monotony into a command in Zircon.

Begin: I've seen this problem one time too many. And it is also the final time. I wanted to .pak up this map, it is a Quake 3 format map and I want the pak to contain the textures and shaders needed for it.

r_listmaptextures will list the textures, but I will still have to hunt around. The textures might have some extra _norm versions and who knows what else.

And then you have the Q3 shaders .. which can be in several different files and maybe 15 lines each.

That is a ton of work for a human that a machine would be able to do very quickly.

March 1: Idea Paid Off

Hilarously, this going to be in the Intermap Demo as the lead-in to the Quake action. I wanted to pack as many of the experiments into the Intermap Demo as possible and this idea proved great ... and you'll be able to run around in this map.

[I am hoping the construction crew gets weekends off -- need a break from the constant noise ...]

February 29: Release #38

Several new features added, most discussed below.

Had planned to finish the Intermap Demo today, however some outrageously loud construction is occurring outside -- it's so loud I am laughing as I write this because it is so funny how loud is it -- there is a crew of 20 to 30 and they are hard at work and having fun while doing so -- but very, very loud.

February 29

In the Intermap Demo -- which I expect to release in 24 hours or less -- I want the concept of a world clock in the game. I realized to make that work transparently, I need to some extra information in the engine extension.

Upon re-entering a map, the QuakeC "time" variable must have the value it had when exiting the level previously -- as you may leave a map with a door closing or opening. Upon returning, you want the door to close, right?

This means had to add a new field to save accumulated all-maps time on exit and a similar field for entering and extend the save games and the intermap state preservation system to include these times, and expose them to QuakeC.

The mechanism I implemented also provides QuakeC a method to see much time has elapsed since you last left the map, potentially giving QuakeC the opportunity to make adjustments upon return.

February 28: Quake Retext Project JPEG

Quake Retexture Project TGA pk3 sizes were: 407 MB and normal maps 856 MB = 1.2 GB grand total +/-

JPEG version using JPEG _alpha textures -- except for sky textures, I could not make those work so the sky4.tga and so on are in the JPEG version: 67 MB and normal maps 118 MB, so 181 MB grand total.

Link: Quake Retexturing Project JPEG Set (181 MB)

85% smaller download size

Pictured: LEFT = Quake Retexturing Project TGA, RIGHT = JPEG version managed to make including _alpha textures since JPEGs cannot do alpha and normal maps use them.

Going to upload these to "DarkPlaces Classic Set".

JPEG is lossy, but for higher resolution textures even staring at a wall, can be hard to tell the difference.

February 28: TGA to JPEG _alpha

Quake Retexture Project set including normal maps is 1.2 GB. Zircon console command to split to JPEG supporting alpha channel ... results ...

Looks like the TGA to JPEG conversion of normal maps using the DarkPlaces method for supporting JPEG alpha images is making a PK3 around 18% the size of the TGA pk3. So a reduction of download size by roughly 80%. And this console command will be easily available in the future, so bonus.

That 1.2 GB texture data should be in the vicinity of 250 MB when everything is done for nearly the same result.

February 28: QRP Texture Set Thoughts

The Quake Retexturing Project has very solid textures. The Intermap Demo uses.

The QRP Texture Pak PK3 is .tga size = 400 MB
The QRP Normal Maps Texture Pak PK3 is .tga size = 856 MB

That is 1.2 GB ... I do not want the Intermap Demo to be 1.2 GB. And bad news! The normal maps have alpha channels -- the JPEG format does NOT support alpha channels.

I am writing a converter inside Zircon to do some alpha channel splitting and get all of that in JPEG and using a DarkPlaces feature that allows JPEG to use a separate file for the alpha channel.

We see where the QRP textures weigh in after the JPEG diet.

Adding this as a command in Zircon, Zircon can be used to convert even TGA with alpha channels into JPEG that DarkPlaces can use.

Zircon command: 

jpegsplit textures // load all TGA in supplied folder, write them as .jpg to same directory

February 27

The torches in SMC and by extension used in Quake 1.5 / Quake Combat Plus were written by Nahuel who helped make SMC. I compacted and streamlined that torch code (below).

I happened to see some QuakeC in a mod KleskBY did and got his permission to use them in the Intermap Demo -- pushable objects.

I want to get the Intermap Demo out during February, I am trying to wrap it up and close it out, writing engine enhancements here and there as I encounter limitations that I dislike.

I was planning on 2D text effects -- but I'll need to cut that to get this completed in February.

When I say, "2D text effects" -- I don't mean the "text effects" typically seen in Quake -- I mean leveraging DarkPlaces TrueType Font support and creating worthy scriptable animations.

void Particle_Emitter_Think()
{
    pointparticles (self.fx_effects_number, self.emission_origin, self.velocity, self.count);
	
	self.nextthink = time + self.interval;
}

void torchflameparticle (vector emission_org, string effects_name, float is_flame_sound)
{
	if (is_flame_sound)
		FireAmbient ();  // Static sound

	StrSet (self.fx_effect_name_sa, effects_name);  // "smc_particleflamesmall", etc.

	self.emission_origin	= emission_org;
	self.count				= 1;
	self.interval			= 0.02; 
	self.velocity			= '0 0 0.02'; 
	self.fx_effects_number	= particleeffectnum (self.fx_effect_name_sa);

	if (self.fx_effects_number == not_found_neg1)
		zpr ("SV Effect ", QUOTED (self.fx_effect_name_sa), " not found");

	self.think = Particle_Emitter_Think;
	self.nextthink = time + 0.3 + self.wait;
}

void light_torch_small_walltorch()
{
	self.model = "models/q_items/flame_notop_torch0.mdl";

	precache_model	(self.model);
	setmodel		(self, self.model);

	Flag_Add_To (self.effects, EF_NOSHADOW);

	torchflameparticle (self.origin + '0 0 15', "smc_particleflamesmall", /*is_flame_sound*/ true);
}

February 26: Attachments/Task Scheduling

QuakeC only allows a single "nextthink" (future task) on an entity. This is what I do to raise that number from 1 to no real limit, spawn a short-lived extra entity to run a future task and switch self to the owner.

I want to attach moving lights to lifts, trains, etc. and have an attachment mechanism. (I also want the ability to attach particle effects. And models to doors as an option.)

One limitation of attachments, entity order for MOVETYPE_FOLLOW matters. Physics are run on entities in entity order, so if a following entity must be AFTER the entity it is following for the physics to work nice.

However, I still want it to work even if this is not the case (for convenience of mapping) and allow seeing what it looks like before messing with the map editor to get the entity order right (which ultimately has to be done as MOVETYPE_FOLLOW on wrong ordered entities tends to be jerky).

Since it is not possible to attach to a future entity during entity spawn (as the future entity does not exist), we schedule the attachment for 0.1 seconds in the FUTURE when that entity WILL EXIST, using task scheduling like this ...

TaskServant_Schedule_Task (self, Attachment_Late_Ugly, time + 0.1);

void Attachment_Check ()
{	
	if (!self.attach_to) return;

	self.aiment = find (world, targetname, self.attach_to);

	if (!self.aiment)	{
		dpr (self.targetname, " cannot spawn-time find (Ent order matters!) attach_to ", QUOTED (self.attach_to));
		TaskServant_Schedule_Task (self, Attachment_Late_Ugly, time + 0.1);
		return;
	}

	dpr ("Found attachment ", etos(self));

	attach_x_to_y (self, self.aiment);
}

void TaskServant_Run_Task ()
{	
	entity eservant	= self;
	entity e		= eservant.owner;
	
	void() scheduled_function = eservant.think1;

	e.task_servant = 0;
	eservant.owner = 0;

	Self_Push_To_Var_Set_To_This (oldself, e);
		scheduled_function (); // Run as owner
	Self_Pop_From_Var (oldself);

	remove (eservant);
}

void TaskServant_Schedule_Task (entity e, void() schedule_this_func, float when_time)
{
	if (e.task_servant) {
		// This shouldn't happen
		dpr ("Removing previous taskservant");
		remove (e.task_servant);
		e.task_servant = 0;
	}

	entity eservant	= e.task_servant = spawn();
	eservant.owner			= e;
	eservant.classname		= "TaskServant";
	eservant.think1			= schedule_this_func;
	eservant.think			= TaskServant_Run_Task;
	eservant.nextthink		= when_time;
}

Note the spark emitter pictured above, any effect in effectinfo.txt can be set for both the particle effect and optionally any flash effect, so quite possible to add a new effect into effectinfo.txt and specify it in the map editor and run it. This is the opposite of hard-coding effects.

(Additionally, the whole process in QuakeC was designed to be able to optionally off-load effects to CSQC, which can be important for multiplayer capable works.)

February 25: Moving Real-Time Lights

Made using moving real-time lighting easy in the map editor. Trying to pack some "Lab Report" topics into the Intermap Travel demo, converting them into easy-to-use features in a map editor.

Color "4 2.56 0" --- in DarkPlaces white is "1.0 1.0 1.0". 100% red, 100% green, 100% blue. 400% red 256% green is an overbright orange. The colors beyond 1.0 (100%) are overbright (maximum of 8.0).

Angle is the angle of the light, avelocity is the rotation speed, and "skin 12" is "cubemap/12bk.tga" (plus the other sides) -- which is a window with panes.

"superlight" is blasting an area with high intensity white light at the same location, creating very heavy shadows -- used sparingly and in the right places can give an area a surreal feeling.

February 24: Smoke Thoughts

Attempt at getting some better looking smoke. Spent more time on this than desired, discovering a difference between DarkPlaces Beta and DarkPlaces Classic sprite rendering with additive sprites plus addressing it.

So another addition in upcoming Zircon Release #38.

February 24: Flashlight Thoughts

At first there was the EF_BRIGHTLIGHT or sometimes EF_DIMLIGHT flash light in Quake. KleskBY made a much improved flashlight that utilizes rarely used DarkPlaces features for better customization.

I had a thought about how to take KleskBY's flashlight make it distance responsive with limitations.

code:

// intermap_weapon_flashlight.c

.float is_flashlight_on;

void flashlight_think ()
{
	entity eflash = self;
	entity plyr = self.owner;

	if (plyr.view_ofs == '0 0 0' || plyr.health <= 0) {
		self.think = SUB_Remove; // Dead or intermission or cut-scene
		return;
	}
	makevectors	(plyr.v_angle);

	vector src = self.owner.origin + v_forward * 3;
	vector  direction = aim (self.owner, 100000);
	traceline (src, src + v_forward * 2048, COLLIDE_HIT_ALL_0, self.owner);

	float distance = vlen (trace_endpos - src);
	float truedist = distance;
	if (distance > 200)
		distance = 200;

	float luminance_factor = 600 - distance;

	if (luminance_factor < 20)
		luminance_factor = 20;

	eflash.origin = plyr.origin + '0 0 20';	
	eflash.origin += v_forward * sqrt(truedist) * 4;

	eflash.light_lev	= luminance_factor;

	eflash.angles_x = -(plyr.v_angle_x - 180);
	eflash.angles_y = plyr.v_angle_y;
	eflash.angles_z = plyr.v_angle_z;

	eflash.nextthink = time + 0.02;
}

void flashlight_on()
{
	entity myflash		= spawn();

	setmodel	(myflash, ""); 
	setsize		(myflash, VEC_ORIGIN, VEC_ORIGIN);

	myflash.movetype	= MOVETYPE_NONE;
	myflash.solid		= SOLID_NOT;
	myflash.color		= '8 8 8'; // Maximum overbright white
	myflash.pflags		= PFLAGS_FULLDYNAMIC_128 | PFLAGS_NOSHADOW_1;	
	myflash.skin		= 237; // cubemaps/237nx.tga
	myflash.owner		= self;
	myflash.classname	= "flashlight";
	myflash.think		= flashlight_think;

	Self_Push_To_Var_Set_To_This (oldself, myflash);
		flashlight_think ();
	Self_Pop_From_Var (oldself);
}


void flashlight_toggle ()
{
	sound(self, CHAN_AUTO, "weapons/flashlight_click.ogg", 1, ATTN_NORM);

	if (self.is_flashlight_on == false) {       
		self.is_flashlight_on = true;
		flashlight_on ();
		return;
	}

	// Turn off
	for (entity flashlight = findchain(classname, "flashlight"); flashlight; flashlight = flashlight.chain) {
		if (flashlight.owner != self)
			continue;
		
		self.is_flashlight_on = false;
		remove (flashlight);
		return;
	} // for	
}

February 23: menu_keylist.txt

The Intermap Travel Demo has 2 small extra features and I want them in the key menu - a flashlight and the ability to place an explosive.

I want anyone making a mod to be able to do this easily, if they choose.

How do you put them in the menu? You can't (*).

DarkPlaces -- you can replace the entire menu system with Menu QuakeC (you'll need to write a video menu).

KleskBY is the only individual I know who has done this -- he is an unusually high tier DarkPlaces modder who can also do engine coding -- every other instance was a project team -- like Xonotic / Nexuiz (there are other projects that have done this, I can't remember the mod names at the moment, I'm sure every commercial DarkPlaces game like Doombringer, etc. have done this as well).

Seems like too much add 2 keys to the menu?

So new upcoming feature --> menu_keylist.txt .. so normal regular modders can easily do this -- looks like:

// menu_keylist.txt
// bind                 description
"+attack"               "attack"
"+jump"                 "jump"
"+zoom"                 "zoom"
""                      ""
"flashlight"            "flashlight"
"placeexplosive"        "place explosive"
""                      ""
"nextweapon"            "next weapon"
"prevweapon"            "previous weapon"
""                      ""
"+forward"              "move forward"
"+back"                 "move back"
"+moveleft"             "move left"
"+moveright"            "move right"
""                      ""
"+left"                 "turn left"
"+right"                "turn right"
"+moveup"               "swim up"
"+movedown"             "swim down"
"+run"                  "run"
""                      ""
"messagemode"           "talk"

February 22

DarkPlaces coronas in the map editor -- no creating an .rtlights files and they can be added or removed via QuakeC. It's 20 ish lines of engine code (and posted the modification on the DarkPlaces github).

They can be used to create flare-like light effects or a radiation zone or give a light source a corona.

On another note, gave Enforcers a laser effect for upcoming Intermap Travel Demo.

February 21: Complex New Release #37

Intermap Travel Support including Save Games that store game states of every map visited.

Pictured: Upcoming Playable Intermap Demo -- Complete With QuakeC and Map Sources. 2 days out?

"gl_overbright_models 1" and "gl_overbright_world 1" options that render more like Quakespasm and derived engines.

Defaults off right now -- need to check how looks in content targeting DarkPlaces. gl_overbright_models 1 is likely to become the default for Zircon. gl_overbright_world will stay at zero, DarkPlaces content that use real-time lighting and effects look wrong with gl_overbright_world 1, but might be good with traditional single player releases maybe (?). Either way, it will soon be in the menu.

Readme has other features, most already discussed recently but they are now released.

February 20

Overbright experiment to try to mimic Quakespasm/FitzQuake appearance. I never was able to pinpoint what the difference was between DarkPlaces rendering the start map and Quakespasm.

A comment by MissLavenderLQ at DarkPlaces github led to this experiment to simulate what Quakespasm/FitzQuake do with rendering models.

I'm not sure how this fits into DarkPlaces -- no DarkPlaces content expects this -- but I will add gl_overbright options in the menu and possibly default gl_overbright_models to 1 for Quake.

February 19

Going to soon release an intermap travel demo with QuakeC and map sources. During the process, accidentally created an easy method for lighting in the engine.

As a result, the intermap demo will a unique experience in its own right.

Note to self: EF_NOSHADOW needs supported for static entities. DarkPlaces does not support very much for static entities, a while back I added enhanced static entity support to Zircon for colormod, alpha and I included EF_ADDITIVE. I didn't think about EF_NOSHADOW. (Feature has been completed for next version).

EF_NOSHADOW prevents DarkPlaces from casting shadows from an entity -- and without this, wall torches will cast shadows and their shadows are "not nice". I worked around this by instead setting alpha to 0.99 -- as DarkPlaces will not cast shadows for an entity with an alpha less than 1.

February 19

February 17

Intermap travel -- re-entrant maps and if you save a game, it stores the game state every map you visited into a Quake compatible .sav file.

The end result is quite nice. Gets recorded as a "W", but I did under-estimate the difficulty of this one.

Within 3 days, I expect to document this and take E1M1, E2M1, E3M1 and E4M1 (these are all base maps) tie them together and make a playable intermap demo (with QuakeC source code) explaining/demonstrating how it works (it is easy).

February 17

String concatenation. String concatenation is fast in C, but reallocating and duplicating and strcat-ing an ever-expanding string 16000 times is slow using this process.

When does this come into play? Intermap travel, writing out all the entities to memory and accumulating them for multiple maps. I actually did not get to witness this, I knew in advance it would be a problem.

But you don't have to go that far to find slow string concenatation, the Zircon "copy" command copies the voluminous DarkPlaces console buffer to the clipboard and once it hits 4000 to 5000 lines can you feel that the "copy" command is not instant and at around 10000 lines it takes a second or 2.

I added a new string type to Zircon, rather than think of a name I just called "baker_string_t" so someone reading the source code would know this was a modification to DarkPlaces, not inherited.

These strings over-allocate with concatenation and they actually do not use C "strcat", they know the length of their contents and just tack it on it the end if possible, otherwise reallocate. Not rocket science, Microsoft has done this since at least the late 1980s in various programming languages, but standard C library sticks with basic C strings.

End result: copy of 16000 lines of console text is effectively instant in the upcoming version, instead of taking a second or 2. DarkPlaces supports several kinds of special character encodings in the console including unicode and colored text, copying to the console has to decode it and I have it strip color codes so when the new version produced an essentially instant result -- that was the result hoped for (but wasn't sure if that would be the outcome).

* Although I called it "strcat", DarkPlaces actually uses strlcat -- there is not a single usage of strcat in the entire DarkPlaces source code. strcat can overrun buffers, strlcat never overruns a buffer.

** DarkPlaces was one of the engines I frequently read source code of when learning engine coding years back (JoeQuake, ProQuake, FitzQuake, ezQuake and Bengt Jardrup's Enhanced GLQuake were others). DarkPlaces has comments in the code by various authors -- I saw these comments early on, so I was never a fan of strcat, strcpy or other functions that do not guard against overrunning buffers.

February 16

Getting intermap travel right has a large number of details. Save games need to have the data for all maps ever visited. This requires tracking visited maps. Writing saved states within a save game is unwieldy and the file sizes are large. So I implemented zlib compression (zlib is what .zip files use) -- however only text data can be stored in .sav file. So the compressed binary data is base64 encoded (increases size) but the overall size reduction looks to average about 85%.

The save game files should remain compatible with DarkPlaces (although DarkPlaces will lose the re-entrant data) and I looked through FTEQW to try to ensure that the method used does not collide against FTEQW.

While checking for that collision, I saw FTEQW has a "serverflags" fix which DarkPlaces does not have. In Quake, this is where save games or dying can lose the runes you collected. Implemented that.

Also reworked the changelevel QuakeC function to not collide against FTEQW's changelevel function.

For example, if intermap travel requires extra changelevel parameters -- it is ok to make an extended version that is incompatible with FTEQW. However, the type of incompatibility must be where the incompatibility extends changelevel with new fields -- not with different existing fields.

DarkPlaces and FTEQW have maintained compatibility standard that allows each engine to extend itself to mirror a functionality in the other engine -- that is the benefit that standards provide.

Getting things like this right needs to consider compatibility with DarkPlaces, FTEQW and Quakespasm (the baseline standard for traditional Quake engines).

It is a lot of work and a lot of detail checking. But it is that type of detail and consideration that gives Quake a wide variety of standardized engines and a very nice tool set.

February 14:

Zircon is gaining a form of intermap travel that is compatible with several different scenarios including multiplayer and coordinate based intermap travel. The first prototype of this has passed the initial test, there is more to do.

The intention is to support jumping in a vehicle on Map A and flying or driving to Map B, you will appear on Map B based on coordinates.

Pictured: Texture testing.

However, the real end goal is player 1 being able to be on Map A and player 2 being able to exit to Map B, while player 1 stays on Map A. (Multi-world intermap travel).

February 13

r_glsl_deluxemapping and r_bloom off and then on.

February 12

Sound attenuation. Not a common topic -- it is how sound dissipates with distance in a map. In large areas, this matters.

Pictured is the original func_mechanical test #1 I did when writing func_mechanical -- the ability to move map objects around by joints -- and with normal sound attentuation, the machine sounds go to zero volume over too short a distance. In QuakeC this ATTN_NORM (a value of 1). The opposite is ATTN_NONE which means infinite distance with no sound volume reduction at any distance.

ATTN_NONE is generally undesirable, in Quake it is probably most comedically experienced in cooperative play on a busy coop server --- every time a player tries and fails to open a keycard door, every player hears the failure at full volume everywhere on the map.

In deathmatch, a player dying by drowning is also a full volume sound all players can hear.

February 10

Reverse Order. Where it ended.
Level of detail reduced models using Blender's decimate tool.

Pictured: Quaternius open source models.

Where it started.

It started with spamming the "showmodel" command in Zircon -- which path aware autocompletes making it easy to spam -- to see what vehicles I have available.

Pictured: Most of those are open source models from Kenney.NL

After spamming the vehicles, I think about engine performance and I know the triangle count of those models. However, in huge quantities, you want lower level of detail models for those in the distance.

In a couple of releases in the future, Zircon will have engine-based level of detail model support -- likely with cvars specifying the distance cutoffs and a naming convention like "progs/shambler_lod_2.mdl" for distance cutoffs.

However, in practice this is for .obj and/or .md3 models -- although the model format doesn't matter.

February 9:

Pictured: cubemap built using "envmap auto" command and used with an online cubemap generator tool.

The "envmap" command in DarkPlaces Beta (and therefore Zircon Beta) was not outputting correctly. This command can be used to generate 6 images of a cube from your current position. Take those and use with a tool (or website like a site like Cubemap Generator @GitHub) to make an environmental cubemap that can be used in a Q3 .shader file.

The Q3 shader text to use the cubemap for a glass "reflection" would look like this:

textures/effects_sh/my_cube_reflect
{
	qer_editorimage textures/env/my_cube_reflect.tga
	cull none
	surfaceparm trans

	{
		map textures/env/my_cube_reflect.tga
		tcMod scale 1.0 1.0
		blendfunc add
		rgbGen identity
		tcGen environment 
	}
}

"envmap" is fixed in Zircon Beta Release #36 and there is a simpler form: "envmap auto" command (which in Zircon outputs jpegs not tga). Zircon Beta Release #36 also supports a map worldspawn key "sv_progs" "progs.dat" allowing customization of the progs.dat to run for the map. And you can use +quit in a command line and the engine will do the command line and exit (another small quirk of DarkPlaces Beta, DarkPlaces Classic honors +quit just fine).

(Also "map" command with no parameters prints all the worldspawn keys for a map.)

The result is similar to a slightly warped mirror. Can be used for glass or reflection-like effects without using "mirror" which has to draw the scene an extra time.

February 8

Testing/experimentation ..

February 3

Wanted to see how large of a map I could get a Quake 3 map compiler to compile. And if engine would load it and how fast it would render.

Although I have the fps capped at 72, uncapped it is 319.

Zero Ping Movement

Cooperative play even at 1000 *ONE-THOUSAND PING* is possible. This movement mode is extremely resistant to bad or even terrible connections. Video below ...

For a server to use this movement mode, "zircon_beta.exe -dedicated 16 +sv_allow_zircon_move 1 +map start" is an example command line.

It can be tried in single player with "sv_allow_zircon_move 1; cl_movement 2; map start". Typing "showzmove 1" will show when it is active (it auto disables on trains/elevators).

With Zero Ping Movement, players are not affect by external velocity factors (rocket jumps, etc.) but are able to use Wind Tunnels (hardcoded exception).

KleskBY did a Client Side QuakeC effort of full client-side movement and during testing in late November, I committed to implementing something similar in the engine. There were numerous technical barriers to getting the engine to do this well and do it without requiring any special mod support (it works with vanilla Quake).

Here is the KleskBY QuakeC only effort, it was solid:

Technical note: Zircon uses an extension system and is fully compatible with DarkPlaces, an unmodified DarkPlaces client would be able to connect although would not have the movement mode available. The Zircon extension system, modelled after FTEQW's extension system, the client and server exchange capabilities during connection.

Quake Re-Release Support Improved

2 Issues were reported with the Quake Re-Release, both issues should be fixed in Zircon Beta Release #34.

Real-Time Lighting Improvement

There was a discussion of an issue with real-time lighting in some situations. One of DarkPlaces devs (bones-was-here) fixed the issue that a DarkPlaces user had reported. It has been incorporated in Zircon.

Thanks, bones-was-here!

Pictured: Quake Rivarez Edition, a graphically maxxed out mod for DarkPlaces -- definitely, one of the best heavy effects mods.