Quake Windows, Mac, Linux, DOS, XSX, XONE, PS5, PS4, Switch, N64 game

January 1: map_move (Download: Zircon Beta #86)

Investigating the map_move fail in the Dungeon Maker for origin brushes (func_door_rotating):

I coded the engine to move the "origin" instead of move the brushes if it detects an origin brush as one of the brushes inside an entity. This would be correct if the map were already compiled, but because the Dungeon API works with .map files (pre-compiled) it is wrong.

December 31: Imperfect Alpha 1 (Download: Zircon Beta #86)

A version 1 of the Dungeon Maker Lite (Alpha 1) is in the downloads section -- it appears that the "map_move" function in the Dungeon API incorrectly handles origin brushes (func_door_rotating) which would require an engine update.

The Dungeon Maker Lite is largely a proof of concept work anyway with a simple code demonstration of the Dungeon Maker API.

December 31: Dungeon Maker Lite Today? (Download: Zircon Beta #86)

View Preview

December 31: Q.U.A.L.K.E.R. 0.4 (Download: Q.U.A.L.K.E.R. 0.4)

December 30: For Future (Download: Zircon Beta #86)

Some times when I look at a picture that I see that I like, I try to determine what exactly is the characteristic that makes the image interesting.

In a map, you might want something that is supposed to look important. A quick experiment that happened to work out.

December 29: Chest (Download: Zircon Beta #86)

This chest is a func_door_rotating (upper half) on top of a func_wall (lower half). I had to do some carving. My original plan was to use a free model from somewhere, but I determined it would be better to open up the J.A.C.K. map editor and make one with brushes. The theory was that a chest is a cube with a half-circle top with some metal trim and carve out the interior.

I have real-time lighting on here, which does not use lightmaps. If I had real-time lighting off, the inside of the chest would probably be pitch black. Unless I put a light in the chest. I might be able to export it to .obj model using "modeldecompile" (in theory). Other methods exist like having q3map2 compile to .ase and then opening it in Noesis and exporting to .obj or .md3.

December 29: Continued (Download: Zircon Beta #86)

I may take what I have and put it together into the "Simple Version" demo of the Dungeon API. The first version is intended to function as a demonstration of the Dungeon Maker API.

December 28: Trying To Wrap Up (Download: Zircon Beta #86)

I'm a bit stuck in how to close out. The consolation prize is things look F***K**G great.

This challenge was to make a respectable door. I'm pretty GD satisfied with the results.

I made a cylinder and attached it to the top of a rectangle to make the door. Used carve in a block. Added some rects to the door including 3 rects to make the door handle -- these are all textures from AmbientCG and TextureCan (license: CC0) and the light model is from OpenGameArt.

December 28: Zircon Beta Release #86 (Download: Zircon Beta #86)

Hemebond improved upon the 64-bit lightmap fix and I consider this a major improvement so immediate release. See readme.

Pictured: Winter Hellscape Q1SP which is a recently released Christmas map that Hemebond used as a test case for DarkPlaces Beta.

No the map isn't really that dark ... I messed with some brightness settings to get the Christmas lights to stand out more.

December 28: CSQC Player Captions (Download: Zircon Beta #85)

CSQC Player Captions with source code. A speed mod, captions are not centered .. the purpose of this code is to show how it can be done. The code should also work in DarkPlaces.

I didn't expect to be writing this, haha.

It works by cycling through maxclients (as in "maxplayers 16") and using getentity to get the player origin and then calculating the 2D screen position --- vector thisguy_screen = cs_project(thisguy_origin);

	for (float player_num = 0; player_num < maxclients; player_num   ) {
		float sv_player_num = player_num   1; // player_num 0 is edictnum 1 on server because 0 is world.

		if (sv_player_num == player_localentnum) {
			// This player is us.
			if (cvar("chase_active") == 0)
				continue; // Don't try if chase_active is 0
		}

		float is_potentially_visible = getentity(sv_player_num, GE_ACTIVE_0);

		if (is_potentially_visible == false)
			continue; // Can't see

		vector thisguy_origin = getentityvec (sv_player_num, GE_ORIGIN_1);

		if (!thisguy_origin)
			continue; // All zeros origin

		thisguy_origin.z  = 32   8; // Use the head as target.

		vector thisguy_screen = cs_project(thisguy_origin);

		if (thisguy_screen.z <= 0)
			continue; // He's behind us

		thisguy_screen.y  = 20;
		string s_name = getplayerkeyvalue (player_num, "name");
		drawcolorcodedstring2 (thisguy_screen, /*"Player"*/ s_name, ov.fontsize, white_111, alpha_1_0, DRAWFLAG_NORMAL_0);

	} // for

To center the caption ... Should have subtracted thisguy.screen.x -= (stringwidth(s_name, /*colors?*/ true, ov.fontsize) / 2) or something to that effect. TODO: Investigate why slots show as active when no player is connected to occupy that slot, this is the reason for checking zero origin which I would not expect to be necessary.

December 26: Linux Wiring (Download: Zircon Beta #85)

I want features to work on Linux. In this case -- I had to read up on C documents for "execlp", "system", "fork" and "SDL2_CreateThread" and look through the DarkPlaces macros on thread management.

"Working First, Perfect Later ..." I was able to get all the basics working on Linux.

Pictured: Linux quick barebones map compile test. I have Ubuntu running on my Windows 10 machine via WSL and video capture does work. An aside: WSL is nice, but it cannot actually be used for compiling Linux binaries for a real Ubuntu machine because the GCC on WSL is a different version than the real Ubuntu.

The Dungeon Maker API has some nice mechanics that I had to read FTEQW code and DarkPlaces code to get a feel for if what I wanted to do was possible (I saw use of supplied callbacks in FTEQW and examined the wiring in DarkPlaces) and then look through fteqcc compiler docs. Very happy with all the nice work in fteqcc and inside FTEQW/DarkPlaces.

December 25: Dungeon Maker "Lite" Close .. (Download: Zircon Beta #85)

December 24: Zircon Beta Release #85 (Download: Zircon Beta #85)

Final version before full Dungeon Maker API. Linux binaries return Visual Studio 2022 built binary.

• Microsoft Visual Studio 2022 compile works again. I noticed it broke either when Microsoft Visual Studio 2022 updated or when a previous version implemented "member_offsetof" (a macro that somehow causes a compile error in Visual Studio 2022). See readme. Likewise there is a binary built by Microsoft Visual Studio 2022 in the .zip.
  
  (I don't use Visual Studio 2022 but a much older version and the Zircon Beta Windows final binaries are built by MinGW/GCC on Windows using CodeBlocks -- however, I view it as important for it to compile in Visual Studio 2022 because it is a recent and free for open source development version.).

See readme for other changes.

December 24: Pak_this_map Extended (Download: Zircon Beta #84)

"pak_this_map myfolder" will take the currently loaded Q3 map and dig through the map and locate all textures, look through sounds in entities segment and then put all textures sounds in "myfolder" with a scripts/something.shader that has the .shader textures for the map in a single file. It will also dig through the .shader texture and locate non-obvious textures required and do those too.

But it didn't actually put it the files in a .pak or .pk3, but it will in the next version.

(A human can do this ... slowly with a high error rate .. extra dependencies in shader text is hard to unravel and making a .shader file with only the necessary shaders texture entries by hand would be labor intensive with a high error rate ===> and then there is the time testing to discover the errors.)

December 22: GCC (Download: Zircon Beta #84)

The GCC compiler sure prints a lot of warnings and in my case, it does not much care for how I use labels.

I sometimes use labels to literally mark what that piece of code is doing.

A prime example of using labels to mark code is in cl_screen.c:CL_UpdateScreen_SCR_DrawScreen

Zircon does something a bit complicated that DarkPlaces does not do. Zircon can render the menu and render CSQC 2D elements with different 2D rendering canvases.

This was achieved by turning what was previously one drawing phase into 2 separate drawing phases, yet keeping all events in the same order. There are about a dozen different labels marking what event is occurring at various points in the screen draw function and not a single goto to any of them because they are informational.

GCC prints warns "unused label" for those.

GCC also does not like how I initialize structures. I do struct super_complex_struct myvar = {0}; I think GCC wants me to do something like {0,0,0,0,0,0,0,0}; for 90 fields and warns that I did not separately initialize each struct member. And I won't be that ever.

But with GCC you can disable warnings individually like -Wno-missing-braces -Wno-misleading-indentation
-Wno-switch -Wno-parentheses -Wno-unused-label.

I code in Microsoft Visual Studio so during debugging on Windows I am not using GCC at all, but when I do a final compile I use GCC for many different reasons including it can conveniently totally eliminate the need for including SDL2.DLL with a Windows build.

I want to see if I silence some of the most noisy warnings, how much remains. GCC warnings can find things that, for instance, the Microsoft compiler in Visual Studio does not seem to be able to do, like missing printf style arguments and such.

Missing printf style arguments is a bigger deal in Zircon than DarkPlaces. Zircon uses variadic expansion everywhere it makes sense. DarkPlaces probably historically veered away from variadic expansion because the code is annoying to write for variadic functions. I converted the annoying and awkward process into 2 short macros and implemented variadic expansion in a very large number of functi result ===> fewer lines of code and the lines of code are easier to read.

December 21: ... (Download: Zircon Beta #84)

I expect to have 2 demos by Christmas, both open source. A simple case demonstration, deliberately simple and a more complicated case with code that is not so easy to follow but more immersive.

December 20: 92% Done /- (Download: Zircon Beta #84)

The final 8% and hardening remains. Then working up and refining the "simple case" demonstration.

December 19: 33% Done /- (Download: Zircon Beta #84)

Writing a complicated DarkPlaces extension is a fair amount of detail work. Have to consider startup, shutdown, hosterrors, savegames, memory allocations in addition to writing and then testing the actual code.

To do a QuakeC extension correctly, there should be code for every possible error situation. This includes checking strings to make sure they aren't zero length because QuakeC compilers like fteqcc will allow missing arguments to functions.

float map_load (string filename) = #150; // Returns 1 or greater on success allowing 0 value uninitialized variables to never contain a valid handle.
float map_close (__inout float hmap) = #157; // Return value is 1 on success, 0 on failure. Sets hmap to 0.
float map_entity_count (float hmap) = #158;
float map_find_entity (float hmap, string key, string value, optional float afterindex) = #159;
float map_entity_key_count (float hmap, float entnum) = #160;
string map_entity_key_for_index (float hmap, float entnum, float keyindex) = #161; // Return NULL on failure
string map_entity_keyvalue_for_index (float hmap, float entnum, float keyindex) = #166; // Return NULL on failure
float map_clipboard_set (float hmap) = #154;

This is a little less than half of the .map manipulation functions in the Dungeon Maker API. The rest over the next few days.

Praise Spike/Spoike for __inout in fteqcc! 😀 This allows function parameters to be writable, making it possible for a QuakeC function to modify a parameter in some special cases and have it marked in the function prototype.

Keeps things simpler in certain special cases: I have "map_close (maphandle)" zero out the map handle as part of the close process as the handle is no longer valid.

December 18: Dungeon Maker API (Download: Zircon Beta #84)

I have been drafting out and working through a CSQC server mod to build a dungeon via a CSQC user interface for "simple example #1". When completed, an on-screen user interface will allow quickly assembling a grid based dungeon and then running and playing the fully compiled map.

The Dungeon Maker API is not grid based, but grids are easy to work with and for a first demonstration in the theme of "Keep It Simple" is the way to go.

The actual Dungeon API performs command line like map_paste_at (mainmap, thiswall, '200 142 11'). At map compile time --> map_save_as (mainmap, "maps/thismap.map"); map_compile_with_callback ("maps/thismap.map", Compile_Complete). Will need to work through the callback mechanism, there can be up to 4 stages for a map compile.

December 16: Zircon Beta Release #84 (Download: Zircon Beta #84)

"tool_marker" is now a command instead of a cvar and has new capabilities (type "tool_marker" in the console to see uses). This command will display a topmost marker of an origin point inside a map and now typing: tool_marker 85 will automatically set a display of where entity #85 is located.

Also: Makes 1 frame of showing console between startdemos disappear, fixes scr_levelshot_auto crashing if a hosterror occurs (failed map load). And gamedir changing resets game fonts fully.

No Linux again, hope to do that again once the Dungeon Maker API get settled in.

December 16: EffectInfo Viewer (CSQC) (Download: Zircon Beta #83)

Download: CSQC EffectInfo.txt Viewer (CSQC source code included).

Pictured: The SMC 5.60 mod by Seven (thread) and many others (including jakub1). I expected maybe 150 effects -- was in shock when I saw it was over 300. Some of the effects like the water fountain (not pictured) ... I can't even imagine the amount of effort required to make such a thing. Seven's work has a deep and lasting impact and is why numerous mods even exist (and there were a great many others too who helped make SMC .. see readmes).

Zircon #84 should be coming soon.

December 16: EffectInfo Viewer (CSQC) (Download: Zircon Beta #83)

Soon: Made a CSQC only mod that can be placed in a folder and allows browsing the effects listed. I have next_particle and prev_particle bound to keys.

This allows quick and convenient viewing of each of the effectinfo particle effects. For instance, place it in the SMC 5.60 folder and browse all of the magnificent effects in the SMC mod.

I wrote this in a way that should work with any DarkPlaces, in addition to Zircon.

December 15: CSQC Entity Networking (Download: Zircon Beta #83)

I have written CSQC entity networking several times. I would give it a 9 of 10 in functionality/reliability/coop support, but the code was 4/10 in readability.

CSQC entity networking is the process of making certain entities send to the client with update bits. A prime example is torches so that the client handles all the particles in CSQC instead of the server sending tons of particle messages to the client.

I revisited CSQC entity networking and managed to collapse it into a simpler and much more streamlined form -- few lines of code for what it does and very legible.

In the future sometime (2 months from now?) I hope to do a simple mini-CSQC project/tutorial with it, but I want to get the Dungeon Maker out before Christmas in a simple demo version with understandable code (but less fancy) and a more complex version with more functionality (but the code gets complex and not good for tutorials).

December 14: Solution to Background Music (Download: Zircon Beta #83)

For #84: Implemented a very "DarkPlaces" method to use custom names for background music. Here is what and why ...

1. Say that I find some very freely licensed music at, say, Pixabay.
2. Picking something at random, this will be the example.
3. The download file name is mystery-dark-ambient-emotions-music-259996.mp3
4. I open Audacity and convert it to .ogg for DarkPlaces.

5. Now I must destroy the name and give it a name with no meaningful information such as ...

sound/cdtracks/track003.ogg <--- 🙁 (or music/track003.ogg)

Now, looking at this file I have no idea what it is and where it is from, if I want to find out I must play the music. This sucks.

Zircon #84 method:

5. Now I place the .ogg in the music folder and prefix it with the "track number" as such ...

music/003_mystery-dark-ambient-emotions-music-259996.ogg <--- 👍

This will help make attributing source material easier in mods. And if you open the music folder, you will also know what the hell each of the files are.

Most of the solutions in DarkPlaces for things like this have historically tried to use the most flexible or easiest methods. This method doesn't use cvars or text files, just a simple prefixing of a file and then DarkPlaces file pattern matching see if there is a match (and if not, use the traditional naming scheme).

December 13: CSQC Demos Continued (Download: Zircon Beta #83)

The way that DarkPlaces embeds CSQC in demos means that a background menu demo can have its "own program". That means it can run code customized specifically to that demo only.

Pictured: The menu background is demo1.demo recorded in a map and we do not move. The CSQC used in this demo specifies "do not draw status bar", "do not draw crosshair", "do not draw view weapon". The MenuQC draws the selection elements.

An example: there could be camera code written specifically for a menu background demo.

December 13: CSQC Demos (Download: Zircon Beta #83)

As I have been working on the automated Dungeon Maker, I have been integrating some of KleskBY's MenuQC into the mod and he has a great menu he uses in Object N. I am exploring a menu idea that does something unusual for Quake and even DarkPlaces mods but if I manage to pull it off, I need CSQC and MenuQC to talk to each other and I need an ambient demo1.dem playing in the background.

When I did the first test, it didn't work. It was not using my current CSQC.

DarkPlaces stores the CSQC in the demo at time of recording and uses that. I did know this, but I wasn't thinking about it at the time and it caught me off guard.

The reason that DarkPlaces stores the CSQC in the demos is that if you do some really interactive CSQC server CSQC coding you can send network messages (and text commands) from the server to the client. Without the CSQC at the time of demo recording, there is no way to interpret those messages.

December 13: Loading Healthbox Maps (Download: Zircon Beta #83)

Added a method to force loading of maps like "b_batt0.bsp" (small lightning gun cell box). This method should also allow loading maps that are mod-locked with no info_player_start because the mod/game uses something else for spawnpoints.

On another note, the fix to scr_levelshot_auto was incomplete. Although it fixes one instance, a HostError like missing "info_player_start" still has issue. What I had believed would solve the issue was checking r_refdef.scene.worldmodel (is there a world in the scene) but the way map load works is that persists from the previous map until it is replaced (this why single player death restarts are quick, so it does not need to reload everything) and it seemed to check ok in a test simply because no map had previously been loaded.

December 12: Font Reset (Download: Zircon Beta #83)

I am using some of KleskBY's menu QuakeC like used in Q.U.A.L.K.E.R. and after some testing, DarkPlaces does not reset fonts to default after gamedir change (I coded a reset when gamedir change occurs for #84).

MenuQC is the 3rd form of QuakeC supported in DarkPlaces. It is used less commonly -- Quake 1.5 does not use MenuQC -- because use of menu QC will require things like handling video mode changes since it is a replacement for the menu.

December 12: Zircon Beta Release #83 (Download: Zircon Beta #83)

A recent thought: in standard Quake, there is always "some light on the gun". In DarkPlaces, there isn't. In Zircon it is possible to select Options->Overbright->Min Light.

I did some testing around on Q3 with colored light and discovered that it is impossible to detect the color of colored light in a completely dark area because the color data is 0 0 0 black.

However, what if the lighting for the map is "red". What should forced minimum lighting color be in a totally black spot? This is actually a little puzzle because in Quake 1, all light is white but for Quake 3 map format this is not the case.

I want to see if I can solve this issue especially for view weapons. I want them to receive lighting from the map, but never go full black but also have the correct color for the lighting in the area (which can be any color).

December 11: Dungeon API Test #0 (Download: Zircon Beta #82)

This was made from a grid (20 x 13), but there is nothing about the Dungeon Maker API that requires a grid, the interface itself can paste a component anywhere.

Pictured: Look closely and you will see a texture tiling fail in the series of wall.However, grids are easy to work with and I want the initial examples to be easy to understand. If you pay close attention, the quick wall block1.map that place back-to-back-to-back does not tile right because this is a test.

I need to decide the "level of picky" I am going to do and stick with a limitation. Here is what I mean:

Ideally, I want compatibility with DarkPlaces real-time lights. However, those must be radius lights like in Quake. And additionally, cannot use "_extradist" -- the q3map2 mechanic to reduce overburnt pixels. This is critical for the textures of type used -- super bright light will make those textures look supernova white.

So either I need to say no to with real-time lights for the initial examples or get really picky about light placement.

From a quick grid interface I made. I click the green button, it makes the map.

Zircon has a "purgeall" command that has existed for about half a year that will entirely discard all loaded maps/models, so I can recompile the map and type purgeall before loading it.

Pictured: An ugly grid I made that I can click the boxes to cycle through values to get test #0 going ...

"Purgeall" is an example of one of the many dozen "low-yield" modifications in Zircon. Individually, they don't seem particularly important, but adding them all together removes many hassles. This is why I sometimes stop what I am doing if I encounter the same hindrance too many times and decide to code the hindrance away.

December 9: Dungeon Maker API Work (Download: Zircon Beta #82)

Coded the process to make the first dynamically generated test map. A large list of technical details and other planning had to be done and also thinking out a system for interfacing with it.

This has been "rough" but not in a hard way, but in a way that requires working through a very large amount of setup and preparation. Once this "overhead" is completed, I think the real fun will begin.

😏

Humor of the Day: Need to make a QuakeC function that does:

"Insert Door7.Map Into YourMap.Map at 256, 3240".

December 8: Tutorial "AmbientCG" Map (Download: Zircon Beta #82)

Soon to release a super-simple *vanilla Quake* (no gamedir just .bsp textures) tutorial .map ==> No CSQC, no particles, no .shader (except the dirty floor q3map2 _decal).

A super simple Q3 map that is pure textures.

Pictured: Sticking to the Keep It Simple plan, nerfed torches instead of particle torches.

And I'll explain how to use textures from AmbientCG and TextureCan (just simple rename bricks_0019_color.jpg -> bricks_0019.jpg, bricks_0019_NormalOpenGL.jpg -> bricks_0019_norm.jpg, bricks_0019_ambient.jpg -> bricks_0019_gloss.jpg).

December 7: Autocomplete Upgrade for #83 (Download: Zircon Beta #82)

I downloaded a number of textures from TextureCan to test and initially I was recompiling the map. That is too slow to quickly see how a texture looks in-game.

Update: Went back in and made it so textures ending with _gloss, _norm, _alpha, _reflect do not appear in the autocomplete for r_replacemaptexture.

r_replacemaptexture has already had a few autocompletion upgrades (jakub1 and someone else had asked to make it easier a while back), but I have improved on the autocompletion some more to make it even smarter (for instance, it will autocomplete paths now).

The autocompletion in Zircon has evolved substantially since the original release in early 2023. Initially it just did the minimum, but now it can figure out individual arguments and complete paths because of list management system upgrades. DarkPlaces has this great "stringlist_t" used throughout the engine and after working with it, I had decided I loved it -- truth be told, it went from about 4-10 functions in DarkPlaces to somewhere closer to 100 -- machines can remove/simplify tons of tedious tasks if you keep pressing it harder to do so.

December 6: Inverse Distance Squared (Download: Zircon Beta #82)

Some real-time light testing -- intend to strategically use them sparingly -- and ran into the "lighting thought of the day".

1. Quake uses linear light falloff.
2. q3map2 uses inverse distance squared. (Typically looks nicer, set a flag to Quake radius light is option).

Pictured: Quake "lightstyle 2" in a real-time light. Whatever codec or compressor that WebP is using really wants to pixelize the bottom part of the image above.

DarkPlaces real-time lighting? It uses linear falloff like Quake. The implication of this is that real-time lights are not q3map2 inverse distance square style. Quake linear lighting is far brighter.

In a map, this also means I can't turn light X into a real-time light and expect it to look mostly the same in q3map2. And DarkPlaces real-time lighting does not support "_extradist".

This just means planning things out that radius lighting with no _extradist is the most straightforward lighting method to use in most cases, should I want to conveniently switch lights between classic map compiler lighting and real-time lighting.

For certain things, real-time lighting really adds to the environment:

Although what I have in mind is door opening, staircases, torches and such.

Note: I did look around and consider trying to change real-time lighting to be able to do inverse distance squared. There are massive quantities of light calculations in DarkPlaces. And also, you still want rockets and such to use radius light. Making it support 2 or more falloff styles would require some mild network protocol changes. This just means changing it right now is more involved than what I would want to do right now.

December 6: Lighting (Download: Zircon Beta #82)

Before getting too deep into the automated dungeon maker, needed to scout out textures and work out the lighting.

The lighting in particular was the part I needed to sort out because in q3map2 it seems like I run into the "overburnt pixels" issues frequently and needed to get a feel of what "safe" lighting looks like.

December 5: _extradist 120 (Download: Zircon Beta #82)

Q3MAP2 has a "light" key to fix overburnt pixels called "_extradist".

Pictured: The bottom one uses "_extradist 120". Texture is Bricks0019 where Bricks0019.jpg is the _color image Bricks0019_gloss.jpg is the renamed ambient occlusion and Bricks0019_norm.jpg is the renamed "Normal OpenGL" in the .zip.

December 5: Working Directory (Download: Zircon Beta #82)

Automated dungeon maker construction ... when using q3map2 to compile a map, it seems the current working directory must be "c:\quake\mygamedir" or it can't find textures. If it can't find textures, the texture coordinates are wrong in the .bsp. Quickly resolved. Building infrastructure, one runs into every small detail and speed bump.

December 4: quake/id1/levelshots/e1m1.jpg (Download: Zircon Beta #82)

Autosaves now print the first time it saves in a map. And while handling autosaves, "scr_levelshot_auto 1" (default) will store a levelshot of a map if one does not exist.

The maps menu is where map levelshots are displayed (Menu -> Help/Ordering is maps menu).

It is possible to make Zircon screenshot every map by typing "levelshot_maps_all" in console. (**note below)

Pictured: Intermap Travel Demo. This area of what largely resembles DM5 uses a rotating real-time light with a cubemap. For DarkPlaces, most of the time when you encounter a real-time light it is in a file like quake\id1\maps\e1m1.rtlights. For this mod from earlier in the year, real-time lights are not in a .rtlights file -- but rather are similar to "light_torch_small_walltorch" and the QuakeC spawns the light from the .map "realtime_light" entity (colors, rotation, cubemap, etc.)

The heavy modifications in Zircon to support the Intermap Travel Demo -- where items and maps are re-entrant as if one continuous world connected by teleporters -- is probably going to be very relevant for the Automated Dungeon Maker project. At least for phase 2. I expect phase 1 to be deliberately simplified so that it is easy to understand how to make it work.

However, phase 2 after a simple demonstration prototype -- I want something more complex. I don't know if the maps will be re-entrant, or one very large map and there is the possibility that combat might occur on a separate map (and then return you to the "real" map after combat).

The nice part: the infrastructure in developing the Intermap Travel capabilities makes picking any combination of the above scenarios very easy and non-scary. I don't have to code anything to get Zircon to keep the state of the maps/items/monsters, it can do it automatically and it will save game correctly (Intermap Travel save games contain the state of many different maps).

Extra note (**): It is possible to make Zircon screenshot every map by typing "levelshot_maps_all" in console, however this can take some time and an oddball map that is only compatible with a very specific engine can cause a crash. (Or invalid maps that require specific QuakeC while you worked on a mod and then you changed the QuakeC for the mod and the old map no longer works ...)

December 2: Dungeony ... (Download: Zircon Beta #81)

I have been working on dungeon making infrastructure and much of it involves invoking the q3map2 map compiler. Meanwhile, KleskBY had pointed out this DarkPlaces based randomly generated dungeon mod from the past (R'lyeh City).

Pictured: R'lyeh City randomly generated dungeon. This is a mod from the 2012 era. Notice the mini-map changes after descending stairs. Looks like the mod author later ended up making some mods for FTE (Github.com, YouTube).

q3map2: Today maybe for the 15th time, I briefly thought about absorbing q3map2.exe (isRyven) into Zircon entirely which would solve some future issues -- do I want to compile q3map2 for Linux, Mac, etc. ---> No, I sure don't. I have hard-wired myself to automatically reject the idea of absorbing q3map2 into Zircon until the new year.

Categorizing q3map2 generated files:

When q3map2 compiles a map it creates yourmap.srf (for light stage) and yourmap.prt (for vis stage). These files are no longer needed after map compile. "Baker" q3map2 creates a yourmap.rent file that is an informational only log files of entities added by shaders containing "q3map_surfaceEntity" (similar to q3map_surfaceModel, except instead of placing a model it adds an entity to the entities segment, the mymap.rent log file is quick way to see what entities were added).

November 30: "Sprite Sheets?" Please no ... (Download: Zircon Beta #81)

Zircon Beta Release #81 has commands "particle_split" and "particle_join". See readme for other changes.

I don't like working with "sprites sheets" because I have to do math and pay attention to pixel boundaries.

"particle_join" will take images named particles/images/000.png to particles/images/255.png and combine them into a single image.

Pictured: The rocket trails and such are from a 256 texture "sprite sheet" (particles/particlefont.png) created from separate images in particles/images folder. These images were created from "particle_split" which took the size 8x8 sprite sheet from SMC Mod. "particle_join" happens to write out particles/particlefont.txt with all the texture coordinates automatically.

Short version: Much easier to work with particle effects and create a mega ton more of them with less work and no need to muck around with "sprite sheets".

November 29: Particle Effects Limit (Download: Zircon Beta #80)

In some mods, I use what I will call the "SMC particlefont" which is either similar to or exactly the same as what Quake 1.5 uses. This particle font is a modified and enhanced Nexuiz particle font.

The particles/particlefont.png is basically a sprite sheet that is 8 columns and 8 rows with images for a total of 64 particle texture numbers. From reading the engine code, many effects use hardcoded particle numbers in the engine, for example, smoke is particles 0 to 7 (the first row) and particle #62 is "bubble".

This leaves very few remaining particles for customization as large chunk of the 64 are reserved for something else. 64 is just too small, 256 would be much better.

Now it gets weird ...

According to the engine code, despite 8x8 and 64 being hardcoded ... it looks like to raise the limit to 256, I need to do ... NOTHING.

.. except supply S and T texture coordinates for each texturenum in a separate particles/particlefont.txt file the engine hardcoded limit is 256.

I will have to test this out and verify ... I suspect that this has never been used in this way before (Blood Omnicide by Vortex only has 64 particles and that would be the mostly likely mod/game to use the feature), but looking through code it seems that this should work and surprisingly -- assuming it does work -- it gets backwards compatibility too to at least DarkPlaces 2014.

(Should this test work out, I have to code some new Zircon features. To be honest, I do not want to be editing a "sprite sheet", I want independent particle images. So if this works, I will make a Zircon command to take all the PNG in a folder and turn them into a single PNG.)

November 28: Rear View Mirror (Download: Zircon Beta #80)

CSQC Rear View Mirror with source code.

The code is mostly this ...

void D_RearViewMirror_Draw_3D ()
{
	if (!autocvar_showmirror)
		return;

	vector viewport_size = [ov.vid_width * 0.25, ov.vid_height * 0.25];
	
	// Baker: This is putting in the RIGHT TOP corner, except giving it small margin.
	vector viewport_pos  = [ov.vid_width - viewport_size.x, 0];
	
	viewport_pos  = [ov.vid_width * -1/32, ov.vid_height * 1/16]; // Give it some margin.
	
	vector vfov	= GetCurrentFovEx(viewport_size, ov.viewzoom, ov.fov); // vid_width must update first

	vector viewangles_180 = getpropertyvec (VF_CL_VIEWANGLES);
	viewangles_180.y  = 180; // Do a 180 turn

	// Render the Scene
	clearscene			();			// wipe entity lists. reset view properties to their defaults.

	//setproperty			(VF_VIEWPORT, '0 0 0', '320 240 0');
	setproperty			(VF_VIEWPORT, viewport_pos, viewport_size);
	setproperty			(VF_DRAWWORLD, 1);	
	setproperty			(VF_ANGLES, viewangles_180);	
	setproperty			(VF_FOV, vfov);
	addentities			(MASK_NORMAL_4 | MASK_ENGINE_1); // Baker: Note the lack of MASK_ENGINEVIEWMODELS_2

	// Baker: Sadly we need to do this ...
	// ONLY because we cleared the scene above.  If we don't do this, the main window
	// will not get a status bar.

	float will_draw = autocvar_zr_suppress_engine_statusbar ? draw_statusbar_false : draw_statusbar_true;
	float is_croshair = (ov.is_dead_view == false && intermission == intermission_not_0 && ov.is_in_cutscene == false);

	setproperty			(VF_DRAWENGINESBAR, will_draw);	
	setproperty			(VF_DRAWCROSSHAIR, is_croshair);

	// renderscene: draw the scene to the screen using the various properties.  
	renderscene (); // #304
}

November 26: Item Outliner / Use Key (Download: Zircon Beta #80)

This demonstrates how to implement an interactive use key that CSQC performs enhanced drawing. The source code shows how data is transported from client to server. (Download: Item Outliner / Use Key).

Note that outline rendered is the actual server bounding box (not the bounds of the model).

Most of the server QuakeC changes are in client.qc in PlayerPostThink where a traceline is performed and most of the rest of the server QuakeC is in worldspawn in world.qc (addstat). All changes in the server QuakeC are marked with "INTERACTABLE".

November 26: Quirks (Download: Zircon Beta #80)

I am doing a deep investigation of the traceline function. The traceline function allows to test collision against an entity between 2 points and return what was hit as "trace_ent".

traceline (startposition, endposition, /*nomonsters?*/ false, /*ignore this entity*/ self);

What I am trying to do is collide with health and ammo boxes (SOLID_TRIGGER - value is 1) ... in a DarkPlaces compatible way. It actually isn't possible. There is a cvar sv_gameplayfix_blowupfallenzombies which enables colliding with entities that are SOLID_NOT (zero value) but this does not enable collision against SOLID_TRIGGER which touchables like weapons, backpacks, ammo boxes use.

I ran into this when seeking to do experimentation against model triangle collision (MOVE_HITMODEL) to investigate possible issues with that type of collision, and instead have descended into another rabbit hole.

November 24: item_weapon on DM6 (Download: Zircon Beta #80)

I stopped coding for a few minutes and investigated this. I turned on "tool_inspector 1" in Zircon and was looking to examine ammo boxes to see entity values/flags/etc. and instead of "item_spikes" the nail boxes on DM6 were "item_weapon".

I looked through some other maps like DM1, DM3 and none of the other maps that I checked had item_weapon that I could see. I opened the dm6.bsp in a text editor to verify it was "item_weapon" in the actual map and it is.

Quake is known to have quite a number of small oddities like this, but I hadn't noticed this one before.

November 24: Hitmodel Upgrade Coming (Download: Zircon Beta #80)

The "Monster Box Outliner" was the starting point to tackle a different issue entirely. DarkPlaces has the ability to perform a traceline to collide with the exact triangles of a model (MOVE_HITMODEL), however getting DarkPlaces to actually do this comes with about 4 asterisks that are not solvable within the bounds of QuakeC.

I have the infrastructure in place to eliminate the final 2 asterisks, but will require a some more engine coding and a little bit of planning.

I will have to make another CSQC mini-project to test and demonstrate the new feature, at that time I will walk through all details.

November 20: Windows Unicode Path Fix (Download: Zircon Beta #80)

Windows unicode path support is fixed. See readme for other changes.

Pictured: Q.U.A.L.K.E.R. 0.3 updated .exe is in this Zircon release .zip.

Was a little sluggish in getting this out due to real-life quirky things like power going out for 8 hours (yay!) and some other unusual stuff (coffee machine broke too, caffeine is vital nutrient I need for coding).

November 17: Helicopters For Hemebond (Download: Zircon Beta #79)

The "Helicopter Map" is available for download (Download Helicopter Map). impulse 9 will give you lava gun, chain saw, etc. but main point is MD3 Tags For OBJ Model in Zircon so there is a test case available for testing the extension. I had told hemebond -- one of the DarkPlaces contributors -- a while back I would make a test case, but I haven't completed the mod I was going to use it in yet.

The OBJ model for the Helicopter is in models/vehicles folder, the .map source and the QuakeC is available. The helicopter is a "misc_mdl_entity2" and the source for that function lives in qc/server/extras/misc_mdl_entity.c

Note: I was going to just put the Helicopter in the Quake start map --- however the lighting is rather flat in Q1BSP and the helicopter didn't look nice so I threw in this test map from earlier this year.

November 16: Automated Dungeon Maker.1 (Download: Zircon Beta #79)

Starting the automated dungeon maker. As a byproduct of just setting up an entry point into getting this started, I converted DM1 to Q3 format using Zircon pre-preprocessor -q13. (DM1 in Q3 Format)

1. Getting Started This "Will Do" As Level Of Appearance:

Will need set the planning on how the generator works .. it is probably going to be in QuakeC. It can't be in the engine. And it can't be in the .map. So QuakeC is probably where the generator must live.

3 method exists for generating the map: QuakeC via 100% entities, engine generation or calling q3map2 to compile. Other questions remain ... but immediate goal is getting map generation A to Z going ...

Should q3map2 be the method used, will need to make it so QuakeC can call the Zircon .map pre-preprocessor (the Secrets Finder does this) and Zircon will need call q3map2 to execute it (added "-shell" capability in engine 2 months ago, which I made work both in "blocking" mode and asynchronous mode -- this will need asynchronous mode that fires an event or something when it is done).

So while I never planned on making an automated dungeon maker, most of the required components to make this happen fortunately already exist.

End Goal Though .. At Least This: (Zircon Intermap/park.bsp):

Note to self: dig into KleskBY Qualker GLSL and existing GLSL capabilities.

November 15: Unicode Characters In Paths (Download: Zircon Beta #79)

This was on my short todo list and then today KleskBY had a game crash with unicode characters in the path. I was very aware of this as a potential issue as DarkPlaces Beta github has this addressed recently and Zircon uses the previous code that works with directories on Windows in a non-unicode friendly manner.

Map Decompiler In Zircon?

Random dungeon generation by Christmas is my #1 priority and Zircon has an incredible .map pre-processor. Part of me wants to "level up" working with the BSP format and DarkPlaces already has "modeldecompile" (which can do BSP to OBJ).

One way, I might consider leveling up is making a map decompiler in Zircon. Should I choose to do this, I would eliminate some of the remaining "gray area" in my understanding of the .map format.

One reason I might not do it: sounds boring and currently I'm seeking to do some coding that is exciting at the moment. There are times I where I like to deep dive into the boring tedious tasks, but it is not something I can force myself to do. I'd rate the odds that Zircon has a map decompiler built-in by February 1 around 65% because this seems like something I would want to do on a snowy day.

No matter what: Zircon Beta Release #80 with unicode path support in 48 hours or less.

CSQC Flashlight 3 With Radar/Compass (Download: Zircon Beta #79)

Upcoming: Randomly generated dungeons before Christmas. And wrapping up another project and releasing it also ("Shambler Invaders"). Both of those projects leverage the Zircon Q3 .map pre-processor to do what would otherwise be virtually impossible maps and game play experiences.

When I wrote the .map pre-processor in September, I did not know I would be using it to make random dungeons, but I did know that the .map pre-processor would open several new doors to otherwise impossible maps.

Flashlight Radar Compass ...

CSQC Flashlight 3 combines all the previous CSQC modifications (Radar, Quake With Health Bars, Secret Finder) and adds a compass and a "Settings Panel" (press TAB). The flashlight and compass work in DarkPlaces and older Zircon Alpha. QuakeC source code is in the download (CSQC Flashlight 3 Download).

Pictured: The TAB activated "Settings Panel" turns on/off options. For example, the Secret Finder can display a box the size of the entire trigger in the map.

Not sure that this mod and map is going to get finished in 2024 ... the automated dungeon generator is going to have priority.