First of all, I would like to thank the various members of the list who have given me a number of interesting suggestions in relation to my "pixels problem". All info has been gratefully received. Thanks also to those who have given me advice in relation to the originally stated (but oversimplified) drawing problem. I'm learning a lot!
In response to - <How long does it take to copy an image? <Maybe you can cut that in half by doing the "read the whole image <bitmap" only once. - the whole problem is that in the "eraser" routine the image needs to be continuously and permanently updated and also displayed on the screen according to every tiny movement of the eraser. The idea of copying the whole image into a variable or array, extracting and processing a portion of it and then replacing the whole image may be OK if it is done once, but not repeatedly as required by the eraser routine. In Transcript, the original copying of the image data to a variable is in fact quite quick, but the processing, replacement and copying back of the image is far too slow. According to the method outlined by Ken Ray in his article, I tried a test replacement of a mere 400 pixels, and this took various seconds! Part of the trouble is that Transcript does not appear to have instructions for simply reading or replacing individual pixels, which might alleviate the problem to some degree. However, ironically, as I have found out in VB, this is not the best solution. For maximum speed you have to process the image's pixel data directly. Putting even part of the pixel data into a variable or array for processing slows the whole thing down too much, and don't forget that quite complex mathematical calculations have to be performed on each pixel, which if done correctly can also take up considerable time. I have solved this problem in VB, but only by using non-standard pointer routines to find and process the image data. VB also has instructions (e.g. PaintPicture) for overlaying parts of the image data. VB is pretty fast with regard to mathematical processing. Nevertheless, in spite of my success, the general advice to VB programmers is to use DirectX (or C++) rather than normal VB, which because of its complexity I am not too inclined to do at the moment! From what I have seen so far, Transcript is more limited in all of these respects. In short, it appears not to have been made for this kind of graphical processing. However, if any improvements could be made in #2 (or #3???), e.g. the inclusion of instructions for setting individual pixels, some equivalent of "PaintPicture", etc., I would be eternally grateful. Ken Ray himself has hit the nail on the head: <This is something that as you identified is too slow to be done in regular <Transcript. You need the help of an external to do the processing of the <imageData for you. You might want to check out Chipp Walters' image tools <at: <http://www.altuit.com/webs/altuit2/RunRev/Downloads.htm <There's image compositing and convolution matrix utilities there that use <an external for speed. <I hope it works for you, Me too! Thanks Ray! Bob Warren _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
