home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / games / volume2 / dungeon / part07 / PDP.doc < prev    next >
Text File  |  1987-09-01  |  3KB  |  63 lines
  1. The implementation of dungeon on unix systems
  2. Randy Dietrich         17 Nov 1981
  3.  
  4. When we set out to get dungeon running on unix we figured
  5. it wouldn't be too big a problem.  After all a fortran
  6. compiler (F77) existed and with relatively little problem
  7. managed to get everything to compile.  
  8. Then the Zorkmids hit the volcano.
  9. We thought that a program which would run in 28k on an
  10. RSX system would have fit just fine in 64k, especially
  11. with seperate i & d.  We did not realize just how hostile 
  12. unix is to FORTRAN programs.
  13. The first link indicated about 130 k (text only) was needed
  14. for the whole game (Ieeeeee).  Recompiling with short (I2)
  15. integers brought this down to about 100k.  Throwing out
  16. the game debug package (9k) and the save and restore code (3k)
  17. got us to within 20k.  
  18. At this point we discovered that the fortran library that
  19. was being used was about 25k (A HA !!).  If we could just 
  20. eliminate that we would be in business.  A great game with
  21. no I/O !!  further work allowed us to write the I/O in C
  22. with the bulk of the game using only standard input and output.
  23. The initialization and message printing were "moved out"
  24. into seperate processes and the whole mess piped together.
  25. it is a real kludge but seems to work (mostly).
  26.  
  27. The Input process is called 'listen'.  It first reads the init
  28. file and shoves it in the pipe and then switches to pass
  29. keyboard input to the main game.  This keeps the main program
  30. from having to read anything but 'standard input'.
  31.  
  32. The output process is currently called 'speak'.
  33. this process does the lookup in the file 'dtext.dat' and
  34. sends out the messages that give dungeon it's flavor.  This
  35. process also passes clear text from the main program to
  36. allow the output of other messages for such things as the
  37. echo room, puzzle room, and score.  These functions
  38. were also 'moved out' so the main program would not have
  39. to access any disc files.
  40.  
  41. The main program is sandwitched between listen and speak.
  42. It really does the work of the game.  I/O is handled
  43. thorugh C routines in 'cio.c'. this keeps any fortran
  44. I/O from being used and calling in the whole #$%@ fortran
  45. library.
  46.  
  47. The current lash-up does save or restore but not both.  
  48. It is going to take a while to work in as we are out of room
  49. in the main program and will have to re-write something
  50. to make it all fit.  I guess we will just have to play
  51. without being able to cheat for a while.
  52.  
  53. Restores are done by initializing the game with a second argument
  54. (some day the file name) of 'r'.  This causes the init process 
  55. to send a 'R' down down the pipe followed by the restore data.
  56. normally the init process ends with a '?'.  The trailing '?'
  57. will follow the restore data.
  58.  
  59. Saves are done from within the game.  The game sends a 's'
  60. down the pipe to signal the speak process to do a save opperation.
  61. The save data then goes down the pipe followed by 'e' to
  62. signal the end of data.  The save data is 'dungeon.sav'.
  63.