Yeh, Anthony I figured something like that too - but the problem lay with me thinking it was due to -blitting- these large images (because when ;ming out the 'culprit' DrawImage commands it ran fine)... not the case. I've solved the problem, hurrah. =]
The culprit? Fricken ReadPixel. It -has- got to do with the image loading flags - with flag 1, even though the image isn't being modified, it seems Blitz still needs to grab it back from vidmem to read it (makes sense) - but perhaps also sends it back to vidmem even though nothing has been altered... My guess is that when SetBuffer is called, the image is grabbed from mem and then put back when DrawImage is called - Mark, maybe you can optimise it a bit by only writing the picture back if a WritePixel operation has been performed? That's assuming, of course, that what I'm saying isn't so far off...
I've put it down to AGP bandwidth being clogged. I'm feeling slightly less crazy-stressed now. Only slightly. =]
EDIT : Oh, a little more insight into my crazy little world, for those that want it, the reason I originally thought the flags didn't fix it (and they didn't until...) - in the same routine that uses these ReadPixel commands on the large pictures, are commands that blit to a 25x25 image, which happens 8 times per frame, all of which later get blitted to the screen. Wasn't causing any problems when the large images were taken out of the equation, so I thought maybe they were small enuff to not worry about ;] Big mistake. It was these 8 -in combination- with the ReadPixel commands on the large bitmaps that were causing the slowdown. Phew!
EDIT EDIT : At first I thought it was interesting that the third large, CreateImage()'d pic didn't cause the slowdown - of course, it isn't being read or written to (that was planned later on in development - it's basically just a blank huge image sitting in the background for now). Naturally it gets sent to the vidcard once and isn't affecting the AGP bandwidth after that.
Anyway, now it's 1.50am again so, night all ;] I can at least sleep a little better tonight =]
The culprit? Fricken ReadPixel. It -has- got to do with the image loading flags - with flag 1, even though the image isn't being modified, it seems Blitz still needs to grab it back from vidmem to read it (makes sense) - but perhaps also sends it back to vidmem even though nothing has been altered... My guess is that when SetBuffer is called, the image is grabbed from mem and then put back when DrawImage is called - Mark, maybe you can optimise it a bit by only writing the picture back if a WritePixel operation has been performed? That's assuming, of course, that what I'm saying isn't so far off...
I've put it down to AGP bandwidth being clogged. I'm feeling slightly less crazy-stressed now. Only slightly. =]
EDIT : Oh, a little more insight into my crazy little world, for those that want it, the reason I originally thought the flags didn't fix it (and they didn't until...) - in the same routine that uses these ReadPixel commands on the large pictures, are commands that blit to a 25x25 image, which happens 8 times per frame, all of which later get blitted to the screen. Wasn't causing any problems when the large images were taken out of the equation, so I thought maybe they were small enuff to not worry about ;] Big mistake. It was these 8 -in combination- with the ReadPixel commands on the large bitmaps that were causing the slowdown. Phew!
EDIT EDIT : At first I thought it was interesting that the third large, CreateImage()'d pic didn't cause the slowdown - of course, it isn't being read or written to (that was planned later on in development - it's basically just a blank huge image sitting in the background for now). Naturally it gets sent to the vidcard once and isn't affecting the AGP bandwidth after that.
Anyway, now it's 1.50am again so, night all ;] I can at least sleep a little better tonight =]