There would have to be incredibly compelling reasons for anyone in this community to consider switching from ericw-tools.

Total feature parity with ericw-tools would need to be a starting point I would say, and then it would come down to what a new compiler system could offer in addition to that. 

I understand there is a biiiiiiiiiiiiiiig long-in-works update to the ericw-tools coming at some point. 

Some of the features listed in that P2ST thing sound bloody fantastic.

But my personal view is that the best chance of getting any new awesome stuff to be used by the Q1 community, would be to collaborate on ericw-tools, rather than try to push a competing and different set of tools. 

 

Duplicate of my reply in the News' comments just in case.


On Quake lighting Uncle Mike wrote:
"added full support for Quake lights and their specifics" and mentioned all these delay, wait, cone, cone2, etc.
and "introduced -quake key, sets gamma 1.0, -dscale 0.5, -sky 0.0, and enables -lightbalance. Basically this is a preset to make lighting purely Quake-like".
https://csm.dev/threads/p2st-compile-tools-v-096-beta-bezier-curves.39031/


On limit exhaustion:
https://csm.dev/threads/novye-kompiljatory-urovnej-dlja-xash3d.38603/post-951887

You probably know that now I can't sit tight because of Ericw's compilers for Quake called TyrUtils. Can't say that they're better than mine in all aspects, more like the opposite. But they do possess certain features I don't have. Therefore - these should be added. Meanwhile I compare them for effectiveness and speed.

My coplilers
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
entities [variable] 205865/2097152 ( 9.8)
planes 4968/524288 99360/10485760 ( 0.9)
textures [variable] 8852/33554432 ( 0.0)
vertexes 23696/393216 284352/4718592 ( 6.0)
nodes 9839/262144 432916/11534336 ( 3.8)
texinfo 1212/262144 48480/10485760 ( 0.5)
surfaces 17951/262144 502628/7340032 ( 6.8)
clipnodes 16821/262144 201852/3145728 ( 6.4)
leafs 6289/262144 276716/11534336 ( 2.4)
markfaces 21909/327680 87636/1310720 ( 6.7)
edges 42399/1048576 339192/8388608 ( 4.0)
surfedges 83552/2097152 334208/8388608 ( 4.0)
models 215/4096 13760/262144 ( 5.2)
=== Total BSP file data space used: 2.70 Mb ===
World size ( 2560 2304 3968 ) units
original name: maps/ad_metmon.bsp
internal name: Arcane Monstrosity

TyrUtils
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
entities [variable] 204240/2097152 ( 9.7)
planes 4855/524288 97100/10485760 ( 0.9)
textures [variable] 854214/33554432 ( 2.5)
vertexes 30612/393216 367344/4718592 ( 7.8)
nodes 16485/262144 725340/11534336 ( 6.3)
texinfo 1359/262144 54360/10485760 ( 0.5)
surfaces 25385/262144 710780/7340032 ( 9.7)
clipnodes 25845/262144 310140/3145728 ( 9.9)
leafs 10496/262144 461824/11534336 ( 4.0)
markfaces 29568/327680 118272/1310720 ( 9.0)
edges 65668/1048576 525344/8388608 ( 6.3)
surfedges 100675/2097152 402700/8388608 ( 4.8)
models 215/4096 13760/262144 ( 5.2)
=== Total BSP file data space used: 4.62 Mb ===
World size ( 2688 2432 4608 ) units
original name: maps/ad_metmon.bsp
internal name: Arcane Monstrosity

Performing time of my compilers:
4 sec csg + 12 sec bsp
Memory consumption: csg 39.64 Mb, bsp 30.36 Mb (memory not summed up)
TyrUtils:
11.000 seconds elapsed (qbsp)
Peak memory usage: 163320980 (155.8M)

What is intresting:
1. In terms on limit exhaustion my compilers are definitely more optimal than TyrUtils. Nearly 1.5 times more effective. It's unclear why planes are being exhausted faster though. I mean it doesn't matter, they're 32-bit-limited, but anyway.
2. Memory. I was in doubt but nearly 100% sure now, compilers were split to save memory indeed. This is the most simple way besides screwing with correct memory freeing. And the effect is quite noticeable, too, as you can see. We win 2 to 4 times more memory.
3. TyrUtils work in a single thread (qbsp) without any special optimizations and they're still faster. I've got a couple guesses: either SSE optimization of modern IDEs give an effect here, or this is an effect of VHLT's chinese accelerator of BSP tree building, for small trees lagging more than original code but accelerating greatly with increasing polycount. Can't say for sure yet.

And there is another post with statistics on the same page.
Keep in mind that this was early on and he kept working on P2ST throught the next year. 

I had a short out-of-state vacation interrupt my participation.

