--- /dev/null
+Near functions should be for frequently used functions that update the game engine are are time critial\r
+\r
+far functions are for like menus, file loaders, and such\r
+\r
+ 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
+ Use a little database to keep track of the images loaded and have manipulated the display pallette.\r
+\r
+\r
+"\r
+It is also possible to use the small code option, and to override certain functions and pointers to functions as\r
+being\r
+ far.\r
+ However, this method may lead to problems. The Open Watcom C\r
+16\r
+ compiler generates special\r
+function calls that the programmer doesn’t see, such as checking for stack overflow when a function is\r
+invoked. These calls are either\r
+ near\r
+ or\r
+ far\r
+ depending entirely on the memory model chosen when the\r
+module is compiled. If the small code model is being used, all calls will be near calls. If, however, several\r
+code groups are created with far calls between them, they will all need to access the stack overflow\r
+checking routines. The linker can only place these special routines in one of the code groups, leaving the\r
+other functions without access to them, causing an error.\r
+To resolve this problem, mixing code models requires that all modules be compiled with the big code\r
+model, overriding certain functions as being near. In this manner, the stack checking routines can be placed\r
+in any code group, which the other code groups can still access. Alternatively, a command-line switch may\r
+be used to turn off stack checking, so no stack checking routines get called.\r
+"\r
+\r
+\r
+00:00:19 joncampbell123 | okay you're makefile is already using -zu, -zff and other options that I'm │\r
+ | sure would tell Watcom C to separate stack from data segment, but the MAP file │\r
+ | says it's still associating STACK with DGROUP :( │\r
+00:08:56 joncampbell123 | argh │\r
+00:10:04 joncampbell123 | sparky, it's probably better to refactor your code not to require so much │\r
+ | stack │\r
+00:10:20 joncampbell123 | in most of doslib I test and dev the code against far smaller stack sizes, │\r
+ | usually 8KB │\r
+00:11:03 joncampbell123 | besides you don't want a stack that occupies 1/10th of all conventional memory │\r
+ | in DOS, right? ^^ │\r
+00:11:50 joncampbell123 | 64KB is a more appropriate stack size if you're targeting 32-bit DOS or Win32, │\r
+ | not 16-bit DOS │\r
+00:12:34 joncampbell123 | if you need so much storage please try using global variables or memory │\r
+ | allocation, but don't eat up your stack like that │\r
+00:13:59 joncampbell123 | don't forget you can move a char[] declaration within your function off the │\r
+ | stack by declaring it static │\r
+00:14:17 joncampbell123 | then it's a local variable that lives in the data segment, not stack \r
+\r
+\r
+00:19:40 joncampbell123 | meaning you go through your functions, locate ones that declare a lot of local │\r
+ | stack storage, │\r
+00:19:53 joncampbell123 | and refactor them to put the storage elsewhere, other than the stack │\r
+00:20:03 sparky4_derpy4 | joncampbell123: ah ok ^^ i will!!! │\r
+00:20:16 sparky4_derpy4 | joncampbell123: look for large variables too? ww │\r
+00:20:21 joncampbell123 | yes. │\r
+00:20:29 sparky4_derpy4 | scroll16 needs a bunch of work │\r
+00:20:29 joncampbell123 | the less you declare on the stack, the less stack the function needs.\r
+\r
+\r
+\r
+\r
+\r
+\r
+[15:03] joncampbell123m Think of it this way\r
+[15:03] joncampbell123m If something moves or changes frame\r
+[15:04] joncampbell123m then a rectangular region around the sprite needs to be redrawn\r
+[15:05] joncampbell123m So you collect update regions together\r
+[15:06] joncampbell123m based on performance vs overlap\r
+[15:06] joncampbell123m combine the rectangles together and redraw the screen they cover\r
+[15:07] joncampbell123m the simplest way is to compute a rectangle that covers them all\r
+[15:07] joncampbell123m then redraw that.\r
+[15:08] joncampbell123m Then optimize the code from there how you handle it\r
+\r
+\r
+\r
+\r
+screen set up 2 rendering screens lock together\r
+1 scrolls the other one follow\r
+\r
+pointers from 2nd screen follows the 1st\r
+size and dimentions and stuff are the same but addresses are different\r
+data is different \r
+\r