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]

[goldenboy]

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

[MDave]

[LordHavoc]

[goldenboy]

[Urre]

[mh]

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

[FrikaC]

[goldenboy]