X-Git-Url: http://4ch.mooo.com/gitweb/?a=blobdiff_plain;f=design.txt;h=6d265f0bab07ba1449abbb53143ddab050da88e6;hb=40936f6f8b06f8d5d238e932a4847b8a7d478aa4;hp=3de430a778da424b1df3867a515c453b541b8934;hpb=73a30b484a38841774ea4bd8d93b5d7c6b830f06;p=16.git

diff --git a/design.txt b/design.txt
index 3de430a7..6d265f0b 100755
--- a/design.txt
+++ b/design.txt
@@ -28,3 +28,59 @@ model, overriding certain functions as being near.  In this manner, the stack ch
 in any code group, which the other code groups can still access.  Alternatively, a command-line switch may
 be used to turn off stack checking, so no stack checking routines get called.
 "
+
+
+00:00:19   joncampbell123 | okay you're makefile is already using -zu, -zff and other options that I'm     │
+                          | sure would tell Watcom C to separate stack from data segment, but the MAP file │
+                          | says it's still associating STACK with DGROUP :(                               │
+00:08:56   joncampbell123 | argh                                                                           │
+00:10:04   joncampbell123 | sparky, it's probably better to refactor your code not to require so much      │
+                          | stack                                                                          │
+00:10:20   joncampbell123 | in most of doslib I test and dev the code against far smaller stack sizes,     │
+                          | usually 8KB                                                                    │
+00:11:03   joncampbell123 | besides you don't want a stack that occupies 1/10th of all conventional memory │
+                          | in DOS, right? ^^                                                              │
+00:11:50   joncampbell123 | 64KB is a more appropriate stack size if you're targeting 32-bit DOS or Win32, │
+                          | not 16-bit DOS                                                                 │
+00:12:34   joncampbell123 | if you need so much storage please try using global variables or memory        │
+                          | allocation, but don't eat up your stack like that                              │
+00:13:59   joncampbell123 | don't forget you can move a char[] declaration within your function off the    │
+                          | stack by declaring it static                                                   │
+00:14:17   joncampbell123 | then it's a local variable that lives in the data segment, not stack 
+
+
+00:19:40   joncampbell123 | meaning you go through your functions, locate ones that declare a lot of local │
+                          | stack storage,                                                                 │
+00:19:53   joncampbell123 | and refactor them to put the storage elsewhere, other than the stack           │
+00:20:03   sparky4_derpy4 | joncampbell123: ah ok ^^ i will!!!                                             │
+00:20:16   sparky4_derpy4 | joncampbell123: look for large variables too? ww                               │
+00:20:21   joncampbell123 | yes.                                                                           │
+00:20:29   sparky4_derpy4 | scroll16 needs a bunch of work                                                 │
+00:20:29   joncampbell123 | the less you declare on the stack, the less stack the function needs.
+
+
+
+
+
+
+[15:03]	joncampbell123m	Think of it this way
+[15:03]	joncampbell123m	If something moves or changes frame
+[15:04]	joncampbell123m	then a rectangular region around the sprite needs to be redrawn
+[15:05]	joncampbell123m	So you collect update regions together
+[15:06]	joncampbell123m	based on performance vs overlap
+[15:06]	joncampbell123m	combine the rectangles together and redraw the screen they cover
+[15:07]	joncampbell123m	the simplest way is to compute a rectangle that covers them all
+[15:07]	joncampbell123m	then redraw that.
+[15:08]	joncampbell123m	Then optimize the code from there how you handle it
+
+
+
+
+screen set up 2 rendering screens lock together
+1 scrolls the other one follow
+
+pointers from 2nd screen follows the 1st
+size and dimentions and stuff are the same but addresses are different
+data is different 
+
+https://www.quora.com/How-such-smooth-scrolling-was-achieved-in-games-like-Super-Mario-and-Commander-Keen