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
+https://www.quora.com/How-such-smooth-scrolling-was-achieved-in-games-like-Super-Mario-and-Commander-Keen
OSDN Git Service
