Trying to watch this again :D
It's so long. The voice acting is hilarious. I've tried to watch it numerous times in my life. 

Solved a lot of that stuff engine side - rotatings especially.

Mh did it for RMQ engine, but that was spoiled since nobody wanted the mod.

The main thing is that it's hard to decompile the solutions from Q2 - you really need the source and a reason to do it.

The reason is usually supplied because a mapper wants feature X.

The best mod for mapper features was Q2 Lazarus - physics, weight, monsters improvements, custom monsters, custom monster flags, monster AI (including proper jumping and waypoints), new weapons, trains, drivable vehicles and a load of other stuff. It had (a lot) more features than HL1.

It also, unfortunately, never really had its potential tapped. The handful of mappers who used it just wanted to use the homing rockets flag.

Q1 has had a number of attempts at housing the various features in a single mod. Extras R4, Quoth, AD and the various other megamods all grabbed a few off the mapper wishlist.

Ultimately mappers don't want/use them though, which is a shame.

And yeah, Q2 is hard to decompile and does not translate to Q1 codebase. 

Is more entertaining than the MCU. 

I don't disagree with most of what ijed says, but mappers absolutely do want and use those feature-mods like Quoth, AD, Alkaline, and progs_dump. 

Software Quake prevents z-fighting by making all brush entities be clipped by the world brushes in worldspace. And this is only done against the world brushes, not against other BSP entities, which is why maps such as the ones in Contract Revoked have per-scan z-fighting issues in software Quake engines.

BSP entities such as func_wall are not "worldspawn" entities. Their brushes are stored in the map's BSP, but they're processed along with external BSP entities such as ammo boxes.

But anyway, with current hardware-accelerated Quake engines hitting a thousand frames per second, it's a shame that none of them uses some CPU code to clip the brush entities' polygons against the world like WinQuake did. That would have zero performance impact for the world itself.

Scrolling textures is another Q2 feature that I'm sure would get a lot of use in Q1.
Retroquad has it, using the [ and ] characters in texture names to indicate negative and positive scrolling for both axes.

DP and FTEQW likely supports it in some other way, maybe through Q3A shaders. But I don't remember any engine specifically using Q3A shaders in Q1 map formats. 

Proper rotating brushes would be great, but the Q2 solution relies in the q2bsp format. They store original brushes in there so that the engine can expand them in realtime. If you search for "true rotation" on this board there are conversations about a less painful method. I think those attempts were abandoned due to backwards compatibility. They also have issues due to ignoring the fact that a rotated hull won't give accurate collision.

I think good ladders are achievable in quakec, unless your complaint is the need to place a trigger instead of tagging brushes as "ladder". Probably just needs more code iteration to make it good.

Scrolling textures -- agree on this. An easy feature to implement, just needs an accepted standard, and then an example implementation. I guess the right people never strongly cared. (correction, some engine coders did address it, for example mankrip added it in retroquad I believe. And LordHavoc would probably tell you that darkplaces already supports q3 shaders so just use those.) 

Can't be func_walls, because if that were the case it wouldn't have ever looked correctly, not in WinQuake, and not in GLQuake.
Must be plain worldspawn. 

#32086: coplanar polygon overlapping simply does not exist in the BSP format. Polygons in a model can only be overlapped by the polygons of different models, and for that to happen they must be used in different entities.

dumptruck_ds: does that also happen in this version of Beyond Belief? I'm going to take a look into that later. I know the old release runs in WinQuake, but the newer wip version should run in MarkV WinQuake. 

Also, Z-fighting in the worldspawn model simply does not exist in WinQuake. func_walls does look correctly in it no matter how much polygon overlapping there is against the world model.

As I said, WinQuake clips func_wall polygons against the world polygons in worldspace, killing any overlapping against the world. 

Well yes, coplanar worldspawn brushes will just leave either one face or the other after compiling, that is my point. Either the compilers or the brush order must have changed.

In WinQuake, overlapping func_wall would have been invisible, i.e. the opposite of the desired result. Since it used to look right, it couldn't have been a func_wall. 

A significant percentage of what people want can be achieved by just using the Q2 BSP format. Of course that brings in other things that people don't want, such as storing textures outside the map.

Some of these features were discussed when designing BSP2, but in the end the overriding priorities were ease of implementation in existing codebases and keeping compatibility with the original .map file format. The fact that BSP2 succeeded vindicates this, but I still regret not including a Q3A lightgrid lump.

I need to look over how software Quake clips brush models again. It's been a while but my recollection is that it's not actually that simple, and may have dependencies on faces being converted to spans before it does the clipping. 

Case in point; ladders and rotating brushes. Quake 2 got ladders right on its first try 25 years ago, yet AD has those godawful sticky catapult deathtraps.

