Inside3D!
     

Engine standards for mod compatibility
Goto page Previous  1, 2, 3 ... 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
frag.machine



Joined: 25 Nov 2006
Posts: 728

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

mh wrote:
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.


Bingo. Wink

Please note that by deprecated I mean "unless your explicitly says you want protocol 15 I'll use my own". And that a forced switch to protocol 15 should be one sign (maybe not the only) to disable QSB features, or at least those which depend of protocol 666/667/whatever. In other words, the engine switches to a non-QSB mode, and thus no QSB behaviors are guaranteed.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/


Last edited by frag.machine on Fri Jan 15, 2010 5:58 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
Teiman



Joined: 03 Jun 2007
Posts: 309

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

All network features of Telejano are plug-and-play, the client ask the server, and if the server agree, are enabled. This has a limited use... probably it will make changes on the size of things a pain.

Theres also a special evil mode, "SinglePlayer" where commands like "sound" bypass the network and directly spawn a sound. This mode is disabled wen saving a demo, or playing online/multiplayer. Is there for perfomance reason, but the gain seems minimal or null.
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Sat Jan 16, 2010 3:45 am    Post subject: Reply with quote

Spike wrote:
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.

You touch on a very good point here. To what extent are protocol extensions only going to be of benefit to the SP part of the community?
_________________
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: Sun Jan 24, 2010 11:27 pm    Post subject: Reply with quote

I'm still torn on where we are concerning the protocol discussion. I'd really want to up some networking related limits, but I'm not sure if expecting multiple protocol support is reasonable to ask for, and it feels hard for me to tell which limits break networking and which don't.
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Mon Jan 25, 2010 12:48 pm    Post subject: Reply with quote

As I understand is, fog is commonly additive-blended, meaning black fog wouldn't be possible for example? Would it be too much to ask for multiply-blended fog?
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Mon Jan 25, 2010 12:55 pm    Post subject: Reply with quote

A good start for multi-protocol support can be found here: http://www.quake-1.com/docs/quakesrc.org/107.html

It needs a little work for sure, such as moving the protocol selection from a command-line option to an sv_protocol command, but it does show how easy it really is.
_________________
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: Mon Jan 25, 2010 1:03 pm    Post subject: Reply with quote

Urre wrote:
As I understand is, fog is commonly additive-blended, meaning black fog wouldn't be possible for example? Would it be too much to ask for multiply-blended fog?


No, it is alpha blended, it can be black.

Additive blended fog would be immensely easier to implement, it avoids a ton of issues, which is why Unreal1 only had additive fog (technically the fog was a type of lightsource), Doom3 also had volumetric fog areas as a lightsource but it did alpha blend on it (somehow).

Additive fog is really easy, but no one uses it.
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Sat Feb 06, 2010 8:10 pm    Post subject: Reply with quote

frag.machine wrote:
- raised engine limits. I am assuming a list based in FitzQuake 0.85 and my current engine incarnation:
Code:

    MAX_HANDLES             10                  100
    MINIMUM_WIN_MEMORY      0x01000000 (16Mb)   0x02000000 (32Mb)
    MAXIMUM_WIN_MEMORY      0x04000000 (64Mb)   0x08000000 (128Mb)
    CON_TEXTSIZE            16384               262144                 
    MAX_FARCLIP             4096                16384                   
    MAX_EDICTS              600                 8192 (*)                   
    NET_MAXMESSAGE          8192                65536 (****)                   
    MAX_STATIC_ENTITIES     128                 1024
    MAX_MAP_LEAFS           8192                32768 (**)
    MAX_LIGHTMAPS           64                  256
    NUMSTACKSURFACES        800                 8192                   
    NUMSTACKEDGES           2400                8192                   
    MAX_VISEDICTS           256                 MAX_EDICTS
    MAX_DATAGRAM            1024                32768
    MAX_MSGLEN              8000                65536 (****)
    MAX_STACK_DEPTH         32                  256
    MAX_EFRAGS              640                 2048
    MAX_CHANNELS            128                 512
    MAX_DYNAMIC_CHANNELS    8                   128
    MAX_MAP_CLIPNODES       32767               65535 (**)
    MAX_GLTEXTURES          1024                2048 (***)
    MAX_TEMP_ENTITIES       64                  1024
    DYNAMIC_SIZE            49152               262144
    MAX_BMODEL_VERTS        500                 1000
    MAX_BMODEL_EDGES        1000                3000
    MAXALIASVERTS           1024(GL),2000(SW)   4096                   
    MAXALIASTRIS            2048                4096
    MAX_LBM_HEIGHT          480                 1024
    ABSOLUTE_MIN_PARTICLES  512                 1024
    MAX_PARTICLES           2048                16384
    MAX_MODELS              256                 2048 (*)
    MAX_SOUNDS              256                 2048 (*)
    MARKSURFACES            32767               65535 (**)
    FACES                   32767               65535 (**)
    NODES                   32767               65535 (**)
    MAX_BEAMS               24                  32
    MAX_DLIGHTS             32                  64
       
   (*) = requires new network protocol
  (**) = as LordHavoc pointed out, should be implemented in a non-hacky way (replacing short values with 32-bit ints)
 (***) = OpenGL specific
