Inside3D!
     

Quake Standards Base discussion
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Mon Feb 08, 2010 11:36 pm    Post subject: Reply with quote

Standards by committees suck because they have to adress so many different needs and views, so they become big and cluttered, often slow, whereas non-committee driven standards simply grow out of competition, which is the very thing I'm trying to fight against for once. I'm forced to make it act like a committee-like standard, even though I've just made it up myself, based on peoples wishlists. I'm forced because the goal is the same as committee standards, I'm trying to please as many as possible. Not only the modders and mappers, some of them don't even know they need pleasing, but also the engine devs, that's the biggest headache, really, as all of this is pointless if all engine-devs find it stupid or useless or whatever. So far it seems QSB is getting a lot of support, atleast the idea of it, which is really all I wanted for starters. The next step is cementing a first version of the standard. The step after that is to actively lobby for the idea, make sure engines get it implemented, along with me (and hopefully others) working on making test cases for it.

That's how I see it...

The question remains, should QSB ignore checkextension?
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
dreadlorde



Joined: 24 Nov 2009
Posts: 86

PostPosted: Tue Feb 09, 2010 2:08 am    Post subject: Reply with quote

That's really the only part I don't see a point for.
_________________
Ken Thompson wrote:
One of my most productive days was throwing away 1000 lines of code.

Get off my lawn!
Back to top
View user's profile Send private message AIM Address
Spirit



Joined: 20 Nov 2004
Posts: 476

PostPosted: Tue Feb 09, 2010 7:54 am    Post subject: Reply with quote

What easier way would there be for a mod to check if the engine supports it (or vice-versa)?
_________________
Quake Maps
Back to top
View user's profile Send private message Visit poster's website
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Tue Feb 09, 2010 10:28 am    Post subject: Reply with quote

checkextension is only there for if the mod wants to check it. its existance does not mandate its use.
if you don't mind your mod crashing/etc on a legacy engine, then there's no need to check to see if it supports stuff.
that said, smaller mods like frikbots enjoy optional support from the engine, without breaking too much on such legacy engines, without breaking the mods they get ported to.
but yes, in an ideal world, every engine would support everything you wanted to do, meaning checkextension is useless. in an ideal world, anyway.
The engine should support it, imho, but there's no reason for the mod to need to bother.
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Feb 09, 2010 11:31 am    Post subject: Reply with quote

A QSB 0.5 would be nice.

Right now I am thinking that the ideas behind a 1.0 standard violate the 90%/10% rule (90% of the gain for 10% of the effort).

My personal philosophy is that development and standards are fueled by completed works that people enjoy playing and are popular, increasing the demand and use of the feature.

Certain features have LOW implementation costs and HIGH gains for implementation:

* Scale
* MOVETYPE_FOLLOW
* EF_NODRAW
* EF_ADDITIVE
* DRAWONLY_TO_CLIENT
* FRIK_FILE

etc.

And certain other changes have very HIGH implementation costs and LOW gains for implementation:

* Memory management systems
* Major protocol changes
* Major changes to break limits

I'd like to see a stepping stone standard as a reasonable first step towards a greater standard.

There is nothing inherently wrong with QSB 1.0, but a fast and easy to achieve QSB 0.5 with most of the easy win features that would allow better modding would be nice as a checkpoint to a 1.0.

Obviously with a protocol 15+/666+ to support it maybe even with delta compression if that isn't too difficult to achieve.[/list][/code]
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Tue Feb 09, 2010 11:46 am    Post subject: Reply with quote

One other advantage I can see of a QSB 0.5 is that it would let us road-test the standard rather quickly. We all know that talking about great ideas is one thing, but actually doing them and seeing how they work in practice is completely different. By getting something up and running sooner rather than later we can easily identify and find solutions for potential trouble spots.

It would also greatly ease the implementation overhead for engines that have already been evolved well boyond the ID Quake baseline.

The danger of course is that the standard will become stuck at 0.5 and not go much beyond that.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Tue Feb 09, 2010 4:00 pm    Post subject: Reply with quote

We can create a QSB 1.0 standard with a really minimal list of features, I don't see the need for "< 1.0" version numbers. Actually I already told that: let's start small, a list of 10 or less features that we, the community, could consider the "minimal" to expect from a non-vanilla engine. QSB 1.0 doesn't need to be "complete" - actually, it's unlikely it will be in the first incarnation. I see QSB only reaching a "mature" state after the fourth or fifth iteration. So, I'd vote to start small, but following the "90/10" rule Baker mentioned.