When I returned I had to double down on engine coding before reading any forums because I am not happy if unreleased code is on my hard drive, moddb was down some messing with that.

btw .. nice video. Ironwail looks really user friendly and I knew it would be if the developer interacted with you, haha!

Very pleased to see the mouse driven menu and what looked like Quaddicted install. 

Sure, it needs to get closer to final form and it will.

You really excel at doing videos. 

 

lots of work over 3 months! 

hi, there was this one small rusty industrial vertical SP map, described as innovative on quadicted. any idea which one it could be pls? thanks 

ok https://www.quaddicted.com/reviews/aes_lrod.html srry 

After working on inspecting the interior mechanics of DarkPlaces, I go to close my image editor.

It ask confirm closed unsaved image about 50 times, I had taken screenshots in Visual Studio of the variables and call stack watching it work many times, noting the call order so I don't mess anything up by failing to understand what is going on fully.

I make DarkPlaces do the things that a single player enthusiast will do, find small things that are important. DarkPlaces marks all data for clearing on a restart, it performs a restart on gamedir change or video mode change. But it retains a list of the models currently used, for faster loading.

And noticing this, I solve a crash that I didn't understand. If you switch gamedir, "maps/start.bsp" might not be the same map. In fact, anything could be different.

After reaching the end of "the list"

I ask ... "spent all this time and haven't got to do anything 'fun' or 'cool' yet?" which is a separate list.

And the counter thought is "DarkPlaces needed someone to do this long ago".

And the other counter thought is DarkPlaces has a feature set by dozens of imaginative and talented people.

Where will the future lead?

There are always 2 questions that anyone should ask ... "what are you doing" and "why are you doing it".

The answer for me is I want see what happens if I can unlock the unused value from several underutilized resources all the same time and see what .. if anything ... will happen.

For me, this is both benign intent and the desire to see if the results are amusing. I am curious to know. 

So testing things out in DarkPlaces, come upon a map with dogs floating in air.

I do some ground work and find the last version without the issue (2012 Dec 22). droptofloor is a little different. And it might have even been to make DarkPlaces work better with Quake.

The motivations for DarkPlaces are different and new games/mods were priority.

As far I can tell, there really is no one developing DarkPlaces as a Quake client, seems to be non-Quake development uses only.

I don't know why exactly ... perhaps they got demoralized with bug reports about Quake? I am just guessing.

The reason that I feel this could be the case is to debug Quake issues you need to know:

1. the mechanics of QuakeC
2. How monsters/physics work in a single player Quake map, the order they occur. Someone can engine code but without knowing the mechanics of QuakeC, some of the issues are going seem unsolvable.
3. Be someone who has played a lot of Quake maps, particularly custom single player maps and know the oddball maps that do crazy stuff.

All of the above is taken for granted here. 

You might want to check the dpcompat_* cvars in FTE. Those cvars generally denote behaviour differences that I added to allow FTE to be configured to act like DP for compat with DP-only mods, instead of is more traditional behaviours. Not all of it is relevant for QS compat, but dpcompat_noretouchground is a good one to start with.

