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 original thread.

Quake Standards Base entry on the Quakery wiki (not finalized!)

[Urre]

So, I've really just started making stuff up based on the info already there, to be honest. I'm having slight trouble deciding where to draw the line with some limits. I'm honestly quite puzzled why there are such differencies in the limits between engines, why not just go for maximum possible when you're at it, changing stuff, anyway? Am I missing something?

I tried to be logical about things, picking either the maximum available limit (ignoring "unlimited", as I figure that takes a different kind of programming) or some middle-range value where appropriate.

I'd really like to know your, the engine devs, thoughts on the limits I've picked, and suggest better ones if applicable. I'd really like to max all of them out, as long as there's nothing logical stopping this reasoning, such as memory usage? I honestly don't know.

Some specific points:

• What to do about Vis/Light data on the BSP limits? Is it best kept with heapsize for maximum compatibility? I'd honestly prefer that heapsize disappeared, the user shouldn't need to worry about commandline parameters such as this.

Also, like I point out on the Engine Limits page, in some cases I just couldn't figure out wether an engine reached the limit or not, so please alter it if so.

[Baker]

Perhaps the best approach would be 3 categories: modding features (Extensions), media supported and limits supported.

Modding features: MOVETYPE_FOLLOW, Alpha submodel support, colormod, fog, additive, origin brush support, sound channels, etc.

Media support: MD2? MD3? External lits. External textures. External Skybox. Map types supported (HL bsp, etc.), Stereo sound? OGG support or mp3 support.

Limits support: map limits, model triangles, etc.

One opinion ....

/Thanks for taking initiative with all of this, btw

[Urre]

The plan is two "categories", engine limits as one category, and the rest as another. I originally meant to have it all in one page, but it felt unnecessary to copy the entire table of engine limits which was already available, so I divided that off into the already existing Engine Limits article. It fits well in there, acting as an "engine" in the list

[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]

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?

Packet overflow occurs in extreme action situations with standard Quake like with Once Upon Atrocity fighting the dragon at the end or Fat Controller's Ontranto at the end fighting 40 bad guys at once.

These defines in standard Quake can be modified to make that problem go away (but it breaks the standard protocol limits, both for multiplayer and standard demos if those limits are exceeded):

#define MAX_MSGLEN 16384 //aard: was 8000 max length of a reliable message
#define MAX_DATAGRAM 16384 //aard: was 1024 // max length of unreliable message

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

Only applies to software renders. GL engines don't have that or need it.

MAX_BMODEL_EDGES / MAX_BMODEL_VERTS

In WinQuake, the standard values of those will cause a map with a lot of edges and surfaces in sight to have gray areas (where nothing was drawn, equivalent of gl_clearcolor). aguriRe's WinQuake was cured of that issue, for instance, and instead of stopping at drawing X number of edges/surfaces he raised it significantly in the cvars. A potential performance problem on slower computers, but this isn't 1996 -- still on certain gigantic new age maps, the software render can get a little bit slow in places.

Note: Best attempt explanation. I don't claim to be Mr. BSP or Mr. Software Renderer, this my best attempt at providing info since I long ago borrowed aguirRe's WinQuake limit changes for software map rendering. Explanation subject to correction or expansion by someone else.

Cvar_SetValue ("r_maxedges", (float)100000); //NUMSTACKEDGES
Cvar_SetValue ("r_maxsurfs", (float)100000); //NUMSTACKSURFACES

vs. Standard WinQuake

Cvar_SetValue ("r_maxedges", (float)NUMSTACKEDGES);
Cvar_SetValue ("r_maxsurfs", (float)NUMSTACKSURFACES);

Also:

#define NUMSTACKEDGES 2400
#define MINEDGES NUMSTACKEDGES
#define NUMSTACKSURFACES 800
#define MINSURFACES NUMSTACKSURFACES
#define MAXSPANS 3000

An example of a shot from the Undergate map I made where if viewed in WinQuake you'd likely see ugly gray areas if you walked in the middle of the map.

[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]

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

I want modding features. Extended map limits are "ok", but they won't interest a total conversion author.

aguirRe's engine has supported super sized Quake maps for a long time. I'm not interested in more of the same in a bigger package in the form of a larger brown map, I'm interested in enhanced standards for a more vibrant world.

I want to see more tools in a modder's pocket.

Additive, alpha, vwep, movetype_follow, colormod, Frik_file, CSQC extensions, more colors in the bsp, rotating doors via any means necessary, better effects (motion blurs, cool smoke and flames like in Qrack).

[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]

Like I said, keep discussion about what features to include in the other thread, this could get messy otherwise. I'd really like it if a moderator could move those posts to the other thread, seeing as they'll probably get replies as well.

Baker: modding features are coming, I've just started with listing limit upgrades first. Don't worry.

[Team Xlink]

I think there should be two types of the standards.

Quake Standards Client
Quake Standards Server/Dedicated Server

[Sajt]

These defines in standard Quake can be modified to make that problem go away (but it breaks the standard protocol limits, both for multiplayer and standard demos if those limits are exceeded):

#define MAX_MSGLEN 16384 //aard: was 8000 max length of a reliable message
#define MAX_DATAGRAM 16384 //aard: was 1024 // max length of unreliable message

Watch out when increasing max datagram size. The "max transmission unit" over ethernet is 1500 bytes, of which 20 is the IPv4 UDP packet header (or 48 in IPv6). 1400 is a good safe value for max packet data size. If your packets exceed this size, the packets will be broken into fragments, which increases unreliability and slowness. If you have more information than fits in one packet, you want to do the selection yourself so you're sure that the most important messages get put in the packet first (i.e. entities/sounds closer to the player get higher priority), then throw away doesn't fit (the typical 'packet overflow' scenario).

Of course, the Quake network protocol is completely crap (to post-1996 eyes). A newly-written protocol would perform a hundred times better in high load situations (see DarkPlaces). But I guess you don't want to break network compatibility.

[mh]

These defines in standard Quake can be modified to make that problem go away (but it breaks the standard protocol limits, both for multiplayer and standard demos if those limits are exceeded):

#define MAX_MSGLEN 16384 //aard: was 8000 max length of a reliable message
#define MAX_DATAGRAM 16384 //aard: was 1024 // max length of unreliable message

Watch out when increasing max datagram size. The "max transmission unit" over ethernet is 1500 bytes, of which 20 is the IPv4 UDP packet header (or 48 in IPv6). 1400 is a good safe value for max packet data size. If your packets exceed this size, the packets will be broken into fragments, which increases unreliability and slowness. If you have more information than fits in one packet, you want to do the selection yourself so you're sure that the most important messages get put in the packet first (i.e. entities/sounds closer to the player get higher priority), then throw away doesn't fit (the typical 'packet overflow' scenario).

Of course, the Quake network protocol is completely crap (to post-1996 eyes). A newly-written protocol would perform a hundred times better in high load situations (see DarkPlaces). But I guess you don't want to break network compatibility.

It's generally fine for SP and demos though, which would be the most common scenarios in which an increase would be required. Perhaps the network transmission layer needs to be modified to detect this and react accordingly.

[Baker]

But I guess you don't want to break network compatibility.

R00k and I are both fans of DPP7. It would also make multiplayer coop possible obviously.

But you have to walk before you can run.

Somehow getting DPP7 tutorialized would be the ideal. Maybe in 3 years I'll know enough to write one