Engine standards for mod compatibility

[Urre]

Changed MAX_DATAGRAM to 1400, considering it a hard limit.

What about MAX_DLIGHTS for example, should that be left alone?

MAXALIASVERTS and MAXALIASTRIS, are those hard to change?

MAX_LMB_HEIGHT, how is this best handled, considering the 3dfx downsampling and whatnot?

I'm considering adding flushing unused textures to misc. features, is this a hard feature to do?

Speaking of recursive calling, I do this sometimes, it's very useful!

[mh]

32 dlights should be enough. It's not too hard to go higher, but all the same I would stick with 32 for the standard.

MAX_LBM_HEIGHT I believe comes more from modelgen than from the engine itself, although it's also used by software Quake for a skin lookup table. Either way it should be easy enough to increase, and I don't think we need be worrying about 3dfx these days.

Max alias verts and tris are also easy enough to change, but there are implications for memory usage (also with lightmaps - bumping to 256 needs about 16 MB) which might make the standard inaccessible to lower specced machines (I'm thinking PSP rather than older PCs here). Any worthwhile increase should probably switch to dynamic allocation, meaning something of a rewrite of the loader. This is where gl_mesh.c is really evil and ugly as it just uses a whole batch of big static buffers.

More as I think of it.

[Urre]

I'd love for all of the memory management to be dynamic, but I have no idea how hard that might be to code, I'm guessing very hard. This is why it makes more sense to me to only increase the limits which are the most relevant and easy, which don't make a massive impact on memory usage, I really want for PSP and other handhelds and consoles to be part of this.

Could some memory management be made dynamic, while other parts left static? Are certain parts easier? Are certain parts more relevant than others to make dynamic?

[mh]

Hmmm - lightmaps can be made mostly dynamic easy enough and without upsetting the existing code too much, although putting them on the hunk would require an increase in MINIMUM_WIN_MEMORY. I've already posted code in the tutorials section for just about everything relating to alias models, but I don't know if there's going to be much in the way of uptake on it.

Generally the problem is that everything needs it's own special handling, and sometimes there are knock-on effects in unexpected places. Quake's memory management system isn't too friendly for it either. Finally it can be difficult to retro-fit into an engine that has already had significant work done on it.

[frag.machine]

This discussion about the proposed new limits brings another problem to light: the current artwork (maps, textures, alias models, etc) file formats and how they are quickly becoming the bottleneck for the natural evolution of the engines. I believe that in the event of a QSB 2.0 standard we should consider the option of new, more flexible file formats and then maybe a set of migration tools. For now I think is best to just stick to the current ones for simplicity sake.

If the QSB 2.0 standard did have new file formats would it still be compatible with the original ones? If not would all of the original Quake artwork have to be converted or would it be redone?

Ok guys, let's keep in mind all the time that QSB 1/2/n will be ALWAYS retro-compatible, and only should fallback to legacy stuff if a newer format wasn't found or is not applicable. So, let's take this hypothetical example:

QSB 1.0 = supports Quake network protocol 15 + QSB protocol 997, protocol 999 is active by default, you have to manually selected protocol 15 if want to run a vanilla server;
QSB 1.1 = supports Quake network protocol 15 + QSB protocol 999 + QSB protocol 1000, 1000 is active by default, you have to manually select any other protocol if want to run a legacy-compatible server.
(...)
QSB 10.0 = supports all previous protocols + QSB protocol 6666, blah blah blah blah...

The same rules applied to alias models file formats (WARNING - this is a fictional scenario):

QSB 1.0 = supports .mdl/.md2, always tries to load md2 first, then mdl;
QSB 1.1 = supports .mdl/.md2/.md3, loading sequence is always md3/md2/mdl
(...)
QSB 10.0 = supports .mdl/.md2/.md3/(insert a long list of obscure file formats), loading sequence is from the newest to the oldest format.

So I hope now it's clear to everyone that QSB is not about breaking what exists, but evolve the Quake engine technology so the platform can survive longer.

[Urre]

frag.machine made it very clear, there.

I'm wondering if the increased limits should be listed in some different manner by the standard, rather than all these constants, as it might not make a lot of sense if engine devs want to do it in some other way. Instead of telling them how to do it, it should say what's expected as an end result, I think...

One idea which comes to mind is listing what maps it should be able to run. If the map passes, the engine is QSB compatible. I've already planned to make a QSB test-mod for this purpose, and simply listing limit-breaking maps can be an easy shortcut for some of the tests.

Then again, it might get a bit too abstract? What if there are no maps which break all the limits we want to raise?

[Teiman]

I've already planned to make a QSB test-mod for this purpose, and simply listing limit-breaking maps can be an easy shortcut for some of the tests

This is a awesome idea.

[frag.machine]

I'm wondering if the increased limits should be listed in some different manner by the standard, rather than all these constants, as it might not make a lot of sense if engine devs want to do it in some other way. Instead of telling them how to do it, it should say what's expected as an end result, I think...

The list can be enhanced with a more didactic explanation for non-coders, but all constants are part of the original Quake source code, and engine devs are normally well acquainted of them. Anyway, if you have an idea for a more adequate format, let's see it.

One idea which comes to mind is listing what maps it should be able to run. If the map passes, the engine is QSB compatible. I've already planned to make a QSB test-mod for this purpose, and simply listing limit-breaking maps can be an easy shortcut for some of the tests.

Not only listing, but I think we should prepare a package containing:
a) maps specifically built to force engines to the new limits;