Additionally, the areagrid changes in DP will result in triggers getting touched in a different order (primarily breaking maps with lots of trigger_push volumes). FTE has the same issue. :(

droptofloor is a recurring issue for DP mods - setmodel did setsize(ent, '-16 -16 -16', '16 16 16') in vanilla, but various engines including DP use the model's size. QS has the same issue, but QS tends to have fewer people replacing models willynilly and then getting surprised when the hull collisions change resulting in ents traces going skewy. I suggest you use the filename and only use the actual size for inline and .bsp models (like fte does) rather than doing it based on actual file type - slightly reducing issues when people replace ammo boxes with mdls.
Obviously if it makes a difference then the mod is buggy anyway, but that tends to be their default state.
Sidenote: SV_RecursiveHullCheck got completely replaced (for good reason). Expect some droptofloor differences because of that too.

and yeah, have fun with the whole sv_gameplayfix_* nightmare...

And once you'd fixed QS compat stuff, all the DP stuff will be broken and a different group of people will complain at you instead (more likely both groups).
Compat is a fun never-ending nightmare. Enjoy the treadmill. 

I've carefully plotted my navigation with the perils of those gameplay fix cvars.

However thanks for pointing out the potential bmodel thing.

I should be "ok" because standard QuakeC sets bmodel sizes for all the box models. So replaced or not, that should be ok as a general rule of thumb.

I thought DarkPlaces had solved the all the floating models thing by (attempting) to set everything to baseline Quake.

The floating dogs wasn't a setsize thing. That was the first thing I checked. And I think I have the issue fully solved, but the impossibility of verifying 3000 maps/mods leaves that "tbd". 

Spike, I see you have been on a furious rampage while I have been gone. Congratulations of the sheer volume and scale of your works!

Super, super, super impressed by fteqcc.

I was able to use my Vulcan mind meld ability (that happens when I have read someone else's code a million times) to imagine features that Spike would do in fteqcc to derive undocumented or barely mentioned features.

I think my batting average was an insane 98% or so, and I just kept getting more impressed as I kept on finding you had already done "something I wish it would do" over and over and over.

You have made QuakeC like real C about as much as it can be. 

Of all the features, the surprise discovery of variadic macro support was the one that made me the most happy.

I have abused that one to no end.

(yes, triple post. But no edits here .. what else can I do.) 

Spike, DarkPlaces uses vid_conwidth and vid_conheight during CSQC_UpdateView.

Xonotic and stuff like Quake 1.5 depend on this behavior. Xonotic will set vid_conwidth/height in CSQC_UpdateView which does not take effect in the current draw frame.

In my opinion, CSQC_UpdateView should receive a full canvas of vid.width and vid.height.

To give mods like Xonotic or Quake 1.5 what they expect, but to give a mod the option of a full 2D ortho canvas .. I am doing this at the moment ...

I have created a cvar csqc_full_width_height_available 1.

A mod can check to see if the engine has the option of giving a full canvas.

In default.cfg or quake.rc, a mod can set csqc_full_width_height 1 to ask for the fullscreen canvas.

In CSQC_UpdateView, checking those cvars allows the mod to act on either canvas type, giving DarkPlaces the right stuff or Zircon the better stuff.

fteqw does something different and I imagine it gives full canvas.

I hate the method I have come up with, but it will work. Yes, I could turn the cvars into extensions, but I don't know what extenison numbers are safe to use -- there is no "Baker's range" from 1500 to 1800.

I want any qc mods I make to eventually be compatible with fteqw (fteqcc says detected "DarkPlaces only mod").

I know you have already thought about this topic and know a better way. 

I'm not sure what you mean by 'fullscreen canvas' - the canvas that csqc draws on is ALWAYS the full-window. Other programs running on the same machine are generally hidden and irrelevant anyway.

What your 'csqc_full_width_height' refers to is unclear too. 'Full' as in a 1:1 ratio in your 2d projection matrix? So that mods running at 8k end up with un-readably small huds? Most mods are badly written monstrosities that won't remember to add custom scaling factors everywhere (or will fail to test it properly and generally screw it up).
There's a reason there's scaling. It simplifies mods, reducing these issues.

IIUC, DP mods that stomp on the user's choice of values for vid_conwidth/vid_conheight are generally trying to work around various other DP bugs. I've gone on this rant before.
If you're reading vid_width to compute the 'proper' vid_conwidth then you're going to bug out when vid_restart fails (or just hasn't been used yet), or when resizing the window and just completely bypassing vid_width entirely.
This is why vid_conwidth 0 (or height) means 'auto' in FTE - so the CSQC_UpdateView's width+height args can always have the right aspect without needing cvars to change when cvars are changed etc.

It should also be noted that the vid_conwidth+vid_conheight cvars do not exist in QSS. Cvars are evil. They do not make for good APIs, especially cross-engine ones. Mods depending on specific values for them is an additional nightmare for modders when their mod doesn't work for that one user who just loves to set random cvars and assumes other mods need them too, or w/e. If a mod needs to read/write a cvar just to get its drawpics in the right place then its a bad/buggy mod.

Poke me on discord if you want a real discussion, func doesn't seem appropriate for walls of text that isn't even relevant to mappers. 

Poke me on discord if you want a real discussion

You efficiently communicated everything above. ;)

Most mods are badly written monstrosities that won't remember to add custom scaling factors everywhere (or will fail to test it properly and generally screw it up).

Yes, I was already leaning towards that.

I will say, it is not their fault, per se.

The original Quake C source code is pretty ... well ... shitty and compared to fteqcc, the original Quake C compiler is very shitty.

And csqc and the extensions are marvelous. I have been able to capitalize on them.

If I were not an engine coder, I would stand no chance of effectively using csqc. I probably had to look at the engine source 300 or more times, and numerous times had to watch a function in action with the engine in debug mode.

And csqc and the extensions are marvelous --- if the community were of greater size that had an ecosystem of scale to document and video and tutorialize .. things might be different.

Enough said ... 

Poke me on discord if you want a real discussion, func doesn't seem appropriate for walls of text that isn't even relevant to mappers.

I really hope you keep talking about this on func (maybe in a better thread though) as I am sure there are plenty of mapper/coders around who love to read this stuff. Moving conversations to discord will mean the information will be lost for searching in the future. 

EOM