Another advantage in start small is to dissipate a bit this "formal committee" image we are creating to people outside the discussions. Both dreadlorde and Urre have valid, although different, points regarding this committee image. But IMO the simpler we start the easier people will embrace the idea.

Regarding checkextensions, I share Urre's point of view: why not implement it ? It's really simple to do, a number of projects already have it (filling the "let's standardize what's common" requisite) and quite useful for modders. Having the ability to detect in a safe way if the engine can/cannot do something is useful. Unless somebody is considering another QSB-exclusive mechanism - and, TBH, I think it's not a good idea to reinvent the wheel, since checkextensions works just fine.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Tue Feb 09, 2010 5:02 pm    Post subject: Reply with quote

Let's do it then. Very Happy

No reason not to at the very least implement checkextensions and just return false for everything, is there?
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Feb 09, 2010 5:24 pm    Post subject: Reply with quote

mh wrote:
One other advantage I can see of a QSB 0.5 is that it would let us road-test the standard rather quickly. We all know that talking about great ideas is one thing, but actually doing them and seeing how they work in practice is completely different.


Avelocity is going to get used. Scale will get used. Alpha will get used. Colormap (I hope this works in software renderers?) will get used. Movetype follow will get used. Drawonly to client will get used.

The sooner and easier they become available, the better.

Protocol is not immediately so important because most of the usage would be in single player or in "game-locked" engines (dedicated total conversion engines). For multiplayer, at least at this point, DarkPlaces and FTEQW would be what people use ... until a new standardized protocol emerges.

Quote:
The danger of course is that the standard will become stuck at 0.5 and not go much beyond that.


I have a hard time believing that would happen.

It's just I think massive changes for part of a standard for a first stepping stone puts the entire idea in jeopardy.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Wed Feb 10, 2010 10:42 pm    Post subject: Reply with quote

I agree. To restate my earlier posts:

- smaller, incremental standards. Multiple small versions are easier to implement, but more importantly, easier for a committee to agree upon than one "ultimate standard"

- standardize common practice, rather than inventing new features. new features are too hard to spec, existing practice is proven to be usable in the field.

- keep it modding relevant and eliminate anything that is outside of that scope. Console size, tab completeion are NOT modding relevant.

- implementation-agnostic requirements. MAX_MAP_LEAFS are inherent to the bsp file, MAX_GLTEXTURES are not, because they depend on all things the engine uses gltextures for.
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Wed Feb 10, 2010 11:04 pm    Post subject: Reply with quote

metlslime wrote:
I agree. To restate my earlier posts:

- smaller, incremental standards. Multiple small versions are easier to implement, but more importantly, easier for a committee to agree upon than one "ultimate standard"

- standardize common practice, rather than inventing new features. new features are too hard to spec, existing practice is proven to be usable in the field.

- keep it modding relevant and eliminate anything that is outside of that scope. Console size, tab completeion are NOT modding relevant.

- implementation-agnostic requirements. MAX_MAP_LEAFS are inherent to the bsp file, MAX_GLTEXTURES are not, because they depend on all things the engine uses gltextures for.

The only thing I'd add to that is when BSP/etc limtiations are artificial - i.e. a function of the implementation as it exists in ID Quake, rather than as it is derived from the format - they should be included (but perhaps deferred to a second rev of the standard to allow it to get off the ground quicker).
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Sajt



Joined: 16 Oct 2004
Posts: 1026

PostPosted: Wed Feb 10, 2010 11:31 pm    Post subject: Reply with quote

I'm looking at the QSB wiki page, and it almost looks like you're increasing every single limit you can find. Are these values based on an existing good engine, or are they kind of arbitrary? It would be an annoying task to update all these in one's engine (not to mention probably causing memory use to balloon). Maybe most of it should be kept for a later version... (same with the humongous amount of extensions)

