Quake Standards Base discussion

[Urre]

Hello!

This thread is meant for discussing, commenting and arguing about the current features in the recently started Quake Standards Base project. This thread is not meant for discussing new features, only the existing ones, concerning changing them somehow. Feature-requests are kept in the .

entry on the Quakery wiki (not finalized!)

[Urre]

[Baker]

[Urre]

[Urre]

The Client/Server stuff I don't follow almost at all really, someone has to explain what ~ means in these cases, and how the formats of things can differ so much. How do I measure the Packet size stuff for example?

What are "WinQ bmodel edges" and "WinQ bmodel vertices", how can many engines have N/A on them?

[Baker]

[mh]

Interesting stuff. I can offer some guidelines on choices I made for DirectQ, and may even bump some of my current limits where possible for my next release.

There are also a few of the limits you've chosen which I'm going to argue with, so advance warning is issued.

BSP

Where possible I use completely dynamic allocation so the only limits are heapsize (which doesn't actually exist in DirectQ) and the BSP format.

My max surface extents is dynamically set based on the max texture size your 3D card supports (you also need to make your blocklights dynamic for this, as well as support variable lightmap sizes). For a 3DFX it evaluates to 6640, for a low end modern card it's 32752, for a typical modern card it's 65520.

My max dimensions is +/- 30000000000000000000000000000000000000 so I think I win there. This is only achievable with my protocol 10003 which just sends the original floats direct; other protocols will fall back to lower maximums.

MDL

I don't actually use mesh strips or commands any more, so these limits don't apply.

I have a max tris of 21845 because I can draw an entire alias model with one API call; the limit comes from the max number of vertexes I can submit in that call. It wouldn't be too difficult to increase this to infinite (or at least the max supported by the format).

Client/Server

I just copied what aguirRe had and bumped the stack size a little.

Graphics

The only one where I don't pass is temporary entities - this is utterly trivial to bump. (clickety-clickety-click) - OK, it's now 174,760. (clickety-clickety-click) - oh look, it's back to where it was!

I'd query why you're setting the standards base for this so high actually - they're only used for lightning bolts and grapple beams after all. 1024 would be more like it (especially as each temp ent is also a visible edict, and you only have 4096 there).

Misc

Anything above 8192 edicts requires a protocol change so this standard really should be 8192. DirectQ's entry in there is a little out of date, it's hovering around the 30,000 mark now.

Previous versions of the engine didn't use efrags at all so the limit doesn't apply. The one I am working now does again, but it's effectively unlimited. Likewise I don't use file handles at all so that limit doesn't apply either.

Be careful by the way of the interrelationship between max efrags and max static entities; any increase in max static entities requires an increase in efrags too, on about - I think - a 1 to 2 scale.

[Urre]

Thanks for clearing some of these things out guys. I only realised after Bakers post that I had not thought about what affects the network protocol and what doesn't. It'd be great if someone could add a sign of some sort to each column which does affect the network protocol, so we can keep track of this. Also while you're at it, change the QSB value in the given column to be the maximum allowed within the protocol limits, as I don't actually know these things.

mh: this thread is meant for criticizing the standard, to make sure we reach something we can all agree on

So, to anyone who frowns at any part of the suggestions I make in the standard, please speak up! We want open discussion, not ignoring things because it didn't fit your tastes

[Baker]

[frag.machine]

I suggest to add this to the list, if isn't already there:

- .scale support, so you can enlarge/shrink entities (and automatic recalculation of bound boxes would be a good bonus, too). This feature exists in TomazQuake, don't know about others engines;
- colormaps for monsters - implemented in DP;
- at least one more hull(*) for crouching player collision tests, I don't know if any engine currently implements this, but Half Life has it, and I think it should be mandatory if HL1 map support becomes part of QSB.

(*)Speaking about hulls: can't we get rid of this and just do collision check against the BSP geometry directly ?

[Urre]

[Team Xlink]

[Sajt]

[mh]

[Baker]