AD has 3 ladder systems;
1=Rubicon2 (sticky + jump upward only movement)
2=Extra4 (player facing direction for up/down movement)
3=FTE (uses skin key, works like extra4)

The reason most people use the rubicon2 system because its easy to implement, the source is available and most people understand it straight away (ie don't fall off ladders and die) Probably the best system is the FTE skin system (closest to Q2) because its engine controlled and not hacked by QC progs to fight the engine physics.

I have pestered eric to add rotating brushwork support to Quakespasm for years and at this point I think everyone has just given up because the chance of it breaking something else in the engine is too high! With no universal engine solution everyone just accepts the shite QC Hipnotic version instead. The RMQ and DP/FTE versions are very good, but to really make a difference it needs to be added to the core (QS/Mark/Fitz) engines to really be adopted. Ideally it should be a declared feature so that progs can switch around rotation types.

PS. Tried to login properly, but can't remember password anymore. I had to reply to the AD jab from Text_Fish because there is a lot of history to the reasons why stuff is the way it is! 

nathnolt has the best ladder. In bsp. He let me use it in the map I just released. I used it in 2 places. One place is the courtyard at the start. You just walk forwards, and you convincingly bounce up the steps, one at a time, at a believable speed. 

I need to look over how software Quake clips brush models again. It's been a while but my recollection is that it's not actually that simple, and may have dependencies on faces being converted to spans before it does the clipping.

I don't remember the exact order, but here are the steps:

First of all, the server uses VIS data to determine which BSP entities may be visible to the client.

The engine clips all visible BSP entities' polygons against the world. Somewhat similar to selecting the world in a map editor and using the "carve" function. This is what eliminates coplanar textures in software Quake.

Frustum clipping also clips the BSP polygons, this time against the frustum.

Spans clipping is the last step in vanilla software Quake. It clips the spans of the resulting polygons against each other in screenspace, ensuring zero overdraw and eliminating most of the need for a depth buffer.

Z-buffer checks clips the polygons' spans on a per-pixel basis, and is only done by custom engines with features that requires overdraw (semitransparent water, colormasked textures, etc).

Vanilla Quake's source code makes things confusing because the worldspace "carve" clipping, the frustum clipping and the screenspace spans clipping uses very similar terminology in the code. There are lots of "edge" clipping stuff in the comments with no mention of screenspace and/or worldspace. 

In WinQuake, overlapping func_wall would have been invisible, i.e. the opposite of the desired result. Since it used to look right, it couldn't have been a func_wall.

Good point. Maybe, for some reason, that worldbrush was now converted into a brush entity by either the map editor or the BSP compiler. Comparing the current map sources against the map sources of the original release may give a clue.

Also, r_drawentities 0 helps to identify which brushes are part of BSP entities.

If the coplanar polygons are still present with r_drawentities disabled, there's something really broken in the BSP file. 

If this was an endurance excercise to see who can keep guessing the longest without opening TB and actually testing it, I guess I lost.
No but seriously though, there's no need for some rogue brush entities when it's simple qbsp. I think I got it right in #32075, then metl agreed, and then dumptruck never responded.
Like this. Note that TB doesn't consider brush order to be significant, while compiler clearly does. Case solved? 

I thought you were talking about a problem that happens when actually playing the map. What happens in the video you've shown is normal behavior, with the resulting BSP having zero polygon overlap.

At 0:26 the small brush appears because the big brush was carved by the BSP compiler to make space for the small brush. There's absolutely no overlap happening in the engine.

Brush carving order during compiling is up to the compiler, and can also be completely random. There are no rules for it in the map spec. This is why map editors have a "carve" feature, so the mapper can manually define which brushes should be cut to make space for other brushes.

Developers shouldn't rely on undefined compiler behavior. This is true for both programming and mapping.

There are many ways that undefined behavior can go wrong. For example, nothing guarantees that when copying & pasting multiple brushes the order between them will be the same. And afaik, there are zero editors with an option to display the brush order. It simply shouldn't be relied upon. 

This reminds me of when Abrash mentioned that despite out-of-order execution making CPUs much faster, it became impossible to predict exactly how many cycles a function would take to execute.

With multithreading and many other optimizations in modern BSP compilers, I wouldn't be surprised if the brush clipping order became completely unpredictable. EricW has much more in-depth knowledge about this than me, maybe he can give a better answer. 

Two things. Matthais hasn't been back to the Discord so no need for me to follow this any further.

I saw your reply and metl's follow up. Thanks! GOod info and great illustration.

P.S. Log in FFS. 

https://lvlworld.com/review/id:2339 

I made this other account called "Mopey bloke" with space. I no longer have that passphrase. If you want, go ahead and delete that please. 

https://www.einpresswire.com/article/561032975/new-research-modernist-architecture-may-be-bad-for-health 

Discord is down, time to party like it's 2002!

But seriously, it's a good thing the community is distributed.