Talk:Engine Limits

(mh sez:) - should we identify which limits are a result of e.g. the Q1 BSP format. I'm thinking stuff like faces and marksurfaces, where there is a limit of 64k owing to the use of unsigned shorts in the BSP, and increasing this limit would require a BSP format change.

(lordhavoc sez:) - yes I think we should, perhaps by putting F in the entries where they are hitting format limits, for example 65530 F being the hard limit for clipnodes (however Quake used signed shorts to interpret this, limiting it to 32768), darkplaces interprets anything over the numclipnodes as being a contents value (so with 6 standard contents values that exist in BSP files... 65536-6 = 65530). Network limits are another matter, because I could say 255 F but a protocol upgrade could increase that (by sending larger colormap values on entities, and increasing the space in the signon message for maxclients), similarly the Q1 protocol does not support more than 8192 entities without changes to the sound encoding, so the fact darkplaces supports 32768 required changes in protocol. I think we should stick to only labeling format details this way.

(mh) Probably easier if we stick to protocol 15 as a baseline and flag any increase that implies a protocol change (it would also help to prevent people from blindly increasing such a limit by alerting them to the fact that there are consequences of doing so).

(metlslime says) - might be better with a row for each limit and a column for each engine - should we be explicit about the differences between winquake and glquake (i.e. not just saying 256/512 but saying 256(win)/512(gl) or something?) - recommend using asterisks in the traditional way, to indicate footnotes: i.e. *depends on heapsize **limited by bsp format ***requires new protocol etc. and avoid a general "please see readme" when we can give a specific note instead. - the categories seem pretty arbitrary, i'll try to suggest better ones later.