Quakespasm 0.85.1 vs. 0.85.8

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Quakespasm 0.85.1 vs. 0.85.8

Post by Baker »

Just looking to see what kind of changes took place and record them permanently. This covers differences in individual files only. Not new features like ogg.

bspfile.h - ifdef only
cd_null.c - nothing really. this file is usually used on systems without cd player support or where it hasn't been coded in the engine.
cd_sdl.c - Various stuff. I'm not worried about this file. Future thought: if a master "volume" cvar were to control all volume it must touch this file.
cdaudio.h - ifdef mainly. A function prototype change.

chase.c - Cvar now are chase_back = {"chase_back", "100"}; ---> cvar_t chase_back = {"chase_back", "100", CVAR_NONE}

1. I wonder why. This changes Cvar_RegisterVariable to the old style.
2. They changed "Length" to "VectorLength" (good! I hate "Length" because it doesn't indicate it is a vector function in the name)

cl_demo.c

1. I see snprintf is now q_snprintf
2. DefaultExtension now includes a sizeof param.
3. strcpy becomes q_strlcpy adding sizeof protection.
4. See this note
// O.S.: if a space character e.g. 0x20 (' ') follows '\n',
// fscanf skips that byte too and screws up further reads.
cl_input.c - the usual ... type checking stuff that non-Windows compilers complain about. Not going to mention these in future files unless important ...
cl_main.c - CL_Disconnect stops background music/CD Audio. Set cl.intermission to 0. max() has become q_max() [same with min() no doubt]
cl_parse.c - System_FloatTime is now System_DoubleTime. COM_StripExtension now has a sizeof final param. svc_setpause pauses/unpauses BGM music (ogg) svc_cdtrack - CDAudio_Play -> BGM_PlayCDtrack

Unknown:
case svc_stufftext:
cls.stufftext_frame = host_framecount; // allow full frame update
// in demo playback -- Pa3PyX
cl_tent.c - model_t has become qmodel_t? I wonder why.
client.h - client_state_t loses mapstring. gains stufftext_frame "host_framecount when svc_stufftext is received"
cmd.c - Hmmm ... Copystring is gone. Looks like replaced with Z_strdup which makes more sense anyway. Potential Cmd_Unalias_f bug fix.
void Cbuf_InsertText (const char *text)
{
...
// add the entire text of the file
Cbuf_AddText (text);
SZ_Write (&cmd_text, "\n", 1); // Ensure the added text has a newline at the end? Maybe if I file is added in this manner? :?:
// add the copied off data
if (templen)
{
SZ_Write (&cmd_text, temp, templen);
Z_Free (temp);
}
}
Before: static char *cmd_null_string = "";
After: static char cmd_null_string[] = "";
Trying to think of the specific merit of that and when it would help ... :?: External source files I suppose ... but it's static? :?: :?:
cmd.h - The usual.
common.c -
1. CRC for Quake 1.00 shareware, 1.01 shareware accepted in registered check ... ok. Historians special. :D
2. q_vsnprintf and q_snprintf
3. Never noticed Quake's COM_FileExtension is a bit weird. I had noticed it was "dumb" (8 char buffer for extension instead of returning pointer), but didn't notice the weird part.
4. COM_ExtractExtension
5. Nice! va with multiple buffers. Makes va so much more handy ...
6. FS_ functions

common.h - MSVC truncation warnings disabled. 7. extern qboolean fitzmode;
conback.c - Debug log isn't initiated in Con_Init, I hope it is initiated earlier.
console.c - Log_Init and Log_Close. Good ideas ...
console.h - Usual
crc.h - usual
cvar.c - Cvar locking. Cvar_SetCallback is now set versus being initiated with the var.
cvar.h - Usual
d_ifacea.h - This file is not used in GLQuake. They should delete it. :mrgreen:
draw.h - The usual.
gl_draw.c - QuakeSpasm -- menu scrolling. Really? :!: I've never noticed it. Maybe for small screen resolutions? I see 2 pics in memory. CANVAS_INVALID instead of -1, so enum changed no doubt.
gl_fog.c - Usual
gl_mesh.c - Something in BuildTris. Hmmmm. Copying a float into an int memory space. Then assigning an int to this memcpy of a float??? This doesn't sound right off hand, but it might not be wrong for reasons I don't understand yet. :!: :!: :!: :!: :!: :!: :!: :!:

OLD:
int commands[8192]; float s, t ...

*(float *)&commands[numcommands++] = s;
*(float *)&commands[numcommands++] = t;
NEW:
int commands[8192];
...
int tmp;

// emit a vertex into the reorder buffer
k = bestverts[j];
vertexorder[numorder++] = k;

// emit s/t coords into the commands stream
s = stverts[k].s;
t = stverts[k].t;
if (!triangles[besttris[0]].facesfront && stverts[k].onseam)
s += pheader->skinwidth / 2; // on back side
s = (s + 0.5) / pheader->skinwidth;
t = (t + 0.5) / pheader->skinheight;

// *(float *)&commands[numcommands++] = s;
// *(float *)&commands[numcommands++] = t;
// NOTE: 4 == sizeof(int)
// == sizeof(float)
memcpy (&tmp, &s, 4);
commands[numcommands++] = tmp;
memcpy (&tmp, &t, 4);
commands[numcommands++] = tmp;
gl_model.c - Quakespasm wrong dir detection and lots of (typeing *) ... worth a thorough examination.
gl_model.h - MH 128 dlights
gl_refrag.c - usual
gl_rlight.c - MH 128 dlights
gl_rmain.c - "QuakeSpasm z-fighting fix". Don't try viewmodel during envmap. + don't in showtris.
gl_rmisc.c - envmap is gone though? r_nolerplist fix.
gl_screen.c -SCR_CalcRefdef ... vid.recalc_refdef = 0; <--- moved down a bit?? Scr_ConWidth --> vid.recalc_refdef = 1;

Modal message has Sys_Sleep(16); :!: :!: :!: Great idea, really. Save CPU while Quake isn't doing anything.

SCR_UpdateScreen doesn't check oldfov == etc etc. Code moved. Good idea.

gl_sky.c - nothing
gl_texmgr.c -
Sbar_Changed (); //sbar graphics need to be redrawn with new filter mode
//FIXME: warpimages need to be redrawn, too.
gl_texmgr.h - "TEXPREF_NEAREST and TEXPREF_LINEAR aren't supposed to be ORed with TEX_MIPMAP" and size_t --> uintptr_t

Texnum is GLuint now.

gl_vidsdl.c - Read early. Gamma stuff.
gl_warp.c - usual
glquake.h - Egads! Yeah those arrays kinda need extern before them. :!: :!: :!:
host.c - Host_Callback_Notify. cfg_unbindall is a cvar that if on pre-appends an "unbindall" to a written config file. Host frame removes Sys_SendKeyEvents which SDL is getting elsewhere. BGM_Update in frame. Dedicated doesn't init keys or console (which aren't needed in dedicated) Several client inits have been moved so dedicated doesn't do them. Shutdown likewise reflects this.

