Engine standards for mod compatibility

[goldenboy]

Yes, it is time for this. Many parts of it are already there, or just about to happen.

Also, at RMQ's headquarters, we could simply close ticket #120 - Engine.

[Downsider]

What Downsider is trying to make fun of like a know-it-all 8th grader is probably that you said a "minimum of a maximum" while there could only be one value and that would be the maximum. You probably said minimum because you meant a common maximum of 512 would be a good minimum standard to see among engines. But hey, it is way moar lulz to post backseat remarks instead of simply correcting.

I love you for posting this topic, very good initiative.

I was just pointing out something I found amusing.

EDIT:
And no, that's not even it. He was saying "Be more specific with your documentation, guys!", but his example is "Increased maximum to a minimum of 512".. Meaning that the limit could be anywhere above 512.. :/

[goldenboy]

OK, let's not further disrupt this thread, please, because this is important.

[frag.machine]

I suggest the following steps:

1) enlist all cited features in this thread (and any others you think deserves to be candidates);

2) start a vote so people can give notes (say, from 1 to 5, higher notes means most valuable/desirable). It's important that this vote MUST be open to other people from the community (mappers, people that stills playing online, modders, etc), so this adds value to the standard;

3) close the vote and select the N top features;
3.1) N must be wisely defined: not being too small so basic structural changes like bigger engine limits being cut off, neither too big that implementing Quake Standard Basic 1.0 (I like this, sounds cool ) becomes an overwhelming task;

4) write or compile tutorials implementing every selected feature;
4.1) it's highly desirable such tutorials not being limited to chunks of code to cut & paste, but a comprehensive explaining at least in general lines what's going on there (MH's and Baker's tutorials are good examples), so one willing to re-implement feature XPTO in another way will have enough available info to do so;
4.2) tutorials showing how to use such features are essential, too!;

5) spread the new QSB 1.0 spec around all the community;
5.1) however, may be wise to keep this site as the main reference for updates, corrections, etc;

6) profit.

[metlslime]

From a more mapping-centric point of view, some of these seem important:

features that could break the experience if absent.
- alpha (e.g. glass that you need to be able to see through)
- fullbrights (e.g. glowing button in a dark area)

features that are pretty harmless if absent
- colored lightmaps
- skybox
- fog

relatively hard limits that break the experience (or crash the engine) if exceeded:
- faces
- marksurfaces
- leafs
- nodes
- visleafs
- lightmaps
- model precaches
- sound precaches
- edicts
- static entities
- clipnodes

more fuzzy limits that might be hard to define and generally don't break the experience (but could)
- temp ents
- efrags
- beams
- dlights
- packet size
- signon buffer size
- sound channels

[frag.machine]

features that are pretty harmless if absent
- colored lightmaps
- skybox
- fog

I disagree about colored lights and fog, mostly the last one. For example, one can use red lights to signalize dangerous area in a map, and plain white lights won't work well in this case.
And fog can be used to, say, hide traps (I know, this can be a very cheap mapping trick, but a valid one nonetheless - id resorted to that a lot in Doom 3 ).

EDIT: for spelling correction.

[MDave]

features that are pretty harmless if absent
- colored lightmaps
- skybox
- fog

I disagree about colored lights and fog, mostly the last one. For example, one can use red lights to signalize dangerous area in a map, and plain white lights won't work well in this case.
And fog can be used to, say, hide traps (I know, this can be a very cheap mapping trick, but a valid one nonetheless - id resorted to that a lot in Doom 3 ).

EDIT: for spelling correction.

Did you mean 'agree' in the first sentence?

[LordHavoc]

I should bring up two mods that kind of set a standard for themselves:
Nehahra - this is a host of hacks but some core elements are good overall (skybox, colored lighting, higher limits, etc).

Quoth - this is also a host of hacks with some good core elements (although the way the q1bsp limits were increased is dubious, the format version should have changed to prevent loading them into engines that are clearly not capable of loading them).