Anyway, this looks pretty good. The wiki page could be expanded into something like that old site which had a huge list of Quake bugs and how to fix them. I would add a few more which I came across and fixed already in GoldQuake (and I would be happy to write tutorials on the wiki for them, maybe I'll do that later today).

Features:
- "freelook" cvar.
- "showfps" cvar.
- mouse4 and mouse5.
- "in_pitch_min" and "in_pitch_max", like DarkPlaces but defaulted to the Quake values.

Actually, according to metlslime's post those first three shouldn't be included. But the pitch min/max should be.

Bugfixes:
- "sv_gameplayfix_setmodelrealbox" (setmodel sets bbox to model bounds, not '-16 -16 -16', '16 16 16').

Also a cvar to disable the effect in Quake where the weaponmodel is nudged upward when the hud is activated (causing the weaponmodel to shift when you look up/down). This is particularly noticeable when you have an effect which is supposed to be sourced at the gun's barrel... when you look up or down it doesn't quite match up anymore.

And a cvar to enable vertical-based FOV, which makes widescreen work properly (or is this again not modding-specific?).

I think the default for all "fix" cvars should be off, to match Quake's behaviour. Mods should set them in autoexec.cfg.
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
Back to top
View user's profile Send private message
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Wed Feb 10, 2010 11:47 pm    Post subject: Reply with quote

mh wrote:
metlslime wrote:
- implementation-agnostic requirements. MAX_MAP_LEAFS are inherent to the bsp file, MAX_GLTEXTURES are not, because they depend on all things the engine uses gltextures for.

The only thing I'd add to that is when BSP/etc limtiations are artificial - i.e. a function of the implementation as it exists in ID Quake, rather than as it is derived from the format - they should be included (but perhaps deferred to a second rev of the standard to allow it to get off the ground quicker).

Oh, yeah I don't want to drop such limits entirely, just try to redefine them in an implementation-independant way. For example, define it in terms of a combined total for bsp textures + skins + sprites needed by a single level.
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Thu Feb 11, 2010 12:38 am    Post subject: Reply with quote

Sajt wrote:
I'm looking at the QSB wiki page, and it almost looks like you're increasing every single limit you can find. Are these values based on an existing good engine, or are they kind of arbitrary? It would be an annoying task to update all these in one's engine (not to mention probably causing memory use to balloon). Maybe most of it should be kept for a later version... (same with the humongous amount of extensions)

Anyway, this looks pretty good. The wiki page could be expanded into something like that old site which had a huge list of Quake bugs and how to fix them. I would add a few more which I came across and fixed already in GoldQuake (and I would be happy to write tutorials on the wiki for them, maybe I'll do that later today).

Features:
- "freelook" cvar.
- "showfps" cvar.
- mouse4 and mouse5.
- "in_pitch_min" and "in_pitch_max", like DarkPlaces but defaulted to the Quake values.

Actually, according to metlslime's post those first three shouldn't be included. But the pitch min/max should be.

Bugfixes:
- "sv_gameplayfix_setmodelrealbox" (setmodel sets bbox to model bounds, not '-16 -16 -16', '16 16 16').

Also a cvar to disable the effect in Quake where the weaponmodel is nudged upward when the hud is activated (causing the weaponmodel to shift when you look up/down). This is particularly noticeable when you have an effect which is supposed to be sourced at the gun's barrel... when you look up or down it doesn't quite match up anymore.

And a cvar to enable vertical-based FOV, which makes widescreen work properly (or is this again not modding-specific?).

I think the default for all "fix" cvars should be off, to match Quake's behaviour. Mods should set them in autoexec.cfg.

Despite the fact that they're not in metl's list, these are interesting features and probably more suitable for a "baseline essential engine features" thread.

One thing that I think is relevant is cvar name standardisation. DirectQ is shortly going to have the ability to refer to a cvar by multiple names (and potentially to declare new cvars on the fly from QC, but that's a whole 'nother story), but that's not something that most engines would have, and it's important to get right for any included feature that is cvar-controlled.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
r00k



Joined: 13 Nov 2004
Posts: 483

PostPosted: Thu Feb 11, 2010 5:54 am    Post subject: Reply with quote

1.> QSB 1.0 engine limits
2.> ENHANCED STRING FUNCTIONS / FRIKFILE support
3.> SKYBOX, FOG, ENTRYSPAWN world spawn fields
4.> enchanced SVCs for hud features.(teamscore, match time, flag status)
5.> 24bit texture support. atleast menu and world textures
6.> animation interpolation
7.> cvar standards
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 4 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group