b) a simple test mod for QSB-specific features;

c) recorded demos that stress the network limits and any new protocol features;

d) screenshots with the expected results for things like alpha/scale/fog support (but not limited to this).

Then again, it might get a bit too abstract? What if there are no maps which break all the limits we want to raise?

Then somebody need to build them
I think that's something where the map community can contribute actively: once we define the new limits, the mappers could built simple "testboxes" for the new features. One map can test more than one aspect, but I expect we'll need a bunch of them to test everything. This way we ensure all the community is committed with QSB and thus the standard becomes stronger.

[Spirit]

I have a small testmap for fog, overbrights, fullbrights, texture support (only marginally) and func_ brush transparency. Feel free to use any of it as you like.
http://www.quaddicted.com/quake_engines ... spirit.zip

arguirRe's engine has nice limits output in developer mode. Very useful to create limit-breaking maps.

[frag.machine]

Spirit: yeah, I know your map, that's exactly what I am talking about, only with a more extensive coverage (for example, regarding texture loading: IMO QSB should define not only what minimal file formats should be supported - pcx, tga, bmp, etc - but also the loading sequence; then a test map should simulate the situation of having two or more textures with same name but different formats so we could check if the engine loads them in the expected order).

[mh]

Spirit: yeah, I know your map, that's exactly what I am talking about, only with a more extensive coverage (for example, regarding texture loading: IMO QSB should define not only what minimal file formats should be supported - pcx, tga, bmp, etc - but also the loading sequence; then a test map should simulate the situation of having two or more textures with same name but different formats so we could check if the engine loads them in the expected order).

So really what we're talking about is a kind of conformance test? Sounds like a good idea to me.

[frag.machine]

Spirit: yeah, I know your map, that's exactly what I am talking about, only with a more extensive coverage (for example, regarding texture loading: IMO QSB should define not only what minimal file formats should be supported - pcx, tga, bmp, etc - but also the loading sequence; then a test map should simulate the situation of having two or more textures with same name but different formats so we could check if the engine loads them in the expected order).

So really what we're talking about is a kind of conformance test? Sounds like a good idea to me.

Test-driven development is always a good idea, specially in the case of many independent coders.

[Spike]

test driven gives reason.

[gnounc]

Like the acid tests for web browsers.
I love reading those, cant wait for the acid4 test.
http://en.wikipedia.org/wiki/Acid1

[LordHavoc]

I made an acid test of sorts for quake map compatibility once...

http://icculus.org/twilight/darkplaces/files/entitytest.zip

Yes, it has a moving sky brush.