Quake Standards Base discussion

[r00k]

[goldenboy]

[goldenboy]

[goldenboy]

OK, who is interested in really getting together and defining a small set of core features that a QSB 1 should contain - following the 90/10 rule that Baker mentioned, 90 percent of the gain for 10 percent of the effort?

http://quakery.quakedev.com/qwiki/index.php/QSB

The list of map limits and extensions on the Quake Wiki page is still too big for a first attempt IMO. So let's try to pare it down:



RemakeQuake is a humungous mod, and we already break most of the limits listed by Urre in that draft. So regarding map limits, I'm pretty sure RMQ could serve as a test case for engine coders, and several of them have kindly expressed interest in supporting it, too. When it comes to oversized maps with badly broken limits made by self-absorbed, criminally negligent outlaw mappers, I guess we are a good example, and a realistic example at that.

QSB 1 should aim to only include stuff that actually, realistically, gets used and can be tested (engine coders can simply get access to our SVN as watchers). In the case of the rotating entity stuff and flickering bmodels, there was already a working collaboration like that.

I think the full list of map related limits ("phat map support") should be part of QSB 1, since this really gets used and I think it isn't too hard to implement. Also, lots of engines support most of that already, anyway - it is in accordance with the 90/10 rule.

I count as part of "phat map support" also an increased map size limit - some of our maps will break the unwritten law of the 4096. Not by much, but they will break it. This means QSB1 will break protocol 666, for example, and it will need its own.



RMQ uses stuff like rotating bmodels, entity alpha, fog, skyboxes and lit files. We're thinking to include stuff like FRIK_FILE and perhaps a few other extensions.

I do think that checkextensions must be in QSB 1, along with things like FRIK_FILE, .lit file/skybox/entity alpha support, rotating bmodel support - including smooth angles (breaks protocol 666 again) -, and also a common QSB_FOG format much as defined here:

http://quakery.quakedev.com/qwiki/index.php/QSB_FOG

and the list of gameplay fixes defined as QSB_GAMEPLAYFIXES:

http://quakery.quakedev.com/qwiki/index ... EPLAYFIXES

as well as the bugfixes mentioned on the wiki page.

All of that is stuff that actually gets used, fixes gameplay bugs, and is widely implemented and working (90/10 rule). We should probably add external texture support to that list, as defined in the QSB wiki entry.

Engines must also contain fixes for flickering (rotating or otherwise) bmodels; mh posted a fix recently. RMQ includes at least one test case for this.

44100 kHz sound support is required by RMQ; this should be standard anyway. Is there an engine that doesn't support this?

If I'm not mistaken, this sums up the stuff that RMQ uses currently or in the near future (like FRIK_FILE). This is as good a starting point as any, and the advantage is that there is a real-world test case with its own (Fitzquake-derived) engine and protocol (999).



A few fixes require protocol changes; for example large map capacity and smooth angles. In a poll on this forum, there was a 14 : 0 vote PRO new network protocol. So let's have it.

Out of necessity, RMQ created its own protocol (999) which right now basically is PROTOCOL_FITZQUAKE (666) with large map support (float coords) and smooth angles (floats again) added on top of it. Protocol 999 should be considered in-development, though; a possibility is to use 777 as a short-term solution (fitz666 + float angles/coords), while 999 is used as a testbed, and an eventual, finished, QSB protocol would be protocol 1000.

Of course there can always be discussion about numbering and general features of both the short-term and long-term solutions. But again, I think the 90/10 rule applies: Let's go with something that exists already, and augment it. Protocol 666 includes most of the required map limits stuff and entity alpha support, it is well commented, and easily extensible.



After QSB 1 is defined and engines start supporting it, more extensions can be added to it; this would be the main point of QSB 2. Protocol changes and refinements would go into protocol 999. At some point after QSB 2 is finished, protocol 1000 is finalized.



The idea of the 90/10 rule (90 % gain for 10 % of the effort), or going with only a small core set that is largely already supported, makes the most sense.

I'd be willing to write down the specs and hopefully transform input from engine coders into a detailed list.

Very basically, QSB1 would include

a) phat map support

b) checkextensions and common map-related extensions

c) a chosen few non-map related extensions, like FRIK_FILE (QSB 2 would focus on more extensions)

d) Protocol 777 (or whatever the number ends up to be - while 999 is used as a testbed, and eventually becomes protocol 1000)

e) bug fixes, gameplay fixes, and 44100 kHz sound support.

Does that sound roughly agreeable?

[Spike]

[goldenboy]

[frag.machine]

[mankrip]

[Spike]

[mankrip]

I know.

However, I feel that any standards should really try to make things uniform. It's a lot easier to implement new features after achieving that, since when making things uniform we can also make them more abstract - including the documentation, which can be a lot easier to understand and write when there's no need to explain things like specific filetype-dependent behavior.

[mh]

[goldenboy]

[r00k]

[Baker]

[Baker]