interpret -missionpack and [-]game missionpack as the same as a new
QuakeSpasm extension. besides, do not let loading of the mission pack
directory twice.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1011 af15c1b1-3010-417e-b628-4374ebc0bcbd
* make 'game' command to strip all mission pack support
* make 'game' command to accept an optional second mission pack argument,
i.e. -hipnotic, -rogue or -quoth.
* so the new behavior does:
game id1 --> really returns to bare id1 game, doesn't accept any mission pack arguments
game xxx -hipnotic --> strip down to id1 game, load hipnotic and load xxx on top of them
game xxx --> strip down to id1 game and load xxx on top of it
* additionally, some extravaganza:
game xxx --> if the game is already xxx, but the engine was started with -hiptonic
or -rogue or -quoth, strip down to id1 and reload xxx on top of bare id1
game xxx -hipnotic --> if the game is already xxx, but the engine was started without
-hiptonic, strip down to id1, load hipnotic and reload xxx on top of them
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1010 af15c1b1-3010-417e-b628-4374ebc0bcbd
Also surround the SDL version by "#if defined(USE_SDL2)" and "#endif", this
suppresses an unused function warning when building for SDL1. (Building for
SDL2 still gives an unused variable "modstate" warning though.)
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1002 af15c1b1-3010-417e-b628-4374ebc0bcbd
Not totally sure about this but i think it's a decent idea. I'm using 800x600 as a reference screen size (arbitrary choice but it's the default QS resolution). So if your resolution is 600 pixels tall this will make no difference. On higher resolutions this will make the console a bit faster than before.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@992 af15c1b1-3010-417e-b628-4374ebc0bcbd
PF_VarString is only called on the server, in:
- PF_error, PF_objerror, PF_dprint to print error / debugging messages
- PF_bprint, which calls SV_BroadcastPrintf which copies the string into a 1024-byte buffer, then sends that to clients in a svc_print message
- PF_sprint, which sends the string in a svc_print message using MSG_WriteString (without copying into an intermediate buffer)
- PF_centerprint, which sends the return value of PF_VarString in a svc_centerprint message (without copying into an intermediate buffer)
On the client:
- svc_print reads the payload string with MSG_ReadString (2048-byte buffer), then Con_Printf is called (4096-byte buffer)
- svc_centerprint uses MSG_ReadString then calls SCR_CenterPrint (1024-byte buffer)
I also checked the original quake source and the client-side buffers for MSG_ReadString, Con_Printf, and SCR_CenterPrint are all the same sizes as in QS.
Admittedly I want to support sock's ITS mod, but as far as I can see, it's a totally safe to increase this to 1024.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@985 af15c1b1-3010-417e-b628-4374ebc0bcbd
It caused a dramatic slowdown on my machine on windows (50% slower)
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@983 af15c1b1-3010-417e-b628-4374ebc0bcbd
The glBegin(GL_POLYGON), for() loop with GL_MTexCoord2fFunc()/glVertex3fv() calls, and glEnd () per polygon is replaced by a memcpy() and a glDrawArrays() call per poly.
My guess is this only saves function call overhead, but it gives a decent ~20% speedup (36 -> 42fps) on my machine on orl’s map.
Note: glDrawArrays() is in OpenGL 1.1, but the glClientActiveTextureARB function is part of the GL_ARB_multitexture extension but not GL_SGIS_multitexture. Instead of splitting into two code paths, I just dropped support for GL_SGIS_multitexture.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@981 af15c1b1-3010-417e-b628-4374ebc0bcbd
To make this work with the drawing order we use in gl_rmain (world excluding water, opaque ents, world water, transparent ents), I made each texture_t have two texture chains, one for world and one for bmodels. This way they can be cleared during entity drawing without having to regenerate the world ones.
Other than this the changes are mostly minor adjustments to the R_DrawTextureChains_* functions so they can work for things other than the world.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@979 af15c1b1-3010-417e-b628-4374ebc0bcbd
With that alone, the console would come down and slide up when the map changes in a demo.
I added a SCR_BeginLoadingPlaque() call in CL_ParseServerInfo, only done during demo playback, which shows the loading plaque and prevents the console from appearing and sliding up.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@976 af15c1b1-3010-417e-b628-4374ebc0bcbd
for a test case, play a demo from: http://www.quaketastic.com/upload/files/demos/otp_honey100.zip
for the honey map pack: http://www.quaketastic.com/upload/files/single_player/maps/honey.zip
on a slow pc that gets signifigantly less than 72fps, or with host_maxfps lowered (e.g. set to 33).
with QS 0.85.9, the demo will play in slow-motion; with QS 0.85.6 (without the cross-map demo support) it plays normally.
admittedly this is a fringe scenario, but it's imo a legitimate bug in the Pa3PyX cross-map demo playback code.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@974 af15c1b1-3010-417e-b628-4374ebc0bcbd
Not implemented for world polys (afaik it's useless for world polys) but could be added if needed.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@970 af15c1b1-3010-417e-b628-4374ebc0bcbd
Fixes "cycle r_wateralpha 0.3 0.6 1" not working reported by AAS.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@969 af15c1b1-3010-417e-b628-4374ebc0bcbd
From what I understand, if an entity touches more than MAX_ENT_LEAFS, it will only be visible
if the player happens to be standing in one of the first 'MAX_ENT_LEAFS' (so essentially random).
See discussion of MAX_ENT_LEAFS here:
http://celephais.net/board/view_thread.php?id=60310
For more detail (mh has an alternate fix, used in DirectQ/RMQEngine, haven't looked in to what he did):
http://forums.inside3d.com/viewtopic.php?t=2376&postdays=0&postorder=asc&start=23
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@967 af15c1b1-3010-417e-b628-4374ebc0bcbd
