>>> 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"
>Greyscale is actually useful. There are many cases where someone may be >using a mono LCD panel that supports 256 grey levels. Not really a good argument, I'm afraid. You find me a monochrome LCD either: a) supporting gray scale natively (not just where it says so in the datasheet abstract!) or b) being able to accurately show more than 16 levels of gray and I'll concede otherwise. Just remember that once uppon a time I made LCD controller for the QL. Monochrome display panels are natively just that - monchrome. Gray scale has to be emulated using FRM (Frame Rate Modulation) and/or dither. The first works OK but only for a very low number of grays, the controller design was mode 4 only and that was still OK. 8 would already be pushing it. >Also, greyscale can't be beaten if you're doing mono document editing. True. OTOH we don't have hardware capable of producing 256 levels of gray currently (unless someone adds a new mode that would work only for QXL and QPC) since it really implies 24 bit graphics. Now if we take into account Marcel's good point that the ability to specify 15 bit color already eliminates another 8-bit fixed palette, more or less the same is valid with monochrome, as it is also a kind of fixed palette. Unlike the system palette which is an index into a system table or the 'standard' color which also specifies stippling, more or less everything else is covered by the 15 bit specification. Granted, Q40/60 would gain another bit of resolution with a monochrome palette (which would unfortunately still leave two bits unimplemented) the question being how often monochrome is actually being used, or I should say, will beused. However, since Marcel says it's easy to implement... I suppose one never knows. >> The system palette is an excellent idea, the minor question is how to >> define it initially (default values). > I'm planning to add them as a standard configuration block. Well, you certainly have my blessings :-) Hopefully there will be a nice utility some day to set them up while the system is running... >> 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. Which one would that be? i hope we are not talking about the 256 color system palette imposed by the PC? Or am i missing something? > You think another 8bit fixed format would be of any good? Actually, you are right, but I was thinking on my feet really. The proper way to address this would be to encourage certain combinations of 15BPP values and discourage others, as defaults. Obviously colors ommonly found in mode 4, 8 are the ines to use, and (although not supported currently) 16, 256 definitions from Aurora - and finally 15BPP. >> 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. If I understand it correctly, that is the same pragmatical decision used for the high color drivers as they are. IMHO this might prove to be a serious problem in the future given the philosophy of WMAN - simply because the save areas increase 8-fold, the consequence of which is the speed of their manipulation decreases by the same factor. It really undermines one of it's best qualities: speed/simplicity. Just don't get me wrong, I don't think this is something that needs immediate attention, I'd surely put slave blocks on the top of that list, but let us not create another version of the 36 character name+path limit. >> 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? What I meant is that hardware capable of doing >4 colors can still show the 4 colors and given proper screen drivers, 'lesser mode' applications will still work without modification, just like they do now with the new drivers. Apps writen for mode 4 work in 32/33 simply because the drivers translate for them. the only thing that does not work is where there is direct screen access, for obvious reasons, but this is really the exception that cannot completely be catered for anyway - and never was. >> I believe that the solution to this problem also includes the >> solution to programs continuing to produce screen output even when >> burried. > Probably, yes. What I mentioned in an older post. If the save areas are kept in their original specified format (2BPP, 4BPP, 8BPP, etc) in RAM, and the application always writes to the save area and in addition to that, writes to the screen only if it is not burried (with translation for current screen mode) then this solves the problem of the save area size and the background screen output in one stroke. Sure, at first on would get the 'updated' version of a window only once it gets on the top of the job stack, but that's certainly already a big improvement. >> 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. Yes, I think that is something that needs to be addressed at the very least concurrently with the added WMAN options, because with more colors and large save areas more memory is needed, but when more memory is configured, slave blocks slow everything down to a crawl. Considering that people usually limit the size to 8-16MB to get acceptable performance, and that one save area in 1024x768 16BPP is already 1.5MB (even if the program really onli uses 4 colors!), one can clearly see that memory will run out very quickly. Nasta PS: about the 36 character limit. I know that many have argued this is hardly a burning problem, and for a system where all the software ever produced fits on an obsolete hard drve, that may largely be true. But we are talking about serious networking in the near future. Keep in mind that the trick to solving burning problems is to solve them before they become burning problems. This one may not be the open flame variety, but the ambers are being felt under the feet...
