notime

[16.git] / design.txt

diff --git a/design.txt b/design.txt
index 8cdc990f461a769a7a9933c4c67cd3757174c001..6d265f0bab07ba1449abbb53143ddab050da88e6 100755 (executable)
--- a/design.txt
+++ b/design.txt
@@ -2,6 +2,8 @@ Near functions should be for frequently used functions that update the game engi
 \r
 far functions are for like menus, file loaders, and such\r
 \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
 \r
 \r
 "\r


@@ -26,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\r
 be used to turn off stack checking, so no stack checking routines get called.\r
 "\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
+https://www.quora.com/How-such-smooth-scrolling-was-achieved-in-games-like-Super-Mario-and-Commander-Keen