Now that I've done this I realise there could be a more compact
representation by just specifying the number of leafs per cluster, since
leaves are sequentially numbered... but this format is okay as well. And
easy to parse, etc.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Fairly simple extension of the original "PRT1" format; the first four
lines are:
Identifier := "PRT2"
Number of Leafs := INTEGER
Number of Clusters := INTEGER
Number of Portals := INTEGER
Followed by one line for each portal made up of the following, separated
by whitespace:
Number of points on the portal winding := INTEGER
Cluster Number on the front side of the portal := INTEGER
Cluster Number on the back side of the portal := INTEGER
For each point, a coordinate in the format ( x y z ), where x, y, z are FLOATs.
After the portal descriptions, there will be one line for each cluster
which lists the leaf numbers included in that cluster.
LEAF1 LEAF2 LEAF3 ...
I should probably write this up in BNF somewhere, but it's pretty straight
forward.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The test here was really to see if we need to add a portal between two
adjacent leafs with the given content. Rename and re-arrange the code a
little to make it a bit easier to read.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Need to be a little more careful to order brushes correctly when adding
detail to the worldspawn. CSGFaces assumes that the brushes are ordered
such that earlier brushes have chunks carved out of them by any later
brushes that intersect them.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
During conversion from map brushes to bsp brushes, set the brush detail
flag for later use in CSGFaces().
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Pull the progress output up into the caller (not ideal) to deal with the
fact we are making extra calls to load the detail entities for the
worldspawn.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The first step towards supporting detail brushes for Quake 1. This gives
us a way to add detail brushes to a map within the existing mapping tools. A
mapper can simply add a definition for a "func_detail" entity to their
editor and create func_detail entities.
Of course, currently they will behave exactly like world brushes. Future
patches will start to treat them differently.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Make Brush_LoadEntity() take a source and destination entity arguments. In
order for this to work, intialisation is done before calling and then the
BSP brushes generated from the source entity's map brushes are added to
whatever is already in the destination entity.
Reasons for doing this will become obvious with the following patch! :)
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Less error prone as it's usually followed by a strn?cmp or something.
Callers that were relying on null checks updated.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Still have the limitations of MAX_FACES, etc. but in practice it's
probably not going to be an issue.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
We don't need very precise time - only used for telling the user how long
the compile took, so use the most portable API. Fixes compilation on
OpenBSD/FreeBSD.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The previous code would possibly leak faces with weird effects if we
iterate over the face data e.g. 0 -> map.numfaces.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Kevin Shanahan