home *** CD-ROM | disk | FTP | other *** search
/ Total Meltdown / dukenukemtotalmeltdown.img / util / dukenet / readme.txt < prev   
Text File  |  1996-02-14  |  5KB  |  121 lines
  1. =====================================
  2. =                                   =
  3. = Communicating with 3DRealms Games =
  4. = Version 1.0                       =
  5. = February 12, 1996                 =
  6. = Written by Mark Dochtermann       =
  7. =                                   =
  8. =====================================
  9.  
  10. INTRODUCTION
  11.  
  12. A number of 3DRealms games use the same network/serial interface known as
  13. COMMIT.  COMMIT itself is an ipx/netbios/serial/modem communications
  14. package that simplifies the task of getting connected.  If you want to
  15. write a custom driver to replace COMMIT you must follow the specifications
  16. described in this text.
  17.  
  18. GENERAL
  19.  
  20. All communication between the driver and the game program is done through
  21. a shared data structure.  This data structure is passed into the game
  22. program by its flat linear address.  This structure is called the
  23. GAMECOM structure and from here on will be referred to as such:
  24.  
  25. typedef struct
  26.    {
  27.    short intnum;        // Game executes an int to send commands
  28.  
  29. // communication between Game and the driver
  30.  
  31.    short command;       // CMD_SEND or CMD_GET
  32.    short remotenode;    // dest for send, set by get (-1 = no packet)
  33.    short datalength;    // bytes in data to be sent / bytes read
  34.  
  35. // info specific to this node
  36.  
  37.    short consoleplayer; // 1-numplayers = player number
  38.    short numplayers;    // 1-MAXPLAYERS
  39.    short gametype;      // 1 = SERIAL, 2 = MODEM, 3 = NETWORK
  40.  
  41.    short extra;         // extra short for 4-byte alignment
  42.  
  43. // packet data to be sent
  44.  
  45.    char  data[MAXPACKETSIZE];
  46.    } gamecom_t;
  47.  
  48. GAMECOM contains all information necessary to communicate between the
  49. game and the driver.  The GAMECOM structure is modified by protected
  50. mode and by your driver asynchronously, therefore it is recommended not to
  51. modify it until you absolutely need to.  If the interface requests a
  52. packet and a packet is not ready, the partial packet should not be copied
  53. into the GAMECOM structure.  When the GAMECOM packet is initially passed
  54. into a game it must have certain critical information set in it.  This
  55. information includes: number of players, local player number,
  56. communication type, interrupt vector.
  57.  
  58. - intnum (interrupt vector) The interrupt on which all calls to the
  59.         communications driver are made.
  60. - numplayers (number of players) The total number of players in a game.
  61.         This value can have a value of [1..MAXPLAYERS].
  62. - consoleplayer (local player number) the player number of the local
  63.         system.  This value can have a value of [1..MAXPLAYERS].  Player
  64.         0 should always be the local address as well, so if the local
  65.         system, is player 2, the addresses would look something like this:
  66.                 0 - local system
  67.                 1 - player 1's system
  68.                 2 - local system
  69.                 ...
  70. - gametype (communication type) The communication type used in this game.
  71.         This parameter isn't very useful and usually has no consequence
  72.         inside the game itself. Its possible values:
  73.         1 - SERIAL a local serial game
  74.         2 - MODEM a modem game
  75.         3 - NETWORK any game going over a network
  76.  
  77. Once the game has been set up, the communication between the driver and
  78. the game is all done through GAMECOM commands.  The commands are as
  79. follows:
  80.  
  81. #define  CMD_SEND               1
  82. #define  CMD_GET                2
  83. #define  CMD_SENDTOALL          3
  84. #define  CMD_SENDTOALLOTHERS    4
  85. #define  CMD_SCORE              5
  86.  
  87. Upon receiving CMD_SEND, CMD_SENDTOALL, or CMD_SENDTOALLOTHERS, the driver
  88. should take the data in the data portion of GAMECOM (the length og the
  89. data specified by datalength), and send it to the appropriate destination
  90. as follows:
  91.  
  92. CMD_SEND - Send packet to the player number specified in GAMECOM's remotenode.
  93. CMD_SENDTOALL - Send packet to everyone in the game including a local echo.
  94.         This command is pretty rarely used because of the local echo.
  95. CMD_SENDTOALLOTHERS - Send packet to everyone except yourself (the local
  96.         player number specified in consoleplayer in GAMECOM)
  97.  
  98. Upon receiving CMD_GET, the driver should check to see if it has a packet
  99. ready for the game, and if it does copy the packet into the data portion
  100. of GAMECOM and fill in the GAMECOM datalength.  You should also set the
  101. address of the player who sent the packet in GAMECOM remotenode.  If no
  102. packets are ready, the driver should set GAMECOM's remotenode to -1 to
  103. inform the game that no new packets are ready.
  104.  
  105. The CMD_SCORE command is provided to allow score extensions to be added to
  106. a particular game and allow outside drivers to access these scores.  Since
  107. the implementation of a SCORE packet is different from game to game, no
  108. useful information can be given here.
  109.  
  110. It is recommended that you manage your own stack when calling your driver
  111. code since the transfer stack provided by the dos extender may not be
  112. large enough for your driver.
  113.  
  114. Please Refer to game specific documentation for idiosyncracies of a
  115. certain game.
  116.  
  117. Happy Programming,
  118.  
  119. Mark D
  120. PARADIGM @ METRONET.COM
  121.