design.txt

   1 Near functions should be for frequently used functions that update the game engine are are time critial\r
   2 \r
   3 far functions are for like menus, file loaders, and such\r
   4 \r
   5         Make a palette manager that updates the display palette with the pallet of images and sprites. in a stack and reuse same colors in the pallette on the image by changing the image's values to the matching color.\r
   6                 Use a little database to keep track of the images loaded and have manipulated the display pallette.\r
   7 \r
   8 \r
   9 "\r
  10 It is also possible to use the small code option, and to override certain functions and pointers to functions as\r
  11 being\r
  12  far.\r
  13   However, this method may lead to problems.  The Open Watcom C\r
  14 16\r
  15  compiler generates special\r
  16 function calls that the programmer doesn’t see, such as checking for stack overflow when a function is\r
  17 invoked.  These calls are either\r
  18  near\r
  19  or\r
  20  far\r
  21  depending entirely on the memory model chosen when the\r
  22 module is compiled.  If the small code model is being used, all calls will be near calls.  If, however, several\r
  23 code groups are created with far calls between them, they will all need to access the stack overflow\r
  24 checking routines.  The linker can only place these special routines in one of the code groups, leaving the\r
  25 other functions without access to them, causing an error.\r
  26 To resolve this problem, mixing code models requires that all modules be compiled with the big code\r
  27 model, overriding certain functions as being near.  In this manner, the stack checking routines can be placed\r
  28 in any code group, which the other code groups can still access.  Alternatively, a command-line switch may\r
  29 be used to turn off stack checking, so no stack checking routines get called.\r
  30 "\r