===================================== = = = Communicating with 3DRealms Games = = Version 1.0 = = February 12, 1996 = = Written by Mark Dochtermann = = = ===================================== INTRODUCTION A number of 3DRealms games use the same network/serial interface known as COMMIT. COMMIT itself is an ipx/netbios/serial/modem communications package that simplifies the task of getting connected. If you want to write a custom driver to replace COMMIT you must follow the specifications described in this text. GENERAL All communication between the driver and the game program is done through a shared data structure. This data structure is passed into the game program by its flat linear address. This structure is called the GAMECOM structure and from here on will be referred to as such: typedef struct { short intnum; // Game executes an int to send commands // communication between Game and the driver short command; // CMD_SEND or CMD_GET short remotenode; // dest for send, set by get (-1 = no packet) short datalength; // bytes in data to be sent / bytes read // info specific to this node short consoleplayer; // 1-numplayers = player number short numplayers; // 1-MAXPLAYERS short gametype; // 1 = SERIAL, 2 = MODEM, 3 = NETWORK short extra; // extra short for 4-byte alignment // packet data to be sent char data[MAXPACKETSIZE]; } gamecom_t; GAMECOM contains all information necessary to communicate between the game and the driver. The GAMECOM structure is modified by protected mode and by your driver asynchronously, therefore it is recommended not to modify it until you absolutely need to. If the interface requests a packet and a packet is not ready, the partial packet should not be copied into the GAMECOM structure. When the GAMECOM packet is initially passed into a game it must have certain critical information set in it. This information includes: number of players, local player number, communication type, interrupt vector. - intnum (interrupt vector) The interrupt on which all calls to the communications driver are made. - numplayers (number of players) The total number of players in a game. This value can have a value of [1..MAXPLAYERS]. - consoleplayer (local player number) the player number of the local system. This value can have a value of [1..MAXPLAYERS]. Player 0 should always be the local address as well, so if the local system, is player 2, the addresses would look something like this: 0 - local system 1 - player 1's system 2 - local system ... - gametype (communication type) The communication type used in this game. This parameter isn't very useful and usually has no consequence inside the game itself. Its possible values: 1 - SERIAL a local serial game 2 - MODEM a modem game 3 - NETWORK any game going over a network Once the game has been set up, the communication between the driver and the game is all done through GAMECOM commands. The commands are as follows: #define CMD_SEND 1 #define CMD_GET 2 #define CMD_SENDTOALL 3 #define CMD_SENDTOALLOTHERS 4 #define CMD_SCORE 5 Upon receiving CMD_SEND, CMD_SENDTOALL, or CMD_SENDTOALLOTHERS, the driver should take the data in the data portion of GAMECOM (the length og the data specified by datalength), and send it to the appropriate destination as follows: CMD_SEND - Send packet to the player number specified in GAMECOM's remotenode. CMD_SENDTOALL - Send packet to everyone in the game including a local echo. This command is pretty rarely used because of the local echo. CMD_SENDTOALLOTHERS - Send packet to everyone except yourself (the local player number specified in consoleplayer in GAMECOM) Upon receiving CMD_GET, the driver should check to see if it has a packet ready for the game, and if it does copy the packet into the data portion of GAMECOM and fill in the GAMECOM datalength. You should also set the address of the player who sent the packet in GAMECOM remotenode. If no packets are ready, the driver should set GAMECOM's remotenode to -1 to inform the game that no new packets are ready. The CMD_SCORE command is provided to allow score extensions to be added to a particular game and allow outside drivers to access these scores. Since the implementation of a SCORE packet is different from game to game, no useful information can be given here. It is recommended that you manage your own stack when calling your driver code since the transfer stack provided by the dos extender may not be large enough for your driver. Please Refer to game specific documentation for idiosyncracies of a certain game. Happy Programming, Mark D PARADIGM @ METRONET.COM