...not to mention that lightmaps require 16MB...

To be honest, scrimping and saving on zone memory in that kind of situation is like fretting over a pinhole in a leaky bucket when there's a great big gaping wide rent on the other side of it. 

ok, so it's safe to just suggest to people playing my map to use, say, -zone 2048 just to be safe? 

The zone memory system can be replaced outright by standard malloc/free, and doing so shifts the technical burden from the player (where it shouldn't belong) back to the developer (where it should). I think there's one potential crash condition in the command processor with this, but can't remember specific details right now. It's easily worked around anyway.

True, memory fragmentation might become an issue, but the Big Dirty Secret of zone memory is that it is already prone to fragmentation as is (and actually contains code to deal with it).

One has to remember that Quake's memory system was developed under the constraints of running on a machine with 8 MB RAM and no virtual address space. A lot of the decisions made with it may have been valid for those constraints, but they're not so valid - and indeed limiting - today. 

what exactly does the engine use zone memory for anyway? it already has the -heapsize memory. 

as far as i know, the 'zone' command somewhat related with a large/messy .cfg files 

-zone

Type: Parameter

Syntax: game.exe -zone (bytes)

Description: Specify the amount of memory in bytes to allocate to holding dynamic information such as aliases.

Note: You will need to specify a value such as 512 if you experience game crashes because of too many aliases being loaded into memory. It is not necessary specify any larger value, since this value will work suffice.

Example: game.exe -zone 512 

Key bindings, the command buffer (used for every time you press a key in-game, includes cfg files which go through the same system), cvar strings, aliases, and certain types of file loading. -heapsize (known as "the hunk" in the engine) is used for loading models, maps and other big things. A part of this "hunk memory" is also used for keeping permanent copies of a part of MDL files so that they don't need to be reloaded between maps.

This isn't the only memory that Quake uses. GLQuake in particular uses several fairly large fixed-size buffers for lightmaps and texture loading (about 8 MB total; Fitz uses more for lightmaps but less for textures), and all versions of Quake use other memory buffers outside of this system for console prints, network traffic (also applies to SP games which go through the same code; will use more if large map support is enabled, and also allocates for up to 4 players as standard, even if you never run an MP game) and other bits and bobs.

OpenGL itself will keep backup copies of all textures in system memory which are used to recreate the hardware copies if you Alt-Tab away, and which were also used for texture swapping in the Bad Old Days of low video RAM. The framebuffer itself may even be backed up by system memory; I haven't found anything to indicate either way.

Windows Task Manager shows a standard unmodified GLQuake with no command-line params as using about 66 MB of memory on my machine, and I doubt if it's much different on yours.

So in other words the amount of memory specified by -zone (or even by -heapsize) is really mickey mouse stuff compared to the overall memory usage of Quake. Being conservative about them seems to be a waste of time and effort these days, in particular when more or less everybody is guaranteed to have 256 MB as an absolute bare minimum, and 95% of people will have 1 GB or more. 

wow, there's even more going on than i realized...

thanks for the clarification, i'll just go ahead and start suggesting a 2mb zone or something from now on. :) 

I'm in the process of porting protocol 666 into QuakeForge, and I ran into this (in SV_WriteEntitiesToClient):

//johnfitz -- don't send model>255 entities if protocol is 15
if (sv_protocol == PROTOCOL_NETQUAKE && (int)ent->v.modelindex & 0xFF00)
continue;

Shouldn't that be sv.protocol? 

sv_protocol is the cvar, IIRC. 

> Shouldn't that be sv.protocol?

I suspect that you're right. sv_protocol is the command whereas sv.protocol is the currently active protocol which only gets updated when a new server is spawned. Using sv_protocol here would mean that server messages would go all wacko if the protocol was changed while a server was running. 

that's a mistake. I'm not sure what happens if you compare the cvar directly rather than cvar.value ... it's a struct which means are you comparing the first element of the struct? 

.. is not a cvar, it's a global associated with the sv_protocol console command which sv.protocol is assigned to at server creation. So the comparison in SV_WriteEntitiesToClient() really needs sv.protocol and not sv_protocol. 

Yeah it's been a little while since i looked at the code. I guess it works as written but is unsafe. Should be sv.protocol. 

Ha ha ;>

Nice to see QuakeForge is getting updated. 

Due to a series of unfortunate events, QF more or less went into hibernation for a few years, though I kept poking at it occasionally (there is no year with 0 commits). I've been fairly busing hacking on things this past year, and lately, the maps on quaddicted have given me some real motivation :). git helps a lot, too (easy branching and stash).

I'm glad to have been of help. 

When running Fitz 0.85 with -quoth, it's impossible to switch to the id1 gamedir with game id1, because the engine thinks that the Quoth dir is the id1 dir, and thus nothing changes. 

If it weren't like this, certain releases wouldn't work they way they do. Those that come with an extra pak/mod dir but still require quoth as a base. 

I'm just saying that typing 'game id1' in the console should probably revert that behavior. 

that was implemented by request because BJP quake has it. ideally there would be ways to turn that stuff on/off in the console. (maybe multiple gamedirs like darkplaces would do it.) But to get the alternate hipnotic/rogue statusbars, you'd also need special variables for those. 

i was really happy you added the -quoth thing, but i guess it does make more sense for a more generalized multimod loading order thing.
maybe there'd be a way to detect what kind of hud layout to use based on what the gfx.wad contains? or are they all the same? 

if (hipnotic || quoth)

???? 

it would be awesome if it wasn't determined by folder name of the mod so you can make other mods that use the hud without having to get people to do a -hipnotic -game mymod.

checking quickly, the gfx.wad in hipnotic has all those extra weapon icons and id1 doesn't, so they do use different gfx.wad files. is that possible then, to look at what entries are in the wad file and then use an appropriate hud? 

Hey, I have a widescreen monitor (1920x1080) and changed my resolution in FitzQuake accordingly, and it works fine, except the UI (HUD, console, main menu) is terribly tiny. Are there any commands to prevent them from being downsized while maintaining the proper resolution? 

scr_conscale
scr_menuscale
scr_sbarscale


pretty self-explanatory... '1' is the default value, '2' doubles the size and so on. i find 1.5 a nice value