"It seems like a good idea to use an array if ReadPixelFast is so slow! Although the slowest part may be creating the array in the first place. This may show as a small pause before the fade actually begins. The only problem with arrays is I have to define a large amount of memory that never gets freed until the program exits because you can't dynamically free arrays can you? What about using a bank? Maybe this would be even faster (or as fast) and it can be freed up later."
It's less than a megabyte. Most people have 256 minimum. I think you'll live. :-)
You could use a bank, but they are not as fast as arrays.
Actually I think there is a way to redimension an array in Blitz now that I think of it... But I think you can't then access X,Y with it, you will have to do Y*Width + X, which actually would be another speed boost because you can move the Y*Width outside the X loop. Heck, you can get rid of it entirely if you just increment the offset every pixel now that I think of it. But one multiply every row isn't a big problem.
As for the pause... copying the screen once to an array at the start is probably not going to cause a visible pause.
As for something faster than readpixelfast, there is in Blitzplus, but to use it you have to find out the color depth, and the "pitch" of the screen, and it's just a nightmare to use, and the speed boost is like 33% in 24bit color mode I think. Don't ask me how to use it. :-)
Oh, and it is my understanding that Blitzplus has no frontbuffer you can access. There is only a backbuffer, and frontbuffer() accesses it.
It's less than a megabyte. Most people have 256 minimum. I think you'll live. :-)
You could use a bank, but they are not as fast as arrays.
Actually I think there is a way to redimension an array in Blitz now that I think of it... But I think you can't then access X,Y with it, you will have to do Y*Width + X, which actually would be another speed boost because you can move the Y*Width outside the X loop. Heck, you can get rid of it entirely if you just increment the offset every pixel now that I think of it. But one multiply every row isn't a big problem.
As for the pause... copying the screen once to an array at the start is probably not going to cause a visible pause.
As for something faster than readpixelfast, there is in Blitzplus, but to use it you have to find out the color depth, and the "pitch" of the screen, and it's just a nightmare to use, and the speed boost is like 33% in 24bit color mode I think. Don't ask me how to use it. :-)
Oh, and it is my understanding that Blitzplus has no frontbuffer you can access. There is only a backbuffer, and frontbuffer() accesses it.