Quake Standards Base discussion

[Baker]

/And triple post ...

The Value of the Eye of The Hurricane

Some easily persuadable people right now would look around at the decreased level of activity at Func, QuakeOne, qw.nu and think such a thing is a permanent trend.

In reality, it is far easier to rewrite the rules when activity is low.

When activity is low, there is little to no resistance to change. No one arguing against ideas and experimentation. No static from loud mouths.

It is calm and a time of peaceful concentration.

[mh]

[goldenboy]

[leileilol]

[mankrip]

[Spike]

[mh]

Cross-platform is an interesting thing. DirectQ doesn't bother itself with being cross-platform, and is a much much better Win32 Quake engine that it ever could have been as a result. Aside from just D3D (which was not a trivial undertaking, caused plenty of pain and suffering along the way, but was more than worth it in the end) the code uses the Windows API very extensively, and also uses API calls for which there is just no equivalent in Linux or the CRT.

Porting the D3D stuff to OpenGL would be easy enough, the renderer is structured in a manner that the platform-specific code is actually quite minimal. Porting the other stuff (in particular the memory manager) to a cross-platform environment would be hell.

I wouldn't enforce cross-platform as a requirement. This should be up to the individual engine coder, and the requirements of the work they are doing. There will always be enough engine developers who care sufficiently about being cross-platform that it is going to happen anyway, and doesn't need to be enforced.

Edit: oh yeah, and what Spike said.

QSB needs to be about what engines can do. Specifics and implementation details about how they do it shouldn't really be in scope.

[frag.machine]

I think we are, again, missing the entire point of having something called "Quake Standard Base". Time to give a step back and look at the problem again:

problem: there are a lot of engines, implementing a considerable number of features each one, and among all those features there are a common subset that behaves differently among every implementation, forcing modders and mappers to create content with one or two engines in mind at max. Worse, with the recent port of the Quake engine to other platforms (PSP, Flash, etc) the common denominator among all implementations is reduced due hardware constraints.

solution: let's create a standard (already named Quake Standard Base) grouping the most common features among all current engine implementations, and let's define a minimal contract to be obeyed by the engine programmers.

addendum: AND, regarding the myriad of platforms the Quake engine now reaches, I suggest to subdivide the QSB specification in "desktop" and "mobile" categories, so we can treat the mobile constraints separately, without artificially reducing the scope on the desktop world. I believe this is an acceptable trade-off.

[frag.machine]

[mh]

[frag.machine]

My idea of QSB is more a "black box" approach: as long you deliver what is expected - exactly in the way is expected - I couldn't care less about HOW you did it. So, as long your engine loads the external textures from the expected path and they look right and aren't flipped or have wrong colors or artifacts, I don't give a flying damn if you're using libpng or DeVIL or some obscure Windows API or you wrote a PNG loader from scratch in x86 assembly to do the job.

That said, suggesting paths to beginners such "you can use an external lib such libpng to load the image" is nice. But this must be a suggestions, not an imposition.

And now that we all agree about this point, CAN WE PLEASE STOP TALKING AND DO SOMETHING CONCRETE ABOUT THIS ?

@goldenboy: I think your feature list is a really nice and reasonable start point, so do you think you could create one or two small maps so coders can have a reference to "calibrate" their engines ?

[leileilol]

i think qsb should be a engine that uses md2 (as md2 is superior like Quake2 is superior), tons of particles, tgas in the "TARGASFORMAPS/" folder inside "base2" and connects to my quake servers with special quake network protocol made fo rit only with a launcher with american mcgee alice's chesire cat pasted all over because i think that is cool also it must only run on the nvidia cards because like the qsb i am proposing this is the way it's meant to be played












THE WRITTEN ABOVE IS EVERYTHING QSB ISN'T but it pretty much summarizes all the offtopicness here

[Spike]

its imho more important to say that it looks in textures/$imagename.$ext to find its replacement images than it is to say that it must support any specific format, although both are useful.

a) phat map support
-bsp limits, more ents, static ents, signon size, avoiding packet overflows.

b) checkextensions and common map-related extensions
-tracebox, replacement texture naming, aware of .lit files, aware of qsg_fog, aware of some skybox cvar/field (not specifically support, but will load them from the correct path if they are supported, mod must be able to stuffcmd or whatever without errors appearing to the user).

c) a chosen few non-map related extensions, like FRIK_FILE (QSB 2 would focus on more extensions)
-string manipulation from frik_file, sincossqrt, 'set' command, multipletempstrings.

d) Protocol
-specify actual protocol separately. clients must be able to support protocol 15 if they connect to a server/demo that uses it. Must be able to support big maps which may be cvar-set to enable, exact protocol not specified. Must be aware of protocol version ids used by other engines (no incompatible duplicates).

e) bug fixes, gameplay fixes, and 44100 kHz sound support.
-oriented sprites. functioning skingroups/framegroups

Any objections? Anything I overlooked? Anything that is vital, versatile and simple?

[Baker]

[frag.machine]