Instead of doing awkward gymnastics to try and load the brushes and faces
into memory in reverse order for compatibility with the original qbsp,
just load them in map file order.
Simplifies iteration over the data, particularly if I want to load less
items than the pre-parse found.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Future work will break the assumption that the number of used items will
be equal to the maximum number of items, so separate the two numbers.
Replace use of maxblah with numblah as appropriate.
This makes the reverse order loading or brushes, etc. look even more
painful, so will look at whether we can change that now. As far as I know
no editors do clever things that would make the map compile "better" in a
different order - it's just that it might break some previously working
maps if they were an edge case that different ordering makes the precision
flip in a non-favourable direction.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
It does make them somewhat less greppable, but makes the variable naming
style more consistent with the rest of the quake utilities.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The count members are actually where we store how much memory has been
allocated for each type of item in the mapdata struct, so rename these to
indicate these are the maximum counts.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Instead of iBrushStart and iBrushEnd, we now store a pointer into the
mapbrush array and store the count of brushes for this entity. pBrushes
and cBrushes members are renamed to brushes and numbrushes, respectively.
The iBrushes member of mapentity_t is no longer needed.
At this stage we still go through hoops to load the brushes in reverse.
The original comment indicates that this was needed for compatibility, I
may try simplifying and loading in map file order and see if that has any
ill effects on compilation of test maps.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Make the caller look up the fixed origin again if they need it rather than
always passing in/out an origin. FindTargetEntity also now returns a
pointer rather than entity number.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Offsets pointing to clipnodes were originally used as signed short (16-bit)
numbers, so that negative numbers could represent the various content types of
leaf nodes. However, only a small number of these types are required, so we
now make use of the rest of the clipnode range.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Ugh, looks like this extraneous line snuck in with commit 6bb3ad32
While I'm here, I see no reason to zero pWorldEnt->cTexdata just above
either. It should already be zero'd memory from the malloc of map.rgEntities.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Use a hash to speed up FindPlane for maps that have huge numbers of
planes. Not many maps have enough planes that this is a win, but those maps
are the ones where speed matters most. :)
Signed-off-by: Tyrann <tyrann@disenchant.net>
To make testing easier, log the output of the job to mapname.log, rather than
qbsp.log. Probably more desirable to make the logfile selectable in the long
term, but this will help for now. Note that we now don't open the log file
until after parsing the command line options, so the Message function needs to
check the file handle before writing to it.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Add the "-wadpath" command-line argument to allow the user to specify a
directory where wad files can be found. If no wadpath is given, the path
defaults to the directory where the map file is located. Absolute path names
in the worldspawn "wad" key should also work.
Signed-off-by: Tyrann <tyrann@disenchant.net>
The options are currently parsed as a big text array, so that the parsing
function can be shared with the code to load options from a file. Anyway,
dynamically allocate the array to copy in the command line arguments rather
than restricting it to 512 bytes.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Make all WADList functions take a pointer to the first wad_t, rather than
embedding it inside the struct wadlist. wadlist_t is no longer needed.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Begin breaking down the wadlist_t structure by having the Init function return
the number of wads loaded to the caller, rather than relying on just setting
it internally.
Signed-off-by: Tyrann <tyrann@disenchant.net>
If the map has no wad key, or none of the wad files found in the key can be
loaded, then try loading mapname.wad as a default.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Move the logic from WADList_LoadLumpInfo into WADList_Init. Now the init
function will open all the wad files, testing for validity. Note that I still
need to tidy up the error handling and warnings a little bit to handle the
difference between filesystem/read errors and invalid/corrupt wad files.
Signed-off-by: Tyrann <tyrann@disenchant.net>
The wad_t struct is actually a list of wads, and the wadlist_t struct
represents the info for a single wad. This is kind of backwards, so reverse
the names. A few function renames went along with this to make things look
saner.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Replace the WAD class with plain C code. Class WAD becomes wad_t and the
member functions are just normal functions taking a wad_t as an argument.
The iWad member was a bit strange. It was used in some member functions for
walking the wadlist array. I've elimanted that from the struct and made the
functions track that state themselves.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Kevin Shanahan
Tyrann