View previous topic :: View next topic |
Author |
Message |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Mon Feb 08, 2010 11:36 pm Post subject: |
|
|
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 |
|
 |
dreadlorde

Joined: 24 Nov 2009 Posts: 86
|
Posted: Tue Feb 09, 2010 2:08 am Post subject: |
|
|
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 |
|
 |
Spirit

Joined: 20 Nov 2004 Posts: 476
|
Posted: Tue Feb 09, 2010 7:54 am Post subject: |
|
|
What easier way would there be for a mod to check if the engine supports it (or vice-versa)? _________________ Quake Maps |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Feb 09, 2010 10:28 am Post subject: |
|
|
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 |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Feb 09, 2010 11:31 am Post subject: |
|
|
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 |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
Posted: Tue Feb 09, 2010 11:46 am Post subject: |
|
|
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 |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Tue Feb 09, 2010 4:00 pm Post subject: |
|
|
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 |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Feb 09, 2010 5:24 pm Post subject: |
|
|
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 |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Wed Feb 10, 2010 10:42 pm Post subject: |
|
|
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 |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
Posted: Wed Feb 10, 2010 11:04 pm Post subject: |
|
|
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 |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Wed Feb 10, 2010 11:31 pm Post subject: |
|
|
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 |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Wed Feb 10, 2010 11:47 pm Post subject: |
|
|
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 |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
Posted: Thu Feb 11, 2010 12:38 am Post subject: |
|
|
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 |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Thu Feb 11, 2010 5:54 am Post subject: |
|
|
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 |
|
 |
|
|
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
|