(****) = See FitzQuake README.TXT about multiplayer games sticking to 1400 bytes due network limitations


I'm opting to use this list as a base instead of the Engine Limits page on the wiki, as it got a bit confusing. I have a couple of questions though.
  • What's typically limiting the new value you posted? Why not make everything as high as physically possible while you're at it? Can "too high" values get hard to implement?
  • You put a star next to ones which require a new network protocol, which is great, but are there any ones in the list which you didn't put a star next to which would require a protocol change if bumped even higher?


There are some which I don't understand, and some which I'm wondering if they are related to modding and mapping:
  • What is CON_TEXTSIZE?
  • What is MAX_DATAGRAM?
  • What is MAX_STACK_DEPTH?
  • What is DYNAMIC_SIZE?
  • What on earth are MINIMUM_WIN_MEMORY and ABSOLUTE_MIN_PARTICLES? Minimum values? Huh?
  • Is MAX_LBM_HEIGHT max skin height?

Have I misunderstood some of the others, considering how I've categorized them on the wiki page.

I've increased some of the limits compared to your list already, feel free to point out which were a dumb idea and why. Thanks for an awesome list!
_________________
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: Sat Feb 06, 2010 10:38 pm    Post subject: Reply with quote

Urre wrote:
What's typically limiting the new value you posted? Why not make everything as high as physically possible while you're at it? Can "too high" values get hard to implement?


Most of these values are a compromise between what's needed to reasonably extend the engine capacities and the minimum hardware platform aimed. Since Quake is an old game, it's logical to expect that people with old hardware will want to run it (I am using my 6-year old notebook, a P4-266MHz machine with 512Mb of RAM and a crappy Trident 3D accelerator, as target in this case). Of course, there's nothing really preventing one to bump, let's say, MAXIMUM_WIN_MEMORY to 256Mb or 512Mb. I took a very conservative approach in this list, but as I said in the original message, it was just something to serve as a starting point.

There are a number of other factors one must take in account when increasing engine limits. For example, MAX_MAP_LEAFS cannot be increased beyond the 32K limit without breaking compatibility with BSP 29 format (in this file format, leaf data is stored as a signed 16-bit integer). MAX_LIGHTMAPS is another limit related to this BSP version.

Urre wrote:
You put a star next to ones which require a new network protocol, which is great, but are there any ones in the list which you didn't put a star next to which would require a protocol change if bumped even higher?


None that I am aware of.

Urre wrote:
There are some which I don't understand, and some which I'm wondering if they are related to modding and mapping:
What is CON_TEXTSIZE?


Just controls the console buffer size, not directly related to modding.

Urre wrote:
What is MAX_DATAGRAM?

Code:

quakedef.h(102): #define    MAX_DATAGRAM        32000   // max length of unreliable message //johnfitz -- was 1024


As pointed out by others, this new value can become a problem for multiplayer engines. For single player dedicated engines the 32K value seems to be safe.

Urre wrote:
What is MAX_STACK_DEPTH?


This constant sets the size of the QuakeC interpreter stack. Not directly related to modding, but having low values for this can prevent execution of highly recursive QuakeC code (i.e. when you have QC functions calling itself recursively). So far I haven't found any example in real life, though - recursive code is a fairly sofisticated programming technique.

Urre wrote:
What is DYNAMIC_SIZE?


This defines the size of the temp string zone memory. This memory area stores mostly temporary strings, created when executing code like this:
Code:

bprint (ftos (self.health));


Urre wrote:
What on earth are MINIMUM_WIN_MEMORY and ABSOLUTE_MIN_PARTICLES? Minimum values? Huh?


Yes. MINIMUM_WIN_MEMORY is the minimum ammount of required memory by Quake, even if you force a lower value by command line arguments. Likewise, ABSOLUTE_MIN_PARTICLES is the minimal number of particles the engine will support, even if you try to force a lower value by command line arguments.

Urre wrote:
Is MAX_LBM_HEIGHT max skin height?


Yes.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Sun Feb 07, 2010 2:18 am    Post subject: Reply with quote

MAX_HANDLES - internal to engine, shouldn't affect modding (maybe FRIK_FILE).

CON_TEXTSIZE - number of characters in the console buffer. Does not enforce a number of lines or width. Wide resolutions will have less lines buffered.