Check quake.rc on this piece of code .... :?: :?:
if (cls.state == ca_dedicated)
{
Cbuf_AddText ("exec autoexec.cfg\n");
Cbuf_AddText ("stuffcmds");
Cbuf_Execute ();
if (!sv.active)
Cbuf_AddText ("map start\n");
}
host_cmd.c - Hunk_Strdup --- interesting. Host_Version moved out of here. NET_QSocketGetTime. "games" command

I'm not seeing why this is right ... :!: :!: :!: :!:
Host_Changelevel_f
if (cls.state != ca_dedicated)
IN_Activate(); // -- S.A.
Changing a level doesn't have anything to do with input activation. As a client or a server, the app might not even be the active one (and why would input be deactivated?). I wonder what this was trying to address ... not very important, I've never noticed any problems with Quakespasm but ... hmmmm ....

image.c - usual
image.h - nothing
in_sdl.c - 5 mouse buttons, OS X acceleration hack 8) 8) , IN_ACTIVATE/IN_DEACTIVATE, SDL key handling
input.h - nothing
keys.c - history
keys.h - 5 mouse buttons, changed keypad names a little
mathlib.c - void BOPS_Error (void) __attribute__((__noreturn__));
mathlib.h - As follows:

Code: Select all

#define	nanmask		(255 << 23)	/* 7F800000 */
#if 0	/* macro is violating strict aliasing rules */
#define	IS_NAN(x)	(((*(int *) (char *) &x) & nanmask) == nanmask)
#else
static inline int IS_NAN (float x) {
	union { float f; int i; } num;
	num.f = x;
	return ((num.i & nanmask) == nanmask);
}
#endif

