ZN wrote: > 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.
Now that you mention stippling, it is my opinion that when having 16 bit colours there is no need for stipples anymore (I mention this because I've heard that Tony invested quite a lot of thinking about how to get stipples in). What is the general opinion about that? >>> 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... Yes, there definitely needs to be some additional utility because most people are not good in binary calculations... >> 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? No, I mean the palette SMSQ uses on palette calls. It's predefined with certain colours (list is at the end of GD2 docs) and I think that most people will leave it this way. > 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. Yes, makes sense. >> 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. Probably, yes. > 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. I know. That's why I have re-done the wallpaper code in a way that it does not use a complete save area anymore but paint the background when it's necessary. Most manipulations aren't really much slower than their 2bit equivalent, the calculations are a lot simpler. The problem comes when big chunks of memory need to be altered, but when one uses the proper OS calls for that it's very fast again because QPC for example uses accelerated routines. And the idea of having accelerated ProWesS drivers etc. has been in my head for a long time, too. Finally in the end there should be a standard graphics library thing which can be consulted for all things involving graphics manipulation, like colour conversions so that not every single application has to implement that stuff etc. And those routines could be accelerated, too. > 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. Well, I really hope that people make their applications more colourful. I do encourage to brush up older applications and might do some of that work myself (e.g. Jochen is currently trying to get the QPAC2 source code so that we/I can extend it. This is very important in my eyes). And the problem might be that this needs to be sorted out right now. Because the basic problem will be: how can I know in what colour depth an application runs? With the new WMAN old applications can be forced to use the new colours just by patching the colour codes in the window definition data structures (which is GOOD thing). So even the applications themselves might not know that they're high colour now! But I need to know how much save area to allocate beforehand. What happens if an application is considered 2bit only and all of a sudden it issues an iow.papt (true colour paper trap) call with some exotic colour? > 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. I'm not completely sure whether I get this right, you're proposing some sort of the old MODE4-MODE8 switch? Well, for one I don't like that and hardware like the Qx0 do make a problem there because the 4 colour mode is restricted to the poor 512x256 resolution. > Apps writen for mode 4 work in 32/33 simply because the drivers > translate for them. I wouldn't call it "translate". The applications issue a "I want a red paper" call and the screen driver handles this in a way suitable for the graphics mode. There isn't really any 2bpp->16bpp translation involved. > 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 am thinking about some compatibility box for this case, too. Jochen e.g. needs Text87 to run in high colour mode before he can finally switch to it. So the solution I am thinking of is Text87 only. >> 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. I'm currently looking into it again (although time's running short, next exam in sight again...) Marcel