MAX_DATAGRAM - this is the maximum unreliable data size. This actually contains all that is unreliable. This includes the entities between each frame. Sizes greater than your link MTU (generally 1500 as specified by ethernet) will result in fragmentation. Packetloss will effectively double for packets over the limit. It is best to avoid the need for a high limit, but a high limit is not inherantly bad.

MAX_MSGLEN - The maximum size of a reliable message. The limit is encountered mostly only as part of the new map svc_serverinfo.

MAX_STACK_DEPTH - maximum number of functions that can be recursively called in QC. This doesn't include the limit for the locals. That's a different limit.

MAX_GLTEXTURES - a greater issue is perhaps that some maps have different textures from others but the same name. Flushing unused may be better than blindly increasing the limit.

DYNAMIC_SIZE - This is strzoned strings, not temporary strings (all engines I know of that do use dynamic memory for temp strings have reworked the dynamic memory code to potentially allocate as much as 4gb, or more on a 64bit cpu :) ).

MAXALIASVERTS - note to implementors. gl_mesh.c is buggy crap.
MAXALIASTRIS - note to implementors. gl_mesh.c is buggy crap.

MAX_LBM_HEIGHT - the maximum size is limited by other factors. a 3dfx card supports only up to 256*256. This is bound by gl_maxsize (it'll silently downsample).

MAX_DLIGHTS - more than 32 is really not pretty. This is not a simple limit change.
_________________
What's a signature?
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: Sun Feb 07, 2010 10:07 am    Post subject: Reply with quote

Spike wrote:
MAX_HANDLES - internal to engine, shouldn't affect modding (maybe FRIK_FILE).


Affects how many paks you can have loaded across all active gamedirs.

Spike wrote:
MAX_DATAGRAM - this is the maximum unreliable data size. This actually contains all that is unreliable. This includes the entities between each frame. Sizes greater than your link MTU (generally 1500 as specified by ethernet) will result in fragmentation. Packetloss will effectively double for packets over the limit. It is best to avoid the need for a high limit, but a high limit is not inherantly bad.


Actually all UDP fragments are automatically dropped on the internet, because their fragment index is 16bit and has a high probability of wrapping multiple times per second on gigabit or multi-gigabit internet backbone links, leading to silent data corruption - hence UDP fragments are simply killed.

So the only safe values for MAX_DATAGRAM are 1400 or less, you won't be able to go online with more than 1450 and some tunneling protocols (think Hamachi for virtual lan gaming and other VPN software) will have problems with values much above 1400.

Spike wrote:
MAX_DLIGHTS - more than 32 is really not pretty. This is not a simple limit change.


Yeah because R_MarkLights and R_BuildLightmap use a single unsigned int for all the dlight flags on each surface (which dlights are illuminating this surface), hence 32 is the hard limit without changing how the flags are stored.
Back to top
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Sun Feb 07, 2010 2:20 pm    Post subject: Reply with quote

This discussion about the proposed new limits brings another problem to light: the current artwork (maps, textures, alias models, etc) file formats and how they are quickly becoming the bottleneck for the natural evolution of the engines. I believe that in the event of a QSB 2.0 standard we should consider the option of new, more flexible file formats and then maybe a set of migration tools. For now I think is best to just stick to the current ones for simplicity sake.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Team Xlink



Joined: 25 Jun 2009
Posts: 320

PostPosted: Sun Feb 07, 2010 4:48 pm    Post subject: Reply with quote

frag.machine wrote:
This discussion about the proposed new limits brings another problem to light: the current artwork (maps, textures, alias models, etc) file formats and how they are quickly becoming the bottleneck for the natural evolution of the engines. I believe that in the event of a QSB 2.0 standard we should consider the option of new, more flexible file formats and then maybe a set of migration tools. For now I think is best to just stick to the current ones for simplicity sake.


If the QSB 2.0 standard did have new file formats would it still be compatible with the original ones? If not would all of the original Quake artwork have to be converted or would it be redone?
_________________
Anonymous wrote:
if it works, it works. if it doesn't, HAHAHA!
Back to top
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Sun Feb 07, 2010 5:03 pm    Post subject: Reply with quote

it wouldn't be quake if it didn't run existing mods.
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
Chip



Joined: 21 Jan 2009
Posts: 314
Location: Romania

PostPosted: Sun Feb 07, 2010 5:22 pm    Post subject: Reply with quote

Spike wrote:
it wouldn't be quake if it didn't run existing mods.


Exactly, don't go write a new game. Just improve existing Quake.
_________________
My Projects: Quake 1 Mods | OpenQuartz 2 | ChipQuake
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 ... 13, 14, 15, 16  Next
Page 14 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