Code: Select all

// QuakeSpasm: To avoid strict aliasing violations, use a float/int union instead of type punning.
#define VectorNormalizeFast(_v)\
{\
	union { float f; int i; } _y, _number;\
	_number.f = DotProduct(_v, _v);\
	if (_number.f != 0.0)\
	{\
		_y.i = 0x5f3759df - (_number.i >> 1);\
		_y.f = _y.f * (1.5f - (_number.f * 0.5f * _y.f * _y.f));\
		VectorScale(_v, _y.f, _v);\
	}\
}
menu.c - serial and modem gone. Quakespasm menu changes. Added "impulse 12" to controls. NET_SlistPrintServer / NET_SlistPrintServerName
menu.h - some externs plus m_keys_bind_grab + extern enum m_state_e m_state; + extern enum m_state_e m_return_state;
modelgen.h - nothing
net.h - Overhaul!!!!! :!:
net_dgrm.c - ip:port .... (Q: IN_Deactivate in datagram connect?)
net_dgrm.h - nothing
net_loop.c - A Linuxy #include
net_loop.h - nthogin
net_main.c - usual
net_sdl.c - touchups
net_sdlnet.c - usual + comments
net_sdlnet.h - nothing
net_udp.c - far more organized
net_udp.h - sys_socket_t
net_win.c - usual
net_wins.c - Some restructure.
net_wins.h - usual
pl_linux.c - Doesn't have clipboard or error dialog. Has setwindow icon.
pl_osx.m - Similar to pl_win.c
pl_win.c - PL_GetClipboardData with max size of 256. Notice it doesn't purge whitespace, tabs, newlines. Z_Mallocs it.
platform.h - PL_GetClipboardData (nice) + PL_ErrorDialog (nice)
pr_cmds.c -
PF_traceline "/* FIXME FIXME FIXME: Why do we hit this with certain progs.dat ?? */"

Code: Select all

static void PF_traceline (void)
{
	float	*v1, *v2;
	trace_t	trace;
	int	nomonsters;
	edict_t	*ent;

	v1 = G_VECTOR(OFS_PARM0);
	v2 = G_VECTOR(OFS_PARM1);
	nomonsters = G_FLOAT(OFS_PARM2);
	ent = G_EDICT(OFS_PARM3);

	/* FIXME FIXME FIXME: Why do we hit this with certain progs.dat ?? */
	if (developer.value) {
	  if (IS_NAN(v1[0]) || IS_NAN(v1[1]) || IS_NAN(v1[2]) ||
	      IS_NAN(v2[0]) || IS_NAN(v2[1]) || IS_NAN(v2[2])) {
	   Host_Error("NAN in traceline:\nv1(%f %f %f) v2(%f %f %f)\nentity %d",
		      v1[0], v1[1], v1[2], v2[0], v2[1], v2[2], NUM_FOR_EDICT(ent));
	  }
	} else {
	  if (IS_NAN(v1[0]) || IS_NAN(v1[1]) || IS_NAN(v1[2]))
		v1[0] = v1[1] = v1[2] = 0;
	  if (IS_NAN(v2[0]) || IS_NAN(v2[1]) || IS_NAN(v2[2]))
		v2[0] = v2[1] = v2[2] = 0;
	}
	trace = SV_Move (v1, vec3_origin, vec3_origin, v2, nomonsters, ent);

	pr_global_struct->trace_allsolid = trace.allsolid;
	pr_global_struct->trace_startsolid = trace.startsolid;
	pr_global_struct->trace_fraction = trace.fraction;
	pr_global_struct->trace_inwater = trace.inwater;
	pr_global_struct->trace_inopen = trace.inopen;
	VectorCopy (trace.endpos, pr_global_struct->trace_endpos);
	VectorCopy (trace.plane.normal, pr_global_struct->trace_plane_normal);
	pr_global_struct->trace_plane_dist =  trace.plane.dist;
	if (trace.ent)
		pr_global_struct->trace_ent = EDICT_TO_PROG(trace.ent);
	else
		pr_global_struct->trace_ent = EDICT_TO_PROG(sv.edicts);
}


