Probably this was added previously due to confusion with edge index
being +1 (no edge 0) but lump->size / sizeof(edge_t) is the correct
number to load.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Turns out there are two types of "BSP2" format - one that I think was
created by MH and implemented in the RMQ project (this is the one I
implemented previously) and one by LordHavoc which exteneded the
coordinate limits beyond 32k, implemented in Darkplaces. The
Darkplaces version of BSP2 will get the name BSP2 and the RMQ version,
which is more limited, will get the name BSP2rmq.
Fairly naive implementation which duplicates a bunch of code. Can be
refactored and tidied up more later.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Provides a modest speedup on Windows, where this operation is ridiculously
slow. Reduces time for simple "make" with no rebuilds necessary from ~23s
to ~18s on my test system.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
When set to 1 mouse look key stops mouse looking
Signed-off-by: svdijk <svdijk@users.sourceforge.net>
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The multiplayer translate pic needs to be a particular size, so test for
that and just allocate the appropriate sized buffer. There are better
ways to handle this, but this is still better than crashing on a bad pic.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Handle this during the texture conversions explicitly - it is actually
valid to make use of this colour in normal textures.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Was for compatibility with vid_sdl + in_win, but not worth supporting that
configuration I think.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
After realising that we have different alpha channels on different qpics,
it didn't really make sense to have a simple boolean for alpha and then it
didn't really fit into qpic8_t any more.
Specify the alpha channel (if any) at upload/conversion time instead.
Fixes sky alpha and removes the charset hack converting all zero indicies
to 255 in the glquake case (maybe someone wants to use the 255 pink in
their charset?)
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Generally we don't want to be modifying the texture data, so this
seems like a sensible precaution to help prevent unintended
modifications.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Didn't realise this was happening, but in the software renderer, we
were re-drawing the version number into the console every time we
rendered the console. Split up the caching function so that we cache
this work.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
We allow for a "stride" parameter so that sub-pics can be used and a
simple boolean to indicate if alpha is enabled or not for palette
index 255.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Fickle man that I am, I decided now that qtexture32 is a poor naming
choice and I'd rather stick with calling these 'pics'. Will have to
rename the files now as well I guess.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Now that we take consistent command line parameters across platforms,
remove the _WIN32 ifdef. Try to give a sensible suggestion for increasing
the memory size instead of just saying 'try 16MB' - since the default is
128MB anyway!
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
set the colour channels of fully transparent pixels on 32-bit textures to
the average of their non-transparent neighbours, to avoid artifacts when
blending (or creating mipmaps, etc.)
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Created the gl_extensions.c file to pull some of the common stuff into
where appropriate. Non-power of two textures will be allowed by default,
with the option to go back to old behaviour by setting command line option
"-nonpot" or cvar 'gl_npot 0'. The cvar is a bit of a hack, as existing
textures won't be reloaded at this stage.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
New mipmap code handles odd textures sizes so that we can start using NPoT
textures where the hardware supports it. We've also removed some texture
size limitations - the new code is only limited by the available space on
the hunk.
We're still unconditionally stretching to power of two, so this doesn't do
anything noticable yet. One thing this fixes is generating the lowest
level mipmaps where the texture is only one-pixel wide or tall - the old
code didn't handle this special case properly.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Mainly because taking the address of the data pointer and casting to
byte * is something easily confused.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
