Progress progress progress. Never enough, but more than before. Time for an update.
Less Is More
In my last post, I bemoaned the amount of programmer’s debt in the A&A code. So, how bad was it? In the networking code, there was over 70 different types of packets. Gratuitous editing has taken this down to 9. There was a large number of packets used in the client/server model that were no longer needed. Many functions were just hanging around in the hope of being used again, but I find this was just distracting and making the core concepts even harder to identify. They had to go and I’ve proceeded to pluck them out one by one. Removing one packet would then lead to a section of code that handles the packet and even more dead subsystems (such as the file transfer routines that are no longer used, or the mechanics for handling a server side store).
I can hear the question from the audience, “But won’t you need that sometime.” And the answer is, “Maybe.” Yes, I admit some of these features will be needed again, but they are not needed now. And, I still have copies of the original code with those features. But for now, its about getting back to the core.
The Magic Number
And getting to the core has allowed me to fix some of the problems plaguing the join/start system. But I got tripped up with a crazy bug that totally eluded me for the longest time. Here are a few details.
One of the goals I set out for this new networking is to allow players from DOSBox and Windows play games with each other. Someone with a Linux or Mac could use the DOSBox version and link up with another with a Windows player. It seemed like a neat idea and since DOSBox’s code was available for doing IPX networking, I decided to pull it out and set it up in the A&A Server program I wrote (you can use the DOSBox server as well, the A&A Server is just a self standing version). Upon making the A&A Server, I found that it worked — or so I thought. Before all of my networking changes, two DOSBox instances could use the A&A Server and talk to each other. Cool.
Then I added the Windows port and setup the networking code. I then proceeded to test two Windows instances on the A&A Server and that worked. Cool also.
However, when I mixed Windows and DOS programs, I found that Windows instances could see DOSBox output, out DOSBox instances could never see Windows instance output. What? Makes you want to sit down and make a logic puzzle or diagram out of it.
At first, I thought it was a problem with the A&A game code. Perhaps the code was compiling differently between DOS and Windows. Nope.
Finally, I pulled out Wireshark — the best tool for debugging networks. I wish we had this tool back in 1995. It would have saved me a ton of time. Looking very closely at the packets coming from DOSBox and Windows, I finally found the problem — the Magic Number. Well, that’s not its real name. The real name is IPX socket number.
The IPX network is a different networking system than TCP/IP. Novell’s Netware system was a contender (more or less) to the networking world way back, but it never did scale up like TCP/IP did on big networks, so it fell by the wayside. But it had a similar concept called a socket number … usually known as a port number. There are plenty of details here I’ll skim over (such as a source and destination port number and how they’re assigned), but let’s just call it a magic number. The problem is that when I created the Windows software, I accepted all IPX packets regardless of their destination port number. DOSBox does too. So, where is the problem?
When creating A&A, I setup a system where a different networking driver can be loaded before the A&A program is run. There were three versions: One for serial, one for modem, and one for IPX. We use the serial port one for single player mode too, but it doesn’t talk out the port. Anyway, when I went to start adding debug code to the IPX driver version, I found it — the magic number. That IPX driver would filter packets that didn’t have a port destination of … drum roll please … 0x869C (34460). The IPX Driver is only used by the DOSBox version. And only incoming packets were filter. The windows version was using the TCP/IP port number (213) instead of the magic number (0x869C). Thus, the DOSBox version would not talk to any packets coming from a Windows instance, but Windows would not filter and accept anything that came from the rest of the computers.
Changing 213 to 0x869C fixes the problem and now everyone can talk to everyone. Problem solved.
With these changes, I can now have 3 players start a game, see each other in the 3D world, and affect it. Too bad I’m still having instability problems and a few other known issues. But I was excited to see the players finally on a map. They also seem to move smoothly. That’s nice!
Then I noticed all the graphical errors when a player attacks and how players slide instead of walk. Sigh.
But my goal is simple: Setup a server where many players can meet (community server or personal server), join up in groups up to 4, and play through the original levels. And I want it all stable.
Slowly but surely, we’ll get there.