pr_comp.h - ev_bad added
pr_edict.c - usual.
pr_exec.c - usual
progdefs.h - usual
progs.h - void PR_RunError (const char *error, ...) __attribute__((__format__(__printf__,1,2), __noreturn__));
protocol.h - #define DEFAULT_SOUND_PACKET_VOLUME 255 and #define DEFAULT_SOUND_PACKET_ATTENUATION 1.0 (relocation?)

quakedef.h - MAX_OSPATH increased from 128 to 256. I wasn't aware Fitz wasn't using 256 already which could be a real problem with long paths.
r_alias.c - nothing
r_brush.c - uintptr_t in a couple of places. gl_zfix, mh 128 dlights,
r_part.c - usual
r_sprite.c - usual
r_world.c - R_MarkSurfaces ... vis_changed = false; at time of r_visframecount++
render.h - qmodel_t thing
resource.h - nothing. This file is living in "Quake" but is a Windows only file. :!: Or does makefile need it here?
sbar.c - Quakespasm customized scoreboard. Plus the health <0 fix I see.
sbar.h - nothing
screen.h - cvar_t scr_scale; and CANVAS_INVALID
server.h - usual
snd_dma.c - Many touchups.
snd_mem.c - S_LoadSound refuses sound that isn't 8-bit or 16-bit width.
snd_mix.c - PAINTBUFFER_SIZE larger. Amiga AHI. if (s_rawend < paintedtime).
snd_sdl.c - AUDIO_S8 sound format
spritegn.h - nothing
sv_main.c - NET_QSocketGetAddressString(client->netconnection) instead of client->netconnection->address :?:
1. change of cls.state != ca_dedicated to isDedicated.

sv_phys.c - sv_freezenonclients cvar
sv_user.c - usual
sys.h - usual
vid.h - changed some data types for the better.
view.c - Added if (lookspring.value) before V_StartPitchDrift ();
view.h - nothing
wad.c - W_LoadWadFile loading changes which doesn't change anything material.
wad.h - nthoing
world.c - Whiteroom links fix, maybe. #define DIST_EPSILON (0.03125) to a number that can be represented in floating point easily. (impact if any? wasn't this 0.1?) :?:
world.h - nothing
zone.c - z_strdup. Zone to 384 kb
zone.h - nothing except noted above
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quakespasm 0.85.1 vs. 0.85.8

Post by Baker »

Just want to say, this is so entirely cleaned-up in source code. I don't mean "looks nice". I mean, function prototypes where they should go. All the network files have been made "right". Almost every proper cleanup angle you could think of (gcc warnings, no externs except for the headers almost entirely, string safety, const char* where that should be, #define XYZ type definitions gone in favor of "sizeof(blah)/sizeof(blah[0])", everything "filed" in the right header) and it actually changes no functionality in doing so. Unloved source files fixed up and modernized. Uses the right way to multiplatform everything.

And the functionality is unchanged, a true cleanup.

This had to be about 1000 hours of cleanups. And the quality and expertise of the cleanups are astonishing and almost robotically correct in precision and full understanding of all the C and platforms "rules".
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
szo
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

Re: Quakespasm 0.85.1 vs. 0.85.8

Post by szo »

Baker wrote:Just want to say, this is so entirely cleaned-up in source code. I don't mean "looks nice". I mean, function prototypes where they should go. All the network files have been made "right". Almost every proper cleanup angle you could think of (gcc warnings, no externs except for the headers almost entirely, string safety, const char* where that should be, #define XYZ type definitions gone in favor of "sizeof(blah)/sizeof(blah[0])", everything "filed" in the right header) and it actually changes no functionality in doing so. Unloved source files fixed up and modernized. Uses the right way to multiplatform everything.

And the functionality is unchanged, a true cleanup.

