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.

(spirit says)

For footnotes there is a nice wiki way to do them: http://en.wikipedia.org/wiki/Wikipedia:Footnotes

You can append your username by writing 3-4 tildes by the way. Also rather use the + sign at the top, discussion is easier that way. Spirit 10:51, 26 September 2009 (CDT)

---

Baker:

Certain limits are important for some models to work and in WinQuake for the maps to render well. The default Quake zone allocation is terrible and should be at least 1 MB. For most of the rest of the limits except for edicts and the texture/OpenGL type of limits, isn't it really just breaking Quake compatibility? Like how half the engines demos can't even be played in any other engine or how most of these engines can't connect to each other on a LAN with their default protocol. It does seem that DirectQ should be able to play aguirReQuake demos and vice versa. Slightly lobbying against "Tower of Babel" problem.

By the way, DarkPlaces completely removed Efrags ages ago so really the correct answer is "N/A". ZQuake, likewise, does not use Efrags nor FTE.

---

(mh) - yeah, DirectQ can play aguirReQuake demos quite well as it supports the same protocols. You can also use the sv_protocol 15 command in both DirectQ and aguirReQuake to switch back to a compatible protocol for generating demos that are usable in other engines, as well as if you want to use either engine as a server. Also, both engines let the server fully control the protocol, so they can quite happily connect to any protocol 15 server without any jiggerypokery required by the player.

actually as i recall, even with sv_protocol 15, aguirRe's engines will send nehahra-style U_TRANS data for entities with alpha, which will crash a stock engine. Metlslime 04:56, 18 January 2010 (CST)

negke: Just wanted to point out that "aguirReQuake" isn't a good name, because hardly anyone outside Func/Inside3d knows BJP by this nick. "Bengt Jardrup's enhanced engines," while being overly long, seems more appropriate for a wider audience.