maximqad

maximqad 

just a dev who ports fps to Dreamcast

4subscribers

2posts

goals1
$79.09 of $469 raised
BBA

Half-Life Dreamcast is back online!!

The engine's net_ws transport layer — the code that owns the UDP sockets and moves packets in and out — was replaced with stubs. They compile, they get called, they return cleanly, and they do nothing. Look at the executable's import table and there is no winsock at all: the binary has no way to open a socket even in principle.
The gutting goes past the transport. Chunks of the client that only matter when other players exist were trimmed or narrowed on the assumption that nobody would ever be online. The multiplayer menu leads nowhere.
And the disc's copy of Windows CE was built without a networking component either, so even a fully repaired game would have nothing underneath it.
Two separate problems: no network stack in the OS, and no networking in the game.
The OS side: a CE image that can actually reach the network
A Dreamcast disc carries its own small operating system (0WINCEOS.BIN) that boots before the game does. That image is where the TCP/IP stack lives, and the shipped one doesn't have one.
So it gets rebuilt. Rather than bolting on a third-party stack, the replacement image drives the stock CE networking stack — microstk.exe and winsock.dll, the same components Sega shipped — over real hardware. The trick is at the link layer: CE's dial-up PPP driver (mppp.dll) is swapped for a drop-in shim exposing the same driver interface, but backed by the Broadband Adapter. The stack above it never knows the difference. If there's no BBA present, the shim hands off to the original PPP driver and dials out over the modem instead.
The result is a stock CE userland with working DHCP, DNS, TCP and UDP. Rebuilding the image is also where the disc gets told to autorun the game directly, and where a serial console can be enabled for debugging.
Crucially, this is what gives the patch a real winsock.dll to link against — the retail image has none.
The game side: a payload DLL and a static patcher
There's no source, so the executable is modified in place. Two components:
hldcnet.dll — a small SH-4 CE DLL holding the replacement networking and fixes.
hlpatch — a static patcher that rewrites HALFLIFE_DC.EXE so it loads and uses that DLL.
Getting the DLL loaded
The patcher appends a new PE section to the executable and rebuilds the import directory inside it: every original descriptor, plus one more for hldcnet.dll, with its own lookup and address tables. Nothing needs to inject anything at runtime — the CE loader sees a normal import and maps the DLL into the game's process at startup, like any other dependency. Our code ends up in the engine's address space, with the same view of memory it has.
Replacing the transport
Each of the six gutted NET_* entry points gets a trampoline patched over its first instruction, jumping through an import slot into the corresponding export in hldcnet.dll. The engine calls what it thinks are its own functions; execution lands in a real UDP implementation built on the CE image's winsock.
That implementation has to be faithful to GoldSrc, not merely functional — including reassembling SPLITPACKET fragments, since the protocol splits oversized messages across multiple datagrams and the engine expects them whole.
Hooks for everything else
Working sockets get packets flowing; they don't make the client survive a second player. The rest of the patch is a set of hooks installed by repointing call literals to thunks that vector into the DLL, covering the parse paths for server info, player info and client state, plus disconnect and shutdown handling.
Behind those hooks the patch also repairs the data structures the port narrowed: the per-frame client state is enlarged so it can hold more than one player's worth of data, backed by a shadow buffer that the parse hooks mirror into, and a sound-index table is restored that multiplayer needs and the port dropped.
Subscription levels0
No subscription levels
Go up