Robert, >>I think I would make sure imageval was a reg var (or maybe 3 reg vars) >>rather than reading it from RAM on every line. > >Hi Jay, >I do consider that where applicable. I figure that the rotation vars need >to be register vars, and then I stick whatever else in there I can. >I don't really know enough about how the compiler works in the Register >arena to know which would be optimal. That is Robert Purves country. :) The vars to put in regs are the ones most frequently referenced. Every time you read from or write to RAM, it takes several times longer than using a register. It is probably faster to read 4 bytes at a time into a register var, separate them out into other registers, reassemble them after calculations, and write them to memory than to read each byte separately. (This is a trick I used in my Alphabetic Continuum.) Iff I get a chance, I'll look at whether and how this could be done in your code. >But here is what I think may save some time. Not sure, will have to test >first. > >The loop is moving a 4x4 box across the image. I am peeking values that >have already been gotten most of the time. I could have an array of 3 rows >of the image, after the first 4 scan lines or so, and then access the >previously gotten values, and using the new 4th row just input, shuffling >the buffer up as I go. > >That should save even more. > Brilliant in concept, but I fail to see where the savings come. It sounds as though you're talking about copying values into an array, then back into the gworld, which I think would take extra time. They are both in RAM, so one shouldn't be any faster than the other. Now if you are saying there are redundant calculations, and you can save preliminary calculations from one box to use in the next, then you've got something! Or are you suggesting that an output pixel address can be checked just once for bounds, and the results saved? That makes sense, and is more-or-less what I was suggesting before. 0"0 =J= a y "