This had to be about 1000 hours of cleanups. And the quality and expertise of the cleanups are astonishing and almost robotically correct in precision and full understanding of all the C and platforms "rules".
Thanks for taking time to read through the changes. As for some of the cleanups being done almost entirely, well, heh, I am just a human and get tired or bored sometimes, and if I'd try more, I am sure that I'd find many other places to clean too.
Baker wrote:gl_draw.c - QuakeSpasm -- menu scrolling. Really? :!: I've never noticed it. Maybe for small screen resolutions? I see 2 pics in memory. CANVAS_INVALID instead of -1, so enum changed no doubt.
Options menu scrolling is needed because if 2D elements scaling is maxed to emulate, say 320x200, we would be writing offscreen. The canvas enum is not really changed, the first value is still 0. CANVAS_INVALID there is to satisfy C++ compilers when a canvas returning funstion wants to return -1.
Baker wrote:gl_mesh.c - Something in BuildTris. Hmmmm. Copying a float into an int memory space. Then assigning an int to this memcpy of a float??? This doesn't sound right off hand, but it might not be wrong for reasons I don't understand yet.
The original code does the same thing by typecast assignment, but that violates pointer aliasing rules and not guaranteed to compile correctly by new compilers at high optimization levels. That particular solution uses memcpy to work around that and the result is precisely the same.
Baker wrote:pr_cmds.c - PF_traceline "/* FIXME FIXME FIXME: Why do we hit this with certain progs.dat ??
http://celephais.net/board/view_thread. ... &start=185 has some insight about this, and our code actually doesn't seem to be at fault but the qc in question is.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quakespasm 0.85.1 vs. 0.85.8

Post by Baker »

szo wrote: As for some of the cleanups being done almost entirely, well, heh, I am just a human and get tired or bored sometimes ...
I'm still in disbelief that anyone could do it. And few people could. Aside from LordHavoc or Spike or maybe Tonik (ZQuake / ezQuake), I don't think anyone else could do it right --- so much precise knowledge and experience is required. Windows, Linux, Mac, 64 bit, 32 bit, stdint, working around 30+ compiler and platform limitations, differing headers, dirent, stdint, procaddress, varying opengl headers and on and on and on (while knowing what everything is doing in Quake too as to make sure it operates correctly too).

I don't know how you found the stamina to attack that 25-headed Hydra. :P But hats off doing so!

[While examining it all, I probably had to do 25 different Google queries to understand some of the more intricate nuanced changes. Some remain outside my level of experience --- for instance, I'm still working on "getting" the NAN fix --- and some were cool discoveries to me (gcc's printf hints :mrgreen: ) Recognizing art is not the same as being able to create it ;) ]

A Quakespasm thought: Don't fear the MH dynamic light speed-up fix ---- all it is doing is uploading all the lightmaps before the rendering phase before where it submits drawing requests (instead of drawing some -- uploading a changed lightmap --- drawing some more --- uploading another changed lightmap texture, etc.) . On Windows with some of the video card drivers it makes a massive speed difference (increases fps maybe 5x) for gl_flashblend 0. Macs will never be affected for reasons I once knew (something to do with Apple's way of doing OpenGL which I no longer remember) and I don't know about Linux OpenGL drivers.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Quakespasm 0.85.1 vs. 0.85.8

Post by Spike »

the issue with dynamic lightmap updates is that you end up with something like:
1 draw surface
2 update lightmap
3 draw surface
4 update lightmap
etc.

if the update lightmap step is implemented as:
1 wait for texture to no longer be in use
2 replace the subregion
3 return to caller
then you're waiting for each and every draw call individually.
note that if the driver ignores order coherancy (3dfx...) then there's no massive issue here. but drivers that do things properly either need to wait as above, or copy the entire updated subregion to some thread in order to update in sync with the graphics card. if the card has no support for that then there's no choice but to wait. alternatively, the driver can orphan the existing texture such that the hardware sees a completely new texture allowing it to destroy the orphaned texture when its finally no longer active. but that's the sort of optimisations nvidia would do, and not anyone else.
you have the same issues in opengles, except more extreeme.

so animating your lightstyles and updating them in bulk at the start of the frame avoids the excess memcpys or waits, and you get significantly higher framerates in such situations.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quakespasm 0.85.1 vs. 0.85.8

Post by Baker »

Spike wrote:so animating your lightstyles and updating them in bulk at the start of the frame avoids the excess memcpys or waits, and you get significantly higher framerates in such situations.
Just for thread explanation clarity for anyone reading, this is exactly what the MH dynamic light speedup does.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
szo
Posts: 132
Joined: Mon Dec 06, 2010 4:42 pm

