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
  31 \r
  32 \r
  33 00:00:19   joncampbell123 | okay you're makefile is already using -zu, -zff and other options that I'm     │\r
  34                           | sure would tell Watcom C to separate stack from data segment, but the MAP file │\r
  35                           | says it's still associating STACK with DGROUP :(                               │\r
  36 00:08:56   joncampbell123 | argh                                                                           │\r
  37 00:10:04   joncampbell123 | sparky, it's probably better to refactor your code not to require so much      │\r
  38                           | stack                                                                          │\r
  39 00:10:20   joncampbell123 | in most of doslib I test and dev the code against far smaller stack sizes,     │\r
  40                           | usually 8KB                                                                    │\r
  41 00:11:03   joncampbell123 | besides you don't want a stack that occupies 1/10th of all conventional memory │\r
  42                           | in DOS, right? ^^                                                              │\r
  43 00:11:50   joncampbell123 | 64KB is a more appropriate stack size if you're targeting 32-bit DOS or Win32, │\r
  44                           | not 16-bit DOS                                                                 │\r
  45 00:12:34   joncampbell123 | if you need so much storage please try using global variables or memory        │\r
  46                           | allocation, but don't eat up your stack like that                              │\r
  47 00:13:59   joncampbell123 | don't forget you can move a char[] declaration within your function off the    │\r
  48                           | stack by declaring it static                                                   │\r
  49 00:14:17   joncampbell123 | then it's a local variable that lives in the data segment, not stack \r
  50 \r
  51 \r
  52 00:19:40   joncampbell123 | meaning you go through your functions, locate ones that declare a lot of local │\r
  53                           | stack storage,                                                                 │\r
  54 00:19:53   joncampbell123 | and refactor them to put the storage elsewhere, other than the stack           │\r
  55 00:20:03   sparky4_derpy4 | joncampbell123: ah ok ^^ i will!!!                                             │\r
  56 00:20:16   sparky4_derpy4 | joncampbell123: look for large variables too? ww                               │\r
  57 00:20:21   joncampbell123 | yes.                                                                           │\r
  58 00:20:29   sparky4_derpy4 | scroll16 needs a bunch of work                                                 │\r
  59 00:20:29   joncampbell123 | the less you declare on the stack, the less stack the function needs.\r
  60 \r
  61 \r
  62 \r
  63 \r
  64 \r
  65 \r
  66 [15:03] joncampbell123m Think of it this way\r
  67 [15:03] joncampbell123m If something moves or changes frame\r
  68 [15:04] joncampbell123m then a rectangular region around the sprite needs to be redrawn\r
  69 [15:05] joncampbell123m So you collect update regions together\r
  70 [15:06] joncampbell123m based on performance vs overlap\r
  71 [15:06] joncampbell123m combine the rectangles together and redraw the screen they cover\r
  72 [15:07] joncampbell123m the simplest way is to compute a rectangle that covers them all\r
  73 [15:07] joncampbell123m then redraw that.\r
  74 [15:08] joncampbell123m Then optimize the code from there how you handle it\r
  75 \r
  76 \r
  77 \r
  78 \r
  79 screen set up 2 rendering screens lock together\r
  80 1 scrolls the other one follow\r
  81 \r
  82 pointers from 2nd screen follows the 1st\r
  83 size and dimentions and stuff are the same but addresses are different\r
  84 data is different \r
  85 \r
  86 https://www.quora.com/How-such-smooth-scrolling-was-achieved-in-games-like-Super-Mario-and-Commander-Keen