Post

First connection from Xash3D FWGS to GoldSrc (ReHLDS) server with its native protocol.

==== Some nerd stuff ====
Xash3D natively supports writing and reading bit by bit. Whether it's a usual 8-bit or less usual 11-bit integer, it's always encoded the same way.

As I said in a previous post, in GoldSrc, Valve, instead of properly rewriting buffer ops to support bit IO, just hacked it on top of existing Quake code. So this creates a significant issue on how signed values written as bytes and signed values written as bits are encoded. 

In bit encoding mode, sign bit comes first, when in Xash it always in the end. In byte encoding mode, like in Quake, integers are little endian encoded, meaning the sign bit is in the last byte.

From this point, I don't know how to "simply" support the GoldSrc protocol. I guess that's the end, until I come up with some idea (and probably take apart and rewrite the whole engine)

First connection from Xash3D FWGS to GoldSrc (ReHLDS) server with its native protocol. ==== Some nerd stuff ==== Xash3D natively supports writing and reading bit by bit. Whether it's a usual 8-bit or less usual 11-bit integer, it's always encoded the same way. As I said in a previous post, in GoldSrc, Valve, instead of properly rewriting buffer ops to support bit IO, just hacked it on top of existing Quake code. So this creates a significant issue on how signed values written as bytes and signed values written as bits are encoded. In bit encoding mode, sign bit comes first, when in Xash it always in the end. In byte encoding mode, like in Quake, integers are little endian encoded, meaning the sign bit is in the last byte. From this point, I don't know how to "simply" support the GoldSrc protocol. I guess that's the end, until I come up with some idea (and probably take apart and rewrite the whole engine)

Aynekko
Aynekko
Aug 31, 2023

How come this doesn't have any likes? This is impressive!