update README files to reflect further 0.85.10 changes so far.

git-svn-id: svn+ssh://svn.code.sf.net/p/quakespasm/code/trunk@977 af15c1b1-3010-417e-b628-4374ebc0bcbd
Revert r968, optimization in R_DrawSequentialPoly. Going to try a deeper change that uses the world drawing code for bmodels.

git-svn-id: svn+ssh://svn.code.sf.net/p/quakespasm/code/trunk@978 af15c1b1-3010-417e-b628-4374ebc0bcbd
Remove R_DrawSequentialPoly and use texture chains for drawing brush models.

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+ssh://svn.code.sf.net/p/quakespasm/code/trunk@979 af15c1b1-3010-417e-b628-4374ebc0bcbd
update README files to reflect further 0.85.10 changes so far.

git-svn-id: svn+ssh://svn.code.sf.net/p/quakespasm/code/trunk@980 af15c1b1-3010-417e-b628-4374ebc0bcbd
Simple use of vertex arrays in R_DrawTextureChains_Multitexture.

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+ssh://svn.code.sf.net/p/quakespasm/code/trunk@981 af15c1b1-3010-417e-b628-4374ebc0bcbd
Silence warning about vid_fsaa requiring restart when parsing config.cfg at startup. Add missing newline to warning message.

git-svn-id: svn+ssh://svn.code.sf.net/p/quakespasm/code/trunk@982 af15c1b1-3010-417e-b628-4374ebc0bcbd
Revert r981 "Simple use of vertex arrays in R_DrawTextureChains_Multitexture."
It caused a dramatic slowdown on my machine on windows (50% slower)

git-svn-id: svn+ssh://svn.code.sf.net/p/quakespasm/code/trunk@983 af15c1b1-3010-417e-b628-4374ebc0bcbd
dropped support for GL_SGIS_multitexture

git-svn-id: svn+ssh://svn.code.sf.net/p/quakespasm/code/trunk@984 af15c1b1-3010-417e-b628-4374ebc0bcbd
PF_VarString: raise buffer size to 1024. I checked all buffers that the resulting string could end up in, and they're all at least 1024 bytes (even with an unmodified quake client).

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+ssh://svn.code.sf.net/p/quakespasm/code/trunk@985 af15c1b1-3010-417e-b628-4374ebc0bcbd