Re: Quakespasm 0.85.1 vs. 0.85.8

Post by szo »

Baker wrote:[...] A Quakespasm thought: Don't fear the MH dynamic light speed-up fix ---- all it is doing is uploading all the lightmaps before the rendering phase before where it submits drawing requests (instead of drawing some -- uploading a changed lightmap --- drawing some more --- uploading another changed lightmap texture, etc.) .
I might try to implement that. Note, though, I did try the patch you posted on the func boards once, and it seemed broken, at least with ne_ruins where the lighting seemed incorrect at several places. You possibly missed something in your patch, or mh's original was already broken, don't know. (no I don't have a screenshot, and no I didn't try investigating.)
Baker wrote:On Windows with some of the video card drivers it makes a massive speed difference (increases fps maybe 5x) for gl_flashblend 0. Macs will never be affected for reasons I once knew. (something to do with Apple's way of doing OpenGL which I no longer remember) and I don't know about Linux OpenGL drivers.
Tried what I said above on x86-linux with an ATI (Radeon HD 77xx - "catalyst-13.1" driver), didn't see an earth shattering difference (was something like 430 fps vs. 440fps, or something like that, can't remember precisely.)
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quakespasm 0.85.1 vs. 0.85.8

Post by Baker »

I initially confused Quakespasn's handling of dynamic light for possible poor performance of the Win64 build.
I did a timedemo with the Win64 bit build out of curiosity and it did about 40 fps for demo1.dem.
I get about 180 to 200 fps doing timedemo demo1 for other FitzQuake engines.
I set gl_flashblend 1 and got 200 fps.
Because I didn't understand why my timedemo performance was bad with the Win64 build, but good on my Mac.

My Windows laptop uses an Intel Integrated Media and is a Compaq purchased last year. Both very common for Windows laptops. Keep in mind that FitzQuake defaults to gl_flashblend 1 but Quakespasn gl_flashblend 0. So not only does Quakespasm handle dynamic lighting on those machines poorly, but also defaults it to on too!

I know how it is difficult to handle issues not experienced firsthand, you could probably ask around and find another Windows user using Intel Integrated Media. Ask them to do "host_maxfps 999; timedemo demo1" with vsync off. Besides, independent verification of the solution of an issue is always most satisfying.
mh wrote:<This is MH's screenshot showing 8 fps with gl_flashblend 0 and FitzQuake 0.85 ... not mine ... Image

Before: 8 FPS
After: 260 FPS

Use your favourite diff tool to figure out what was changed; it's very little really.

You're welcome.
http://forums.inside3d.com/viewtopic.php?p=34431#34431
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quakespasm 0.85.1 vs. 0.85.8

Post by Baker »

szo wrote:Note, though, I did try the patch you posted on the func boards once, and it seemed broken, at least with ne_ruins where the lighting seemed incorrect at several places. You possibly missed something in your patch, or mh's original was already broken, don't know. (no I don't have a screenshot, and no I didn't try investigating.)
Mark V initially had a couple of annoying lighting issues, but it wasn't related to this but something I did with shadows (and missed a line of code, twice) :( . That's been solved quite a while now, though but sure I can imagine the lighting fix being judged by the lighting bug Mark V had, even if wasn't related.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quakespasm 0.85.1 vs. 0.85.8

Post by Baker »

WinQuake anti-cruft ... this stuff is not used in GLQuake.

Easy to remove:
File = glquake.h ....

#define SKYSHIFT 7
#define SKYSIZE (1 << SKYSHIFT)
#define SKYMASK (SKYSIZE - 1)

surfcache_t
drawsurf_t

r_cache_thrash

render.h

// surface cache related
//
extern int reinit_surfcache; // if 1, surface cache is currently empty and
extern qboolean r_cache_thrash; // set if thrashing the surface cache

int D_SurfaceCacheForRes (int width, int height);
void D_FlushCaches (void);
void D_DeleteSurfaceCache (void);
void D_InitCaches (void *buffer, int size);
void R_SetVrect (vrect_t *pvrect, vrect_t *pvrectin, int lineadj);

I might edit this and add more.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Post Reply