I think the bare minimum set of enhancements desired by level designers would be:
colored lightmaps (.lit) and dlights and optimized dlights (litsupport.zip tutorial)
increase MAX_EDICTS from 600 to 2048
increase NET_MAXMESSAGE from 8192 to 65536 (to prevent getspace errors with lots of static entities)
increase static entity limit from 128 to 512 (for more torches, etc)
skybox
fog
alpha
EF_ADDITIVE flag (can be used for a variety of effects including light beam effects)
EF_FULLBRIGHT flag (often used with EF_ADDITIVE)
fullbrights
full limits of q1bsp unleashed (like arguirre tools allow)
raised model and sound limits (requires extended protocol)
dynamic sound channels (8 is way too few)
beams (8 is too few in some levels)
external texture loading with textures/mapname/blah.tga naming to avoid conflicts with other installed maps, and also _glow texture loading
full lightmap range (0-2x brightness, not clamped like glquake, to avoid the strange gray saturation of level lighting in glquake)

software engines can be exempt to several of these requirements, but I do not recommend software engines at all.

[goldenboy]

Packet overflow fix is a must. There are testmaps around for this (the box full of grunts comes to mind - gib rain).

I would rate skybox support, and probably fog, as important. Support for larger skybox images than 256x256 or even 512x512 would also be nice. Mappers carefully choose the sky for their level, and some maps are designed with fog in mind. Some ugly pixelated default sky does break the experience for me, although technically skyboxes are not strictly required. It would be pretty ridiculous to not have skybox support as the standard.

Colored lighting I would see as the least important of those three, but it would be nice, yeah.

I believe a list of map-related features is comparatively easy to come up with, as metlslime and LordHavoc have demonstrated.

[Urre]

LH pointed out something important, are SW engines of any priority?

[mh]

From a more mapping-centric point of view, some of these seem important:

features that could break the experience if absent.
- alpha (e.g. glass that you need to be able to see through)
- fullbrights (e.g. glowing button in a dark area)

features that are pretty harmless if absent
- colored lightmaps
- skybox
- fog

relatively hard limits that break the experience (or crash the engine) if exceeded:
- faces
- marksurfaces
- leafs
- nodes
- visleafs
- lightmaps
- model precaches
- sound precaches
- edicts
- static entities
- clipnodes

more fuzzy limits that might be hard to define and generally don't break the experience (but could)
- temp ents
- efrags
- beams
- dlights
- packet size
- signon buffer size
- sound channels

The max number of static entities is dependent on the max number of efrags, so if you increase static entities you'll have to increase efrags. Otherwise a good list and nice to see them all in the one place.

[goldenboy]

Well, there are software users in the NQ and QW communities. Are you going to tell them to "fuck off"? Remember not all corners of the planet have cheap modern hardware available. Not all individuals might. There might be good reasons for some to use software.

I do think that we need the software renderer around and that it needs to be maintained for use as a reference. Software was how Quake was supposed to look.

On the other hand, it would put quite some burden on engines like Fitzquake, Darkplaces and DirectQ. We can't really dictate for engine coders to re-include software renderers, and including software renderers as optional would be half-assed.

Hacking the map related limits in a software engine is no problem. Neither is including CSQC or basic Nehahra support. Alpha is a problem.

Maybe the new standard doesn't even need to concern itself with renderers. You could argue that it is the individual engines' problem how they support the standard. This would include the question of which renderers they want to provide.

FTE has a software renderer that works fine. It probably supports 90% of those features already. 90% isn't bad.

In the end, I would say that the renderer question is out of the scope of such a new standard, and the engines' problem, not the standard's.

There was a famous saying in the German army: "Do X. How you do that is up to you". It worked.

[mh]

I do think that we need the software renderer around and that it needs to be maintained for use as a reference. Software was how Quake was supposed to look.

Well said. If for no other reason we definitely need the software renderer for that.

On the other hand, it would put quite some burden on engines like Fitzquake, Darkplaces and DirectQ. We can't really dictate for engine coders to re-include software renderers, and including software renderers as optional would be half-assed.

That's an interesting point. I obviously can't speak for the others, but the whole reason for DirectQ to exist in the first place was for to provide a hardware accelerated alternative for people (especially me ) who had machines that couldn't run GLQuake (or other OpenGL engines). Obviously it's grown quite beyond that initial scope, and these days provision of a software (or even an OpenGL) renderer as an alternative to the D3D renderer is something that's not impossible to consider. Not that it's particular high on the "to do" list either, but all the same, I should probably at least give thought to architecting my setup in a way that would make inclusion of a software renderer somewhat less painful.

[FrikaC]

I should note that a lot of the ports to other platforms are based on the software renderer. GP32, etc spring to mind. It'd be nice if some of those engines were able to participate in these standards.

[goldenboy]

If alpha support is included in the standard, software renderers are excluded. As far as I understand it.

That warrants discussion about alpha support.