Inside3D!
     

Engine standards for mod compatibility
Goto page Previous  1, 2, 3 ... 12, 13, 14, 15, 16  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
LordHavoc



Joined: 05 Nov 2004
Posts: 243
Location: western Oregon, USA

PostPosted: Fri Jan 15, 2010 4:47 am    Post subject: Reply with quote

Urre wrote:
Exactly, I'm starting to lean towards this one a bit, although I was against it at first. Well, I was against optional features as suggested by LH, but this isn't really the same thing. It's features within limits of capability. I'd require full support for the feature if it's a hardware accelerated renderer, but only reasonable support if it's a software renderer. Still with clear requirements, just not fullblown like the hardware one. Nothing optional in that.


No it is the same thing, I specifically made the point that all reasonable features are required - for a software engine, alpha rendering would not be considered reasonable, but for hardware engines it would be considered required.
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Fri Jan 15, 2010 8:31 am    Post subject: Reply with quote

LordHavoc wrote:
No it is the same thing, I specifically made the point that all reasonable features are required - for a software engine, alpha rendering would not be considered reasonable, but for hardware engines it would be considered required.

Okay, must've misunderstood then, maybe I didn't read proper Smile

Original Quake compatibility is a must, I don't see how you guys can even consider this Confused we don't want to break stuff. In that case I'd rather not alter protocol, if it's a big deal to have multiple ones.
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Fri Jan 15, 2010 12:11 pm    Post subject: Reply with quote

