This is probably worth repeating

I mentioned this in a comment, but it's probably worth repeating in a post because it's quite important and has some broader general applicability.

Yes, I removed the automap code a few versions ago. It will most likely be coming back, but I cannot at present say when or give any indication of what form it will take.

The reason why is to do with DirectQ's final remaining major renderer bottleneck. At present there is a HUGE GPU stall - about a third of a frame when the GPU needs to go idle while I'm filling in a dynamic vertex buffer with surface data. Obviously a more optimal strategy that lets me do something useful with that time is required, so I need to investigate it and try a few things out.

Now, it just so happened that the automap code got in the way here. A key component of working on this issue revolves around how the list of surfaces to be rendered is built, and with the automap code I had two different code paths for building this list - with the automap enabled or disabled. Now, you might think that I could have just kept the old way for the automap and tried out new stuff for the standard world refresh, but I want to go deeper than that. I want to explore the in-memory representation of surfaces at a very fundamental level, and come up with something that is just hands-down flat-out more efficient for using on more modern hardware than Quake was originally designed for.

And the automap code held me back from doing that, because every time I did something I would have to do it twice.

When a novelty feature that's not meant to be very robust conflicts or interferes at such a basic level with a core requirement, the novelty feature has to be the one to go. There shouldn't be any arguments or questions about this.

Another thing that should be instantly recognised as being The Way Things Are is that experimental work is, by definition, unbounded in time. After all, it took over a year for DirectQ to come to the beginnings of it's current form, and it took a further year and a half for that to shake out as the best approach for each requirement started to emerge. I don't expect things to take that long this time, but it's clear that another experimental phase is now needed to address deep inadequacies in the Quake architecture.

The other option - which may yet prove to be viable - is to short-circuit the whole thing and move to D3D11 now, which resolves the problem in a clean and efficient manner (but with some cost loaded on elsewhere).

------------

Where this has bearings on features in general is in terms of something that should be obvious: additional features add an exponential overhead to the workload.

Let's take a hypothetical feature, and say that we have three possible combinations: it's not supported, it's supported but disabled, and it's supported but enabled. That's three code paths that need to be tested, debugged and worked over until everything is just right. Add a second such feature, especially if it's a feature that has interactions with the first, and you don't have six paths, you have nine. Add a third and it's twenty-seven, and by then you're in territory where bugs and incompatibilities really come flying out. In just three features where some modest interaction exists.

That's a battle that needs to be fought every day, and the more time you spend fighting it, the less time you have for doing the really productive stuff. Now, if those features are really valuable or vital then it might just be worth fighting it, but you really do need to ask "do we absolutely have to have this feature?" first. Because if you're not asking that question then you're just inviting trouble on yourself.

(Addendum - in a rather quirky Pingback of Karma, this is more or less one of the key reasons why DirectQ existed in the first place: frustration at the horrific mess that OpenGL extensions - and the driver compatibility thereof - were causing for me. It's also the reason why I chucked the fixed pipeline and 16-bit modes.)