ZN wrote: > The system palette is an excellent idea, the minor question is gow to > define it initially (defauklt values).
I'm planning to add them as a standard configuration block. > I have my doubts about the gray scale value palette. Yes, it's a bit superfluous but as it's next to no work for me to implement I just thought "go for it", especially as the main colour for GUIs is usually gray. > Perhaps a fixed color definition could be a good idea instead, and > if so, use something like the Aurora color set. It's simple and all > systems capable of 256 colors can reproduce it. That way programs > can have a unified 'shorthand' color table when needed. Hmm, on the one hand there's already the normal palette mode which is well defined and I think it's unlikely that the user changes it. On the other hand there's the 15 bit colour definition with which one can specify exact colours. You think another 8bit fixed format would be of any good? > The matter of window saves using the deepest color definition regardless of > how many colors are actually used is one of the more serious, and probably > very complex issues. Yes, I thought a lot about it and it is very complex. My conclusion is that the goal is not to have applications that only use 4 colours so that this isn't a disadvantage anymore. This is neither nice nor elegant but pragmatical. > IMHO the MODE command still needs to have effect in > high color screen mode. Actually, ideally, the 'screen' moda nd the > 'application' mode should be separate, especially now that there is > hardware with screen modes capable of concurrently showing all lesser > modes. I don't quite understand, which hardware can do this? > I believe that the solution to this problem also includes the > solution to programs continuing to produce screen output even when > burried. Probably, yes. > Slave blocks are a big problem. As far as I can understand, they really > need to stay in some form - with a limited number as the linear table > search is what really slows things down so imensely. Also, the real problem > in limiting the slave blocks is that the table start and length are > effectively 'hardcoded' because they are derived from pointers to other > structures. Yes, exactly. > I wonder if an alternative way of limiting the number of slave > blocks would be to attack the basic area movement rules. There's the Atari concept of "fast memory" which is not used for slaving. Maybe I should again look into that possibility. Marcel