By simply extending some engine limits (something that appears to be a common opinion here, me included) we already break compatibility with GlQuake/WinQuake, there's no way out. FitzQuake did that and most of people didn't realize (or care about) this. I know, it supports both protocols, but if you're running a server with a map that, let's say, uses more than 256 models (like warpc), you cannot connect a vanilla client on FitzQuake, only other FitzQuake client (and maybe MH's DirectQ). Bang, compatibility is already dead - and ironically, dead by those whom are usually against most changes introduced by us, the developers: the mapping community. Please, don't take this as an accusation, it's just a fact I am pointing. That's what I am talking about when I say we must leave ye old GlQuake behind: if most of the community wants more, we shouldn't restrict ourselves in name of a few who won't leave legacy for anything else to play. Those people don't need QSB because they don't want to change nothing at all.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
LordHavoc



Joined: 05 Nov 2004
Posts: 243
Location: western Oregon, USA

PostPosted: Fri Jan 15, 2010 12:23 pm    Post subject: Reply with quote

Urre wrote:
Original Quake compatibility is a must, I don't see how you guys can even consider this Confused we don't want to break stuff. In that case I'd rather not alter protocol, if it's a big deal to have multiple ones.


No true newbie engine will ever be standards compliant, there is a bare minimum knowledge of programming required to integrate such features - being able to edit the protocol code intelligently is such a case.

This standardization effort is not (and can not be) aimed at complete newbies to the engine programming scene, they need too much help, and should just enjoy their experiments rather than worry about standards.

This effort must be aimed solely at the popular engines on each platform (note the caveat here - an engine can be very low popularity, but still be one of the most popular on its niche platform, and that still warrants attention to standards).

Supporting multiple protocols is a given.
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Fri Jan 15, 2010 12:44 pm    Post subject: Reply with quote

LordHavoc wrote:
No true newbie engine will ever be standards compliant, there is a bare minimum knowledge of programming required to integrate such features - being able to edit the protocol code intelligently is such a case.

This standardization effort is not (and can not be) aimed at complete newbies to the engine programming scene, they need too much help, and should just enjoy their experiments rather than worry about standards.

This effort must be aimed solely at the popular engines on each platform (note the caveat here - an engine can be very low popularity, but still be one of the most popular on its niche platform, and that still warrants attention to standards).

Supporting multiple protocols is a given.

What's needed here then is a writeup on supporting multiple protocols. It's not rocket-science but still it's surprising easy to make an unholy mess while doing it.

Such a writeup needn't start out as a full tutorial on implementing a new protocol, but it could evolve into one at some stage. I'm thinking more along the lines of implementing the sv_protocol command, how to detect different protocols at the client, extending the net message size (and weaving your way through the tangle of #defines in that part of the stock ID code); just laying the basic groundwork for making addition of a new protocol to any engine relatively pain-free.

Above all this comes back to the point I made that any proposed standard must be achievable, otherwise it won't get uptake and will be dead in the water.

If a proposed standard is going to involve supporting multiple protocols then we have an obligation to make it possible for anyone anywhere working on a Quake codebase to be able to do this without having to go through the same learning experience (and make the same mistakes) all over again.
_________________
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
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Fri Jan 15, 2010 12:57 pm    Post subject: Reply with quote

I'm liking all of the views, as they have valid points. The original idea was to standardize the existing popular engines, but I don't want it to be impossible for newcomers to take part in this. Some platforms have very simple and unenhanced engines, and it should be possible to get those compatible as well. It'd require work, ofcourse, but there should be lots of help available. That's why I early on suggested that capable people who feel interested should work on making tutorials for the parts of the standard which don't exist yet. I do more than realise the risk in taking it too far, that people would be put off by the amount of work required to match the standard, I'm being very cautious overall, but I am feeling like we should push for higher quality in some cases which might be hard to achieve, such as multiple protocol support.

If I take a completely objective position for a moment, and ask, why is multiple protocol support a given? Why not do what frag.machine says, and just push things forward, making protocol 15 optional for QSB compatible engines? Where's the harm?

Second, if fog (for hardware rendered engines) is to be included in the standard, it has to look the same among engines, consistency is key for all QSB features. I'm leaning towards making a second fog path, called qsb_fog, and let the engines keep their old fog under the old name, rendering it as they always have. qsb_fog however would have to look the same between engines.

Which is the better choice: forcing old fog to look the same between engines and if the engine dev wants to keep their own fog look, they'll have to call it something else, or calling the new fog something else (qsb_fog, like above)?
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Fri Jan 15, 2010 1:19 pm    Post subject: Reply with quote

The problem we are facing with fog may apply to other gameplay aspects (for example, sliding while standing on top of non-BSP entities - this behavior can change depending the engine, and since this affects gameplay I believe it's a candidate to be standardized by QSB). I suggest that we should have a general on/off key to QSB defined features: let's create a cvar, say "qsb", if it's 1, then is expected that any QSB feature - fog, alpha, fullbrights, etc - will behave exactly as described in the QSB standard. If 0, the developer is free to make it behave as desired - including NOT having a different behavior at all.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Fri Jan 15, 2010 2:03 pm    Post subject: Reply with quote

I just want to point out there are at least a few established defacto standards already:

1. WinQuake: Standard Quake. MAX_EDICTS = 600 without transparent water.

Quake for DOS, WinQuake, GLQuake. Think "Day of Lords" version without transparent water http://www.quaddicted.com/reviews/gmsp3.html

2. Fitz 0.80/JoeQuake: Standard Quake plus more entities skybox, colored lits, fog, transparent water. MAX_EDICTS = 2048. Every modern engine already is expected to be able to load these maps and FitzQuake 0.80 and JoeQuake can run them all.

3. Fitz 0.85: Giant maps standard plus alpha support. FitzQuake 0.85 represents the baseline standard, especially since protocol 666 can reasonably be implemented since the changes between FitzQuake 0.80 and FitzQuake 0.85 are easy to determine (I ported the differences to the FitzQuake SDL in 6 hours --- it's not hard). aguirReQuake can load huge maps and had alpha support first, but due to the gradual limit busting, it would be difficult to isolate the changes.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
LordHavoc



Joined: 05 Nov 2004
Posts: 243
Location: western Oregon, USA

PostPosted: Fri Jan 15, 2010 2:09 pm    Post subject: Reply with quote

Urre wrote:
If I take a completely objective position for a moment, and ask, why is multiple protocol support a given? Why not do what frag.machine says, and just push things forward, making protocol 15 optional for QSB compatible engines? Where's the harm?


I'd like to point out that dropping protocol 15 means it can't play back the quake demos in id1, or any thirdparty ones, that is a very serious move.

Urre wrote:
Second, if fog (for hardware rendered engines) is to be included in the standard, it has to look the same among engines, consistency is key for all QSB features. I'm leaning towards making a second fog path, called qsb_fog, and let the engines keep their old fog under the old name, rendering it as they always have. qsb_fog however would have to look the same between engines.


An interesting approach, however if you insist that fog be table-based the generation method itself can be nailed down, and only the rendering method would vary.

DarkPlaces generates a fog table and applies it to vertices on old cards (pre-shader hardware), on slightly recent cards (shader hardware, DX9-class or higher) it uses a texture which represents the fog table exactly.

However DarkPlaces also has height fog, which has no place in a standard, yet is an important feature to mappers (especially because setting it near the roof of a level causes the skybox to remain visible through the fog, it is also possible to get above the fog in some levels with this in mind).

Urre wrote:
Which is the better choice: forcing old fog to look the same between engines and if the engine dev wants to keep their own fog look, they'll have to call it something else, or calling the new fog something else (qsb_fog, like above)?


No real opinion, but DP won't give up its existing fog, any standard fog would be an addition, not a replacement, so that's one engine with a firm position on the matter.

Now I want to point out something that is semi-tangential to standards but is very much a "raising the bar" matter: DP's lhnet.c + netconn.c implements a single-socket approach to quake networking, making clients able to connect to servers through a NAT firewall, this is a standard feature of quakeworld and later idtech engines, but among NQ engines it is unique. (ProQuake has a partial attempt at this, but only does so when connecting to ProQuake servers, and it can't host servers behind a NAT firewall, where as DP can with a port forward being set up as usual).

A second feature of netconn.c is that it implements a new protocol container which is preferred, which prevents qsmurf attacks (an exploit that causes a whole group of servers to flood an intended victim for 5 minutes), and interacts properly with the dpmaster master server.

I would very much like to see a tutorial released that upgrades the network layer to bring these features, regardless of the contained protocol, because multiplayer in any NQ engine other than DP is "difficult" to get going, and server browsing is a crucial feature as well.

This is an unreasonable demand of engine authors without a tutorial (it requires changes to sv_user.c because all client packets come in through one socket rather than separate ones for each connection), but with a tutorial it can be a required feature, and all would benefit.
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Fri Jan 15, 2010 2:14 pm    Post subject: Reply with quote

LordHavoc wrote:
DP's lhnet.c + netconn.c implements a single-socket approach to quake networking, making clients able to connect to servers through a NAT firewall, this is a standard feature of quakeworld and later idtech engines, but among NQ engines it is unique. (ProQuake has a partial attempt at this, but only does so when connecting to ProQuake servers, and it can't host servers behind a NAT firewall, where as DP can with a port forward being set up as usual).

A second feature of netconn.c is that it implements a new protocol container which is preferred, which prevents qsmurf attacks (an exploit that causes a whole group of servers to flood an intended victim for 5 minutes), and interacts properly with the dpmaster master server.

I would very much like to see a tutorial released that upgrades the network layer to bring these features, regardless of the contained protocol, because multiplayer in any NQ engine other than DP is "difficult" to get going, and server browsing is a crucial feature as well.


I've tried 2 or 3 times to port LHNET to ProQuake and have failed so far ... eventually I'll try again. I think I have attempted it about once every 9 months or so Very Happy

Your network code is vastly better and perfect as a replacement.

It successfully connects in multiple ip address situations and of course NQ needs a proper server browser which only DPMaster is going to be able to provide.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Fri Jan 15, 2010 4:29 pm    Post subject: Reply with quote

LordHavoc wrote:
Urre wrote:
If I take a completely objective position for a moment, and ask, why is multiple protocol support a given? Why not do what frag.machine says, and just push things forward, making protocol 15 optional for QSB compatible engines? Where's the harm?


I'd like to point out that dropping protocol 15 means it can't play back the quake demos in id1, or any thirdparty ones, that is a very serious move.


And I'd like to point out that I am not exactly advocating ditching protocol 15; I only demonstrated that supporting it isn't enough to keep an engine "vanilla Quake-compatible". Is not even enough to assure a vanilla client can always connect to a QSB server. That said, of course it's very desirable to at least support protocol 15 in demo playback, but for normal use it should be treated as deprecated - and FitzQuake 0.85 already does that, actually.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Fri Jan 15, 2010 4:41 pm    Post subject: Reply with quote

frag.machine wrote:
And I'd like to point out that I am not exactly advocating ditching protocol 15; I only demonstrated that supporting it isn't enough to keep an engine "vanilla Quake-compatible". Is not even enough to assure a vanilla client can always connect to a QSB server. That said, of course it's very desirable to at least support protocol 15 in demo playback, but for normal use it should be treated as deprecated - and FitzQuake 0.85 already does that, actually.


Demos, save games, connecting clients to other as a server.
_________________
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: Fri Jan 15, 2010 4:52 pm    Post subject: Reply with quote

Baker wrote:
frag.machine wrote:
And I'd like to point out that I am not exactly advocating ditching protocol 15; I only demonstrated that supporting it isn't enough to keep an engine "vanilla Quake-compatible". Is not even enough to assure a vanilla client can always connect to a QSB server. That said, of course it's very desirable to at least support protocol 15 in demo playback, but for normal use it should be treated as deprecated - and FitzQuake 0.85 already does that, actually.


Demos, save games, connecting clients to other as a server.

I think what frag.machine means here is that an engine should continue to support protocol 15 but only as a legacy mode for content that absolutely requires it (or if the server being connected to specifies 15 as the protocol). Otherwise it should default to something else with higher limits/better accuracy/more flexibility.
_________________
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
LordHavoc



Joined: 05 Nov 2004
Posts: 243
Location: western Oregon, USA

PostPosted: Fri Jan 15, 2010 5:10 pm    Post subject: Reply with quote

mh wrote:
I think what frag.machine means here is that an engine should continue to support protocol 15 but only as a legacy mode for content that absolutely requires it (or if the server being connected to specifies 15 as the protocol). Otherwise it should default to something else with higher limits/better accuracy/more flexibility.


For a time I killed support for hosting servers using old DP protocols, back in 2003 or so, and split off "lhnqserver" at the time, which was an nq server with support for everything possible without a modified protocol or modified limits.

But eventually I went back on the decision and added server support back for all old protocols, including 15 and the corresponding network layer features (so that stock quake could connect and play).

Having an unmaintained lhnqserver didn't solve the problem for me in the end, people wanting to record demos using darkplaces in protocol 15 for example, as well as host servers using protocol 15 (for a time there was one of these running at quakeone.com) with newer features than had ever been in lhnqserver.
Back to top
View user's profile Send private message Visit poster's website
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Fri Jan 15, 2010 5:50 pm    Post subject: Reply with quote

I took a different aproach in FTE. FTE servers attempt to use all supported protocols simultaneously, at least if they have the same default coord/angle size. Clients that don't support extra models don't get sent the entities. If the client doesn't support more than 256 sounds, the extra sounds will not be sent. For maps that don't require higher limits, nothing breaks. For maps that do require higher limits, things only break when you use a client that doesn't mutually support a protocol with sufficient limits.
A cvar to choose which engine to ban today is not a pretty feature.

Mapping engines are going to default to use whatever protocol provides the best limits. They're more for single player and it doesn't matter if its non-standard.
Multiplayer engines will probably default to protocol 15, as it gives them a wider clientel. They'd be stupid to ban 80% of their users simply because they *could* have a map that requires a limit 280 models.
My point is, a standardized protocol only works if its universal. And if it is universal, then its quite limiting. Thus FTE's protocols are optional extensions rather than versions.
_________________
What's a signature?


Last edited by Spike on Fri Jan 15, 2010 6:27 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
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 ... 12, 13, 14, 15, 16  Next
Page 13 of 16

 
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