Raising limits without raising hardware requirements

[mankrip]

Simple question, which limits can be increased without raising Quake's hardware requirements, specially its memory consumption?

On the Dreamcast, for example, it isn't possible to allocate more than 10 megabytes for the heap, so this is a critical issue. I'd like to increase some limits, but not at the cost of dropping support for low-end hardware.

[Spike]

QC limits can be freely extended in such a way (with the exception of the qc stack).
bsp limits can be extended, as these should be allocated dynamically and thus consume only what is needed anyway (exception: vis (so num leafs) has a few static buffers around).
efrags can be killed entirely (thus increasing the limit to infinity), there's no real need for them, and the memory saved can be used for other things.

supposedly.

[mh]

Static entities can go to infinite while you're at it; there's currently a static array of 128 (I think) for storing them, so eliminate the array and just alloc them on the hunk as required. This is also going to reduce memory usage for maps which have less than 128 statics - double win.

Temp entities and beams can also go to infinite, but they're a bit more fiddly.

cl_entities can change from entity_t cl_entities[MAX_EDICTS]; to entity_t *cl_entities[MAX_EDICTS]; with dynamic allocation on the hunk. You'll rarely need the full MAX_EDICTS on the client so this can save quite a bit. Server-side if you want to implement similar on sv.edicts you'll need to do quite a bit more work but it's not impossible. You can bump MAX_EDICTS quite a bit then.