ZN wrote: >> 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 > That's precisely what I meant. Scrolling must be the biggest issue,
On QPC this is actually faster than (or at least as fast as) the 2bit routines due to the acceleration. > but in an environment with background update, this is an issue one > cannot really solve (just thinking in advance here). I don't completely get that comment. >> 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. > All I can say is: AMEN! And this by the way mustn't necessarily be done by me! I really could use some help. >> Well, I really hope that people make their applications more >> colourful. I do encourage to brush up older applications > Agreed - the question being, HOW colorful do they need to be? Certainly not > 4 colors. 16 would already be more like it, 256 is already pushing it a > bit. There probably won't be that much paper, ink etc. colours, but sprites and icons can be quite colourful. So 256 might be fine. > No, the 'mode switch' would really only establish what kind of save area te > job needs and change the way a color definition as given is interpreted by > the driver - It would be a 'property' linked with the main application > window. So instead of the MODE command I would rather expand the traps that are responsible that a save area is created in the first place. Or extend the open command with a colour depth or something like that. > The idea is precisely not to have the jobs know they are running in a > particular mode unless they ask for it speciffically. [...] OK, I think I got your point now. Sounds good, just those conversion routines sound very, hmm, expensive. Both in execution and developing time ;-) Some simpler routines might be fine, too, though. If this creates problems with some applications you just have to increase the default colour mode again. > Now, don't get me wrong, I fully understand that this is a VERY tall > order. And it's not something to do _right_now_ but something to > think about for the future. At this point, you only make > recomendations :-) Yes, sure. I'm slowly looking into things. Perhaps I can do it one day. Sometimes when my subconsciousness has worked long enough on a problem I can just say "OK, let's do it" out of a sudden. :) Discussions like this help a lot. >>> Could you please, PLEASE add GD2 support to the Aurora ? It would >>> add a lot of users to High Color migration. I know it is probably >>> not easy but I'm sure Nasta will help !! >> Well, I am considering it. But I also expect this to be many many >> many hours of work. I don't even have the hardware for it. > Someone mentioned that the QXL drivers have a 256 color mode? No, the QXL users wished there was any 256 colour mode, but there isn't. I would have to write the whole driver. > It would certainly be a very welcome developement! Certainly. But I'm not actually eager to do it, because it sounds like very hard work for me. Especially as I lack the development tools. Tony probably has debuggers that work over a serial link and such, something when trying to write a new screen driver is no bad thing... I would probably have to implement it into QPC first, there I have better chances to debug. At the very least I don't think I can do this for free. It's neither fun nor does it improve anything I personally use. Perhaps something with the upgrade fee of SMSQ/E can be arranged, but it's too early to even think about it. That's one of the moments actually when I really wished that SMSQ was open source. Because although I don't want to do it I remain the only one who has a chance of doing it... :-( BTW: What colour format did the Aurora have? Is it the 3G, 2R, 2B + 1 R/B bit format mentioned in the GD2 docs? Marcel
