Hosting and domain costs until October 2024 have been generously sponsored by dumptruck_ds. Thank you!
Editing Talk:Engine Limits
From Quake Wiki
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
(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. | (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) | (metlslime says) | ||
* might be better with a row for each limit and a column for each engine | * might be better with a row for each limit and a column for each engine | ||
Line 10: | Line 10: | ||
* 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. | * 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. | * the categories seem pretty arbitrary, i'll try to suggest better ones later. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |