Leading the way in newschool multiplayer Doom online
https://zandronum.com/forum/
That was the plan. Major version would increase on ZDoom base upgrades and the minor version was what used to be the letter.AlexMax wrote: I think Zandronum's versioning should be pretty simple. Feature releases should increase the major version number and put the minor version at 0, bugfix releases should increase the minor version number. What do you think?
The thing is, as many open source projects have come to realize (including the Linux kernel), the major version number, in a traditional sense, is no longer significant. ZDoom and thus Zandronum do not intend to ever break the API so if you take the traditional route of increment on API breakage would mean we'd be on 1.x forever. The solution is to drop the major version or use the date as the version number. However, if you're going to use the "rapid release" scheme then you need to use it now. Otherwise you end up like Firefox where people think you did it purly for marketing reasons.Torr Samaho wrote: I'm not completely sure when we should increase the major and when the minor version number. If we upgrade our base from ZDoom 2.3.1 (which is approximately what we have now) to 2.4.1 (which is a conservative but realistic goal for the version following Zandronum 1.0), increase the major version number for this and follow this strategy, we may end up having a much higher version number than ZDoom in the not too distant future. We could make it more like ZDoom and use two minor numbers.
Good argument. So far I disliked the rapid release version numbering model Firefox and Chrome are using, most likely because I'm used to the more traditional model and the new one feels so inflationary. But your argument makes sense, there is no real need to fix the major revision for ages. So let's give the modern system a try.Blzut3 wrote: The thing is, as many open source projects have come to realize (including the Linux kernel), the major version number, in a traditional sense, is no longer significant. ZDoom and thus Zandronum do not intend to ever break the API so if you take the traditional route of increment on API breakage would mean we'd be on 1.x forever.
Spoiler: For great justice. (Open)These are some of the versioning features that come off the top of my head -- I remember having spent some time engineering the initial byte values of the MASSTER auth system in such a way to naturally take advantage of this "ignore the extra bits" system, and enable alternate Huffman trees optimized for various game modes -- Invasion, Deathmathch, etc, as well as different compression trees/dictionaries on a per WAD basis. In fact, I found a few full network logs and profiling stat tables I made back then for various game modes, but the exact protocol itself resides unsafely locked away in Carney's forum data... Though unlikely, I wonder if he could be reasoned with to give us a SQL dump of our data?
I have a copy of the database, although it has seen its damage from the post disappearance incident that happened a few months ago so there is a likely chance it could be lost. Tell me what to look for and I'll retrieve your protocol.VortexCortex wrote: In fact, I found a few full network logs and profiling stat tables I made back then for various game modes, but the exact protocol itself resides unsafely locked away in Carney's forum data... Though unlikely, I wonder if he could be reasoned with to give us a SQL dump of our data?
Code: Select all
| | | |Spoiler: E.G. (Open)Cross referencing posts containing 'Huffman' and/or 'SkullCrusher' with 'VortexCortex' as the author may also yield the post(s).
The more you tell about it, the more useful your proposed versioning sounds :). If you have the time to create patches, that would be great!VortexCortex wrote: If needed, I could schedule the time to create and test the necessary patches.. (..and compatibility with IDE... in a VM, Still closed source, ya?)
I think Eruanna still has a copy of the .net forum database. So if the post we are looking for was written on skulltag.net, it should be in there.Wartorn wrote: I have a copy of the database, although it has seen its damage from the post disappearance incident that happened a few months ago so there is a likely chance it could be lost. Tell me what to look for and I'll retrieve your protocol.
Code: Select all
prefix_byte_value = ... // get the first byte of packet data.
number_of_data_bytes = number_of_packet_bytes - 1; // Account for the protocol's "signal/padding" byte.
if ( prefix_byte_value == 0xFF )
{
    ... // Return the data bytes unchanged (not encoded mode)
}
number_of_data_bytes * 8 = total_data_bits;
number_of_huffman_encoded_bits = total_data_bits - prefix_byte_value;
... // Huffman decode the number_of_huffman_encoded_bits from the data bytes.
       ÂCode: Select all
Signal byte bit Values.  7 = Most significant bit
.--------------------------------------
|
|Â Â Â Â 7Â 6Â 5Â 4Â 3Â 2Â 1Â 0Â Â
|Â Â Â Â |Â |Â |Â |Â |Â |Â |Â |Â Â
|    | | | | | x x x = Numeric value [0 to 7]
|    | | | | |         Number of Padding Bits (used with variable bit length encodings)
|    | | | | |         or Message Flags Field (used with Unencoded mode)
|Â Â Â Â |Â |Â |Â |Â |
|    | | | | x ----- = Encoding Negotiation Flag
|    | | | |           1: An encoding negotiation byte has been appended after the last byte of data.
|    | | | |           0: No negotiation byte exists.
|Â Â Â Â |Â |Â |Â |
|    x x x x ------- = Numeric value [0 to 15]
|                      Encoding Identification Signal
|
`---------------------------------------
Code: Select all
Message Identification Signal.  7 = Most significant bit
.--------------------------------------
|
|Â Â Â Â 7Â 6Â 5Â 4Â 3Â 2Â 1Â 0Â Â
|Â Â Â Â |Â |Â |Â |Â |Â |Â |Â |Â Â
|    | | | | | | x x = Numeric Value [0 to 3]
|    | | | | | |       Error Code
|    | | | | | |       0: No error, a normal regular unencoded data message.
|    | | | | | |       1: Unsupported Encoding
|    | | | | | |          The previously received data encoding is not supported.
|    | | | | | |       2: Corrupt Data
|    | | | | | |          The previously received data did not decode properly.
|    | | | | | |       3: Connection Refused
|    | | | | | |          For some reason the connection was refused, and no further
|    | | | | | |          data should be sent (at least for a while)
|Â Â Â Â |Â |Â |Â |Â |Â |
|    | | | | | x---- = Request for Protocol Negotiation
|    | | | | |         1: Request that a reply contain Encoding Negotiation.
|    | | | | |         0: Encoding negotiation not requested from the other party.
|Â Â Â Â |Â |Â |Â |Â |
|    x x x x x------ = These bits are beyond the MID scope.
|
`---------------------------------------
Code: Select all
.------------------------------------------------------------------------------------------.
|     Encoding ID Value    |                 Description of Encoding Mode                  |
| Hex .  Binary  . Decimal |                                                               |
|-----|----------|---------|---------------------------------------------------------------|
|  0  |   0000   |     0   |  Legacy Huffman: Data is encoded using a Huffman Tree         |
|     |          |         |      that is compatible with the original huffman.cpp         |
|-----|----------|---------|---------------------------------------------------------------|
|  1  |   0001   |     1   |  Improved Huffman: Data is encoded using a newly calculated   |
|     |          |         |      Huffman tree, and bytes do not have reversed bit order   |
|-----|----------|---------|---------------------------------------------------------------|
|  2  |   0010   |     2   |  Skull Crusher: Data is compressed using a custom algorithm   |
|     |          |         |      that utilizes two Huffman trees and a sliding "window"   |
|-----|----------|---------|---------------------------------------------------------------|
|Â 0x3Â |Â Â Â 0011Â Â Â |Â Â Â Â Â 3Â Â Â |Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â |
|  to |    to    |   to    |     Available for future expansion of the STONE Protocol      |
|Â 0xEÂ |Â Â Â 1110Â Â Â |Â Â Â Â 14Â Â Â |Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â |
|-----|----------|---------|---------------------------------------------------------------|
|  F  |   1111   |    15   |  Unencoded Mode: data bytes use the 1:1 (identity) encoding,  |
|     |          |         |     a "no op" raw data mode also used for error code replies  |
`------------------------------------------------------------------------------------------'
Code: Select all
Encoding Negotiation byte bit Values.  7 = Most significant bit
.--------------------------------------
|
|Â Â Â Â 7Â 6Â 5Â 4Â 3Â 2Â 1Â 0Â Â
|Â Â Â Â |Â |Â |Â |Â |Â |Â |Â |Â Â
|    | | | | x x x x = Numeric value [0 to 15]
|    | | | |           Minimum Encoding Level value
|Â Â Â Â |Â |Â |Â |Â Â
|    x x x x ------- = Numeric value [0 to 15]
|                      Maximum Encoding Level value
|
`---------------------------------------
Code: Select all
.------------------------------------------------------------------------------------------.
|   Encoding Level Value   |                 Description of Encoding Mode                  |
| Hex .  Binary  . Decimal |                                                               |
|-----|----------|---------|---------------------------------------------------------------|
|  0  |   0000   |     0   |  Unencoded Mode: data bytes use the 1:1 (identity) encoding,  |
|     |          |         |     a "no op" raw data mode also used for error code replies  |
|-----|----------|---------|---------------------------------------------------------------|
|  1  |   0001   |     1   |  Legacy Huffman: Data is encoded using a Huffman Tree         |
|     |          |         |      that is compatible with the original huffman.cpp         |
|-----|----------|---------|---------------------------------------------------------------|
|  2  |   0010   |     2   |  Improved Huffman: Data is encoded using a newly calculated   |
|     |          |         |      Huffman tree, and bytes do not have reversed bit order   |
|-----|----------|---------|---------------------------------------------------------------|
|  3  |   0011   |     3   |  Skull Crusher: Data is compressed using a custom algorithm   |
|     |          |         |      that utilizes two Huffman trees and a sliding "window"   |
|-----|----------|---------|---------------------------------------------------------------|
|Â 0x4Â |Â Â Â 0100Â Â Â |Â Â Â Â Â 4Â Â Â |Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â |
|  to |    to    |   to    |     Available for future expansion of the STONE Protocol      |
|Â 0xFÂ |Â Â Â 1111Â Â Â |Â Â Â Â 15Â Â Â |Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â |
`------------------------------------------------------------------------------------------'
Code: Select all
// From EID to EL
ELÂ =Â EIDÂ +Â 1Â &Â 0xF;
// From EL to EID (avoids underflow for cross language independence)
EID = (EL == 0) ? 15 : EL - 1;
    ÂCode: Select all
void HUFFMAN_Decode( unsigned char *in, unsigned char *out, int inlen, int *outlen )
{
    // sanity check for *outlen.
    if ( (*outlen < 1) ){
        *outlen = 0; // zero it incase it's some wild negative.
        return;
    }
    int bits,tbits,maxBits;
    huffnode_t *tmp;
    if (*in==0xff) // The first byte is 11, so this won't happen.
    {
        // This block is only executed if StEP sends 255 when LCM is enabled.
        memcpy(...);Â
        return;
    }
    // Ah... I just love the next error prone line of code.
    // I immediately realized it as "Magic", and left it just the way it is :)
    tbits=(inlen-1)*8-*in;
    // Here's what happens:
    // tbits = (9 - 1) * 8 - 11;
    //   inlen--^             ^--- this value is exactly 8 bits more than the 3 padding bits expected...
    // Remember that extra negotiation byte (8 bits) we appended?  It's now fully ignored!
    bits=0;
    // Calculate the max bits from output size.
    maxBits = *outlen << 3; // shift 3 faster than * 8 :)
    *outlen=0;
    while ((bits<tbits) && (bits<maxBits)) // added check.
    {
        // Omitted: decode bytes from the input bits.
        // This section gets skipped when StEP unencoded mode launcher queries arrive :)
    }
}
   Â