Zircon Engine - a "DarkPlaces Mark V" project mod for Quake

September 11: Sky + DarkPlaces (Download: Zircon Beta #65)

DarkPlaces really hates very, very large skybox faces, particularly in Q3 map format where they can be huge, and likes to cull them from the scene (cull = excluded from drawing). Zircon Beta Release 66 will have an option to tell it to not do that (it will likely default off, a mod or map can have a method to enable it -- it affects so very few maps).

More or less, going to make a cvar that gives skybox surfaces a free pass and avoid the frustum culling process entirely -- frustum culling hides surfaces that are not in front of you so all the stuff behind your back and such does not draw.

Logic used is simple enough:

if (this_surface->texture && Have_Flag (this_surface->texture->basematerialflags, MATERIALFLAG_SKY))
shall_pass = true;

Pictured: Not the greatest picture because have not added many lights to the map, but was having issue with the skybox not getting drawn on this test map. As a workaround, I had the option of turning off frustum culling, but that draws everything behind me too. Going to simply give the option for sky surfaces to stay out of the culling process.

September 9: 10 Minute Hill (Download: Zircon Beta #65)

The tool to paint up faces with a texture makes creating terrain like this in a 10 minute process.

In a map, I would probably scale that hill to be 10 times larger. And make some paths up the hill. The process to make using -- say Terrain Generator -- to make some terrain and then import it and convert it to super-efficient terrain where only the visible triangles are textured (and the rest have common/caulk -- causing the map compiler to discard them from draw lists in the Q3 .bsp) -- which reduces the triangle count by 80 to 90% has a pathway with the tool in future Zircon Beta Release 66.

The texture .shader looks like the following, it mixes a rock and a grass texture based on the angle of each triangle so steep sloped triangle faces get the rock and flat ones get grass.

textures/maps_sh/mountain_rock_dark
{
	q3map_lightImage textures/zz_terrain/snow_1.tga
	
	q3map_forceMeta
	q3map_nonplanar
	q3map_shadeAngle 179
	
	q3map_lightmapAxis z
	
	q3map_tcGen ivector ( 2048 0 0 ) ( 0 2048 0 )
	q3map_tcMod rotate 33
	
	q3map_alphaMod dotproduct2 ( 0 0 0.825 )
	q3map_clipModel
	
	q3map_lightmapSampleSize 64
	
	q3map_globalTexture
	
	{
		map textures/zz_terrain/rock_2.tga // darker rock1
		rgbGen identity
		tcMod scale 7 7
	}
	{
		map textures/zz_terrain/grass_1.tga
		blendFunc blend
		alphaFunc GE128
		rgbGen identity
		alphaGen vertex
		tcMod scale 7 7
	}
	{
		map $lightmap
		blendFunc filter
		rgbGen identity
	}
}

September 9: Automated Terrain Culling (Download: Zircon Beta #65)

In this screenshot from months ago, I am manually marking the upwards facing textures.

I am about done writing a tool to do this automatically. No one sane wants to paint 20,000 triangle faces with a texture.

This will allow some techniques using some terrain generators to efficiently make low-triangle terrain that the q3map2 map compiler can discard all the irrelevant faces (faces that are not pointing up regardless of how small the up angle is).

The technique I used reduced triangle counts from 25,000 to 2,000 (or less). It makes quite a difference.

September 6: Automated Road On Hills (Download: Zircon Beta #65)

Follow up ... The answer is yes, the decal road projection process works on hills, provided the start and end points are higher than the hill itself.

Pictured: The 2 point dirt road projector on a hill. The hill is textured with grass. The road projection is projecting the dirt texture on all surfaces.

September 6: Automated Road (Download: Zircon Beta #65)

Pictured: This road does not exist in the map. In the .map there are 2 point entities.

1. An "info_decal" point entity - the start of the road. This point entity targets the "end of the road". It specifies the texture and the repeat interval.
2. An "info_decal" that marks the end of the road.

I used a .map preprocessor (it is inside future Zircon Beta 66) to create all the entities to make the road, which is a series of decal projections. This is version #1. It isn't perfect but a solid start. The current design allows target->target->target->target -- so it is not A to B, but A to B to C to D ... with no specific limit. Need to work out some other small things.

Because it is decal projection, it should work if I were to have a hill in the middle, it would project it on the hill. I have not tested that as of yet.

The short version: I don't have to plant trees or vegetation myself. And making a road is getting very close to just 2 or more point entities, and letting a machine make the calculations to make it happen.

September 6: Up (Download: Zircon Beta #65)

Various:

1. KleskBY used TrenchBroom for working with the QUALKER 0.3 map Lost Village, which was largely or mostly constructed and worked with in Blender and then exported to Q3 map format with this Q3 Blender Export. I was not entirely sure what map editor he used to work with map source except I know J.A.C.K. proved to be troublesome for him -- I suspected it was TrenchBroom, but I didn't ask.

2. Speaking of TrenchBroom, there is something I am coding to give the Q3 map compile process a feature it does not have. During this process, I discovered I need to know how PatchDef2 works (these are patches -- non-brush model rectangles and curves and such) in the .map source, it is a slew of numbers -- fortunately, TrenchBroom Github had a discussion including a link to archive org documentation explaining what these numbers are. SleepwalkR and company = heroes.

3. The programming language C++ started out a C language preprocessor (or so I read). It added/edited/inserted source code -- a pre-compile step -- and then compiled in C. This was a very brief period. After my delightful experiences with q3map_surfacemodel, I want to automate some very tedious processes ... and right now I going to effectively preprocess the .map source. I seem to have it working.

I want to see if I can get decal projection to be at least somewhat automated.

September 4: 90 Degree Lighting = Bad (Download: Zircon Beta #65)

Working through things, I was trying to recall a lighting issue I had that was frustrating.

q3 skybox lighting shaders: Never use 90 degree lighting (high noon). Use 87 or 93 but not 90 degrees -- that means straight down and it does not light straight up surfaces very well ... straight up surfaces = walls or vegetation models that are straight up.

September 4: .Skin Files ... (Download: Zircon Beta #65)

Trying to make an interesting example map. Hope to finish sooner rather than later ... but we will see.

Meanwhile, DarkPlaces undocumented feature .. if you are making a skin file for a .mdl, the name it expects is "default".

Pictured: One quick way to have different looking NPCs -- thoughts for the future. (An NPC is a non-player character, and almost anyone visiting this site will know that, but let's cover the 1% case by explaining).

File: progs\player.mdl_1.skin

Contents:

// mesh name, texture name (one of the conventions for .skin files)
default,progs/player_skin_5.tga

The "default" is what any Quake 1 .mdl expects as the mesh name, I had to get to look through the engine source to make it work.

There are other ways to cause a model to use skins like editing a model and adding skins, the .skin file method in DarkPlaces allows more skins than the model supports (without editing the model).

September 1: Last Mile ... (Download: Zircon Beta #65)

Wrapping up loose ends for a QuakeC release. Too much to do in a single burst, so it will evolve on the fly and will probably grow the examples. I'll have to do phases, I have too many completed experiments and won't be able to do high quality test maps for each of them all at once.

August 31: Tree Fall V ... (Download: Zircon Beta #65)

Damage texture, elegant in map editor, can walk across the tree perfectly once it falls. I want to see if I can make where the final blow is hit determine the fall direction ... likely is something like ...

// vector wanted_angles = vectoangles (target_org - self.origin);

Not Pictured: A pretty solid sound effect from Pixabay that does well with this.

I'm sure there is an art to making good "damage textures" but this will work for now ...

Note to self: Make sure the damage from being hit by that is reasonably high ...

August 31: Win Some / Lose Some ... (Download: Zircon Beta #65)

I want this, but I want it to work in a sensible reasonable way (the way I achieved it the first time was not reasonable and used q3surfacemodel to paint the tree onto the func_door).

I happened to see something in the q3map2 (Q3 map compiler) source code that implied that misc_model can be part of other entities and after some research, I can make a misc_model and set the target to a func_door and q3map2 will make it part of the func_door.

However, this means the method I had planned on using for damage textures won't work because it is a map model and not an exterior model. Eventually, I'll likely devise a method that works with this method.

This is a solid win because of the various methods I could use to make a tree fall, this method is easiest to setup in a map editor and makes the most sense and is close to a totally conventional solution.

August 31: Damage Textures ... (Download: Zircon Beta #65)

Continuing to try to get a QuakeC mod release out ... trying to code "damage textures" for walls / doors -- in the case of a .bsp model entity -- like a func_door -- it will change framenum on the entity but if the model is .md3 or .obj it will instead change "skin" (would prefer same field for both cases but I don't see a way).

August 30: Auditing QuakeC Code ... (Download: Zircon Beta #65)

Amongst other things ... completed code for a func_breakable that uses the actual func_breakable parts as the debris. This code hates BSP models without an origin brush, the code checks for that situation and prints warning text to the console on map start if that scenario is detected.

Pictured: func_breakable multi-part lock that uses the actual lock pieces as the debris. The code is solid, the lock and fence appearance can be made more "fancy" -- the important part is that the code works. It's just a hasty mock-up to get the idea across.

Like I have said before, I am not someone who you will much find "talking about code". I think talking about code is a boring subject in general, but in this particular case I am "paying it forward".

The concept is that I do this right, explain it incredibly well and communicate it via illustration and manage to do it exactly right ... I may be "making a difference" in a long-term.

(I see non-obvious things that are hiding in plain sight ... I'll identify them in the future -- and it won't be kind of things anyone has likely ever heard before. I don't see "code" when I look at code --- I see "time". Future follow up ...).

August 28: Floating Debris / Lock Break (Download: Zircon Beta #65)

Using the nearest available .map for testing .. note that the one that landed on "land" does not float, but the ones that landed on water do float.

Note to self: Do a "4 corners" test or such to judge if it landed on water ... if one of the test drops was half-over water, no telling what it would do.

Break Lock:

Using some fence from "honey" for a quick mock up .. I made the lock, mostly good but the square part should be size reduced -- this is a hasty mock up, the code is the important part.

1. Quake likes to have buttons and doors bleed. Looks terrible here. Quite fixable (P0x Extras R4 invented the "no bleed" patch). I thought I could avoid it ... this proves ---> No.
2. Although not completed, the lock is 3 pieces. I don't want "random debris" falling if I break the lock, I want the actual pieces of the lock to fall to the ground -- and not in one hit. I just didn't complete the whole mechanic (each piece of the lock has the same name -- lock1 -- so when I complete the code, I can have the pieces scatter and fall.)

Extra note: if you ever watch monsters "come at you" in Quake, they can sometimes take illogical routes that do not head straight to the player and get caught up behind fences and such. Thought for the intermediate future ..

August 27: Total Quality Management (Download: Zircon Beta #65)

Close to releasing a mini-project that has some unusual capabilities. I'm crossing every "T" and checking out a number of small things and need to make some test maps and then produce documentation. I have been working through a ton of QuakeC and simplifying anything that looks like it needs it and even checking engine code to verify/document certain things.

Q: What is an example?

A: Having something that floats stuck to the ceiling and then if the player does something causing it to drop and hits the water making a sound and then bobs just a bit like something on water. There are several reasons why this is near impossible, but I thought of a way to make it happen.

Pictured: This lock in Q.U.A.L.K.E.R. 0.3 is not breakable. I'm going to make a breakable lock sample map for Quake. Apparently, I will also be making a lock -- was not able to find a suitable good looking low-poly model.

August 26: Haha -- Why? (Download: Zircon Beta #65 - Win64/Linux)

I laugh sometimes doing experiments. This time it was "Why is nothing ever easy?"

I successfully put this nice looking model to initial use ...

But the model itself is immune to scaling at least when loaded in the engine. Something I am not seeing so far is preventing me from reducing the visual size of this model at least via Noesis export scaling using something similar to "-scale 0.25".

Fortunately, I do get to laugh. One of the nice things about engine coding is that you can investigate and solve anything if you decide to. But yeah, I was not looking for a new Scooby Doo mystery to solve, but I have solid idea what the hold up is -- but without not quite knowing why (at least not yet).

On this plus side, the gloss map on the gloves and knife -- I took v_knife.png and used an image editor and did Image -> Edge Filters -> Trace Contour. Results pretty solid. Without a _gloss texture, the gloves look terrible with a capital T.

On the laughing side -- I wanted to see if the model looks nice in-game, and it does -- no matter what, this was not a waste of time. It is positive partial victory.

Source for the model is Sketchfab.com the model is licensed CC-BY so should I use it I'll need to credit it (I make efforts to credit all source works including CC0) and the license does allow modification.

August 24: Q.U.A.L.K.E.R. 0.3 (Download Q.U.A.L.K.E.R. Win64/Linux)

Standalone download.

August 22: Zircon Beta #65 (Download: Zircon Beta #65 - Win64/Linux)

"pak_this_map" -- which can bundle a Quake 3 map to a folder for converting to .pk3 will now dig through the map locating ".wav" and ".ogg" files (by looking through the BSP entities segment) and accumulate those files too.

(There are other changes in #65 -- see the download description or the readme).

"pak_this_map" example:

"pak_this_map" -- which has been in Zircon Beta since spring -- digs through .shader files and locates and accumulates .shader text blocks that the currently loaded map is using and writes those into a single .shader file.

If you load a Quake 3 format map, typing "pak_this_map fangorn" it will output all the contents the currently loaded map needs to run to a folder named "c:\quake\id1\fangorn"

You can then enter the folder in file explorer, select all files and right click -- and if you have WinRAR installed -- make a new .zip file named "fangorn.zip".

A .PK3 (a Quake 3 .pak file) and a .ZIP are the same thing, rename fangorn.zip to fangorn.pk3 and put in c:\quake\id1 folder and you are done.

August 19: WIP Image/KleskBY (Download: Zircon Beta #64)

Beautiful work in progress screenshot from KleskBY.

Entity distance cut-off in Q3 map format example:

{
"classname" "worldspawn"
"worldtype" "0"
"_keeplights" "1"
"_blocksize" "4096"
"_minlight" "24"
"_farplanedist" "16384" // Baker: This is the distance cut-off
"message" "Fangorn Beach Prototype"

As seen in the text, this is from the Fangorn Beach Prototype -- that map, while large, is not really large enough for _farplanedist to kick in except at the very extremes of the map.

A better illustration of _farplanedist .. if you watch carefully you can see buildings pop into existence in the distance. (below)

.MAP keys that start with "_" (underscore) are map compile-time keys for q3map2.exe (Q3 map compiler). Which is to say that putting "_farplanedist" into maps/start.ent file would do nothing because it is the map compiler that is responsible for the visibility calculations. _farplanedist is done during map compile.

August 19: QuakeC 1.06 in C Syntax ... (Download: Zircon Beta #64)

I finished this up 2 days ago.

Then I thought .. why make it specific to DarkPlaces/Zircon (and maybe fte). The main obstacle was the nicer/easier print messages (matters greatly).

I coded that away with little compromise so that it is possible to use the source code for all Quake engines and then uncomment a "#define DARKPLACES // Enables DarkPlaces/Zircon capabilities" in the progs.src.

The next issue that it felt that there were some issues/problems that could be solved and if I released it as-is, I would be missing an opportunity. So some optional extra coding became necessary and instead of avoiding the hardest and most annoying issues, those were the ones dealt with head-on.

And 3rd ... what I need to do here is communicate WHY this particular source code base is particularly useful (and it is). That means some explanation and it needs some animations demonstrating how much easier it is to do certain things.

This last part is the important part. Explaining what the value is and illustrating it and doing a solid communication job is the actual valuable part.

To be continued ...

Add: I am not someone who generally finds talking about code as "exciting". However, there are some very valid reasons that with some illustration will make some sense. Therefore, this mission is to take what is usually a killjoy of a topic -- "code" -- and illustrate/explain/communicate because I think in this case, it is going to matter.

August 17: QuakeC 1.06 in C Syntax (Download: Zircon Beta #64)

Later today going to release an unexpected mini-project:

1. QuakeC 1.06 source code in full C Language Syntax. fteqcc supports this and if using a C language IDE like Visual Studio, Visual Studio will know all the functions in your QuakeC and know all the variables in your QuakeC:

• This means it can autocomplete anything like variables or function names.
• This means you can hover over a constant and it will say the value.

This would likely work with any other C language IDE.

This QuakeC 1.06 in 100% C language style is Zircon/DarkPlaces (maybe fteqw too) specific because it uses some DarkPlaces string functions to simplify and shorten printing code.

2. CSQC Zero (for Zircon or DarkPlaces)

CSQC Zero is the source code for CSQC that compiles but is just full standard Quake -- which is more code than one might expect as in CSQC the code must handle intermission, death, setting up a view and some other chores.

Additionally, both these projects use what is an enhanced "dpextensions.qc" and "csqc.qc".

The traditional dpextensions.qc and csqc.qc have always been incomplete in some regards and used slightly inaccurate function prototypes. I compared the function prototypes to the engine code in quite a few cases and corrected and documented depending on the situation.

And many of the function definitions were missing optional parameters.

This will allow fteqcc to more accurately provide compiler warnings (like supplying too many parameters to a function). Many DarkPlaces functions claim to be full variadic (can take any number of optional parameters) but only actually accept a certain number of parameters (often 8) -- and yet there are certain DarkPlaces functions that are fully variadic (sprinf is an example).

I also more completely listed constants. I noticed a fair number of constants (RF_AXIS, etc.) that are listed in the engine and not listed in any .qc files.

I used this as the starting point for QuakeC 1.06 in 100% C Syntax:

quake-c-version-106

August 15: Zircon Beta Release 64 (Download: Zircon Beta #64 - Win64)

Resolved Window resizing on-the-fly bug introduced in #58. Also added an optional and experimental "-shell" capability that can be enabled by adding "-shell" to the Zircon command line. In the next version, the "shell" capability will no longer be in the standard Zircon but will be available in a special separate download.

August 14: Wind (Download: Zircon Beta #63 - Win64)

Resize Bug: Did a number of tests and I discovered a windows resize bug introduced in Zircon Beta #58. That version had some "SDL fixes" acquired from DarkPlaces Beta that fixed a "hard to replicate issue". Hard to replicate bug fixes are always very nice, but either my implementation or that fix itself busts resizing a window with the mouse and will result in a black area on the screen. (Update: Actually it was DarkPlaces Beta FBO changes).

Have some very nice things I would like to get out, but need to get this done first because I like window resizing on the fly -- I don't use it often, but it is nice to have available. Likely, I should update Linux.

August 9: Q3 .Shader/SurfaceParm

Quake 3 map .shader options (q3map2 is the Q3 map compiler): Best Links: surfaceParm Q3map2.robotrenegade.com and q3map2_ global directives Q3map2.robotrenegade.com

I do not consider myself an "expert" on q3map2, but will include thoughts ...

• surfaceParm trans - will not cast shadows, will not be considered in visibility
• surfaceParm nolightmap - a Quake 1 mapper should read this as "fullbright".
• surfaceParm monsterclip - if you want a Shambler trapped in an area, Shambler put in a room covered with this. Monsters cannot walk through nor see through this.
• surfaceParm nonsolid - "Does not collide". Opposite is q3map_clipModel, which should rarely be used.
• surfaceParm alphashadow - Any shadows cast by this texture should consider the alphamask.

surfaceParm trans is probably a bit overused .. here is why ... if I have a fence this should be a detail brush (in J.A.C.K. Ctrl-D will toggle rendering of detail vs. structural brushes, and Ctrl-Shift-D will turn a brush into a detail brush.). Detail brushes are not consider by visibility so then the issue is should it cast a shadow and unless it is water usually you do.

So in my head, surfaceParm trans is for liquids and glass textures.

Glass: In Quake 1, all translucent glass you see in any map in Q1BSP is going to be a func_wall (or such) with .alpha 0.5 (or some value less than 1). You can make the whole door translucent or the whole door solid.

In Q3 BSP, you can make any texture glass. So in Q1BSP, it is impossible to make a func_train or a func_door with a glass window because the only method available is the entity .alpha method will make either the whole door translucent or not.

For completion: There are other methods to control shadows on a brush or group of brushes. Turn a group of brushes into a func_group and give it "_castshadows" "0" and/or "_receiveshadows" "0". A func_group remains part of the world and is not an entity like func_door. "_cs" "0" and "_rs" "0" are abbreviated forms of these fields also recognized by all q3map2 compilers.

What DarkPlaces Can Also Do:

With Q3 BSP, you can make a func_train that is solid with glass windows. In DarkPlaces, you can also make them breakable with the right QuakeC.

Pictured: Ugly test map from weeks ago with missing grass texture that shows a func_breakable attached to a func_wall that is rotating. The box attached does not have a glass texture applied, but that would be easy. The func_breakable is attached via setattachment. Rotating objects like the func_wall needs to have an origin brush and so do brushes attached to a brush with an origin brush -- so the func_breakable has an origin brush too.

Pictured: Illustration of the origin brushes that are part of the func_wall (rotating) and the func_breakable (attached). Ugly missing texture is because I had no idea I would be using that test map in screenshot here.

OBJ to Q3MAP:

For completion ... according to KleskBY, this tool does an incredible job converting OBJ in Blender to Q3Map:

Github.com

August 8: Explosion Part2 + Detail

The Quake engine is not well-suited for "explosions" knocking things around. Achieved what I'll call a "9/10" for the physics parts for working with a Quake engine.

Obstacles:

1. Quake runs entity physics in entity order.
2. Things in the air can get stuck on something else in the air and stay there forever.
3. Difficulty to make it so things early in the explosion don't hit each other and stop their movement.

I gave elements knocked around a check to verify they are really actually on-ground with a bounding box collide check. I also preserve the collision details, strip the details for physics and give them back their properties giving them a moment to disperse.

I had looked into the details of the QuakeC Gyro Physics, I came to the conclusion it was "too heavy" and did too much for what I was seeking to achieve here. I look for very minimal, clear, short and effective implementations -- in this case it was making a more interesting T_Damage function.

August 8: Explosion Thoughts (Download: Zircon Beta #63 - Win64)

Pulling off a decent explosion in Quake is a little trickier than I thought. But I'm on the right track after digging around. The first few experiments, nothing moved at all.

The first rule of explosions is that there needs to be lots of debris flying in the air in various directions.

Also required: smoke, things that burning for a bit and then not ...

Pictured: Quake 1.5 Barrel-Test.bsp

August 6: Mirror Alpha (Download: Zircon Beta #63 - Win64)

How to make the window02_1 texture a mirror in the start map. (In conjunction with r_water 1, which enables the mirror effect).

1. Go to c:\quake\id1 folder

2. Make a folder called scripts (it will be c:\quake\id1\scripts)

3. In Windows, right click in the folder and create a new text file. Rename it to "mirror.shader"

4. Edit c:\quake\id1\scripts\mirror.shader so it has the following contents:

5. Start the start map ... type "r_water 1" in the console to enable the mirror effect.

window02_1
{
	{
		map white // "white" is a special texture name in DarkPlaces
	}
	{ // Lightmap
		map $lightmap
	}
	// 70% reflection 100% red 100% green 20% blue %80 alpha
	dp_reflect .7 1 1 0.2 .8 // [reflect factor] [red] [green] [blue] [alpha]
}

August 3: Failed Experiments

I did some successful experiments today, but the failed ones stuck with me more.

3D HUD Cannot Be Written Without a Texture Matrix

I wanted to make a 3D HUD. DarkPlaces has a cs_project and cs_unproject function ... totally ready to go .. I go to draw a 3D quad via R_PolygonBegin. When I was done, I recall some vague recollections about gl_texturematrix and I simply won't be able to draw a 3D using those mechanisms because the texture matrix cannot be set properly. Also minor flashback to remembering that Q1BSP has a texture matrix that the software renderer version used, otherwise it wouldn't be able to "WinQuake".

I do have a Plan B that dodges use of a texture matrix. But requires some setup and some math planning.

Quake 1.5 HD Is Already Very, Very File Size Optimized

A few days ago, I thought I would take a few minutes to see if I could reduce the file size of Quake 1.5 HD. Zircon has some rather automated tools for doing this so it often is really "a few minutes". To my surprise, there were no real gains to be found at all! The author of Quake 1.5 HD, freddiehimself, did an incredible optimization job on Quake 1.5 HD.

Other

I use a different machine than I did a year ago, but did not transfer over everything. I need some old geometry libraries I wrote (for some 3D calculations) and there is an experimental old FitzQuake Mark V with a really exotic oddball feature I want Zircon to have. I need to assess the difficulty of implementing this highly unusual feature. It isn't a graphical feature, it is a console command that does something "not easy at all" (the difficulty of the feature was the appeal of writing it) and can be incredibly useful if making a mod under some circumstances.

August 2: Compass

I added a CSQC compass (customizable color, set compass_name to select whatever image wanted) that will be in a slight update version of previous tool.

KleskBY made some very nice pure text based CSQC compass (see QUALKER), I wanted to make one that uses an image. (I couldn't find a suitable permissive license image, so made one in image editor).

I changed the arrow color in the console, but the GIF compressor turned into white so I cut the portion after that.

Zircon Beta #64 is very likely to have a "high resolution, automatically scaled" canvas available in CSQC that should look "nice" on high resolution displays and I want to shift all of the "overhead" out of CSQC and into the engine so it can "just automatically happen".

August 2: CSQC Overlay Tool (Download: Zircon Beta #63 - Win64)

CSQC Overlay Tool With QuakeC Source (Download)

I saw some things in the SMC 5.60 source code, created a real-time testing tool for screen overlays.

"overlay_name textures/yourtexture.tga" will test a texture.

Edit the scripts/overlay.shader text (or use a raw image and set overlay_alpha 0.5 and overlay_red 0.5) .. if you do be sure to use "r_restart" to reload the shaders to take effect.

August 2: SMC 5.60 Repack (Download: Zircon Beta #63 - Win64)

Created a repack of SMC 5.60 (SMC 5.60 Repack Download) that is a single file you unzip to c:\quake\smc

(SMC always came as 3 different non-zip archives that you would have to download, and SMC 5.60 requires that you patch them with a 4th download. I repacked to a single file to unzip to keep everything simple.)

August 2: SMC 5.60 (Download: Zircon Beta #63 - Win64)

Fangorn Beach Prototype: Download

Looking for videos showing gyro physics use, search results brought me to a video made by Seven with SMC. Loading up SMC 5.60, which I have not loaded in a while ... and I noticed these while looking for something else.

August 1: "_extradist"

Fangorn Beach Prototype: Download

For a "light", Q3 map key "_extradist 150" can "fix overburnt pixels" near light sources. (link)

Discovered this on OpenArena wiki incidentally while searching for something else on Google. Have not had time to "process" this, but there have been numerous times that I had a light that I would prefer to not over light the wall it is near and yet if I move it away from the wall, it does not look like the light comes from the light source.

Pictured: Left: Normal, right "_extradist" "150"

July 30: Fangorn Beach Prototype

Fangorn Beach Prototype: Download

Heavy trees/vegetation terrain map (map source available in the download). No mod required, place .pk3 in c:\quake\id1 folder and "map fangorn_beach_prototype". (Compatible with Zircon and DarkPlaces).

The triangle count of the map is rather mild due to the method of construction and aggressive optimization techniques (Under 75,000 triangles -- the Quake start map has 15,818 triangles).

Best results: r_glsl_deluxemapping 1; r_bloom 1

There is a visual glitch by the lake caused by some invalid brushes that was not noticed early enough to quickly repair. Eventually, the plan is evolve this map further, populate it and give it some very nice gameplay/flow.

This map is a terrain map and was difficult to properly construct -- there are several advanced Q3 features used by the map including lightmap merging and some major challenges with the trees and collision volumes that I had to add a new feature to the q3map2 (Quake3 map compiler) to accomodate here.

Various Vegetation / Tinyweeds Models V1 (Download)

This pack has several vegetation models I made -- most of them in available in 2 versions -- an "autosprite2" version (always upright sprite) and a "cross-model" version.

A mystery to investigate: healthboxes and ammo boxes are getting lightmap darkened. In Q1, these are Q1 .bsp and fullbright and they are here too. Attempting to understand the issue, I substituted some high res models that the health boxes are not Q1 BSP -- and they still are getting lightmap darkened. If this required a mod, I would set EF_FULLBRIGHT to all the box models, but this requires no mod so --- it is what it is (for now).