Help? =] I am freaking out!
BlitzPlus Forums/BlitzPlus Programming/Help? =] I am freaking out!
| ||
| OK, largish program, probably uses too much vidmem (but I have 128MB and I definately havn't used that much yet;) - three very large (3000x800+) pictures being blitted to the screen, amongst other smaller, much more normal images. Runs fine in B2D, crawls to a halt in B+. Two of those pictures are loaded from a png - one created using CreateImage(). If either of the two pngs are blitted anywhere on the visible screen area, massive slowdown. If pngs are blitted offscreen everything runs smoothly. This is not true for the CreateImage()'d pic - it doesn't slow anything down whether it's in view or not. --- Forgetting the defualt response of 'don't blit images larger than the screen', can we discuss reasons why this behaviour exists and perhaps also why it doesn't exist in B2D/B3D at all? I should probably mention that the behaviour doesn't exist in a small testbed comprising the offending images only (B+ is faster then)... but it's 2.30am here and instead of creating a bigger, more elaborate, comprehensive testbed, I'm gunna go sleep ;] I don't drink coffee. =] |
| ||
| The reason this behavior exists is DirectX itself. Which leads to an interesting possibility - if you have bought a copy of BlitzPlus, try testing that same stuff using either of the two new graphics drivers (the Native or the OpenGL, as opposed to the original DirectDraw) and see if the problem gets resolved. |
| ||
| Hi, Try setting image flags to 'dynamic' (2 I think). This should emulate the behaviour of Blitz2D. |
| ||
| No no, that's what I was hoping for, this behavior has not changed with B+1.34 - flags make no change, differant gfx modes make no change (OpenGL is a little slower, in fact - and Native crashed (Error Reporting dialogue style!) but I can't be certain if this was the cause, I havn't fiddled with it extremely much). I was -so- hoping the dynamic flag would 'fix' it... The only differance is between B+ and B2D/3D, it is HELL weird, I've decided, probably something dodgy going on in my code somewhere, but I havn't had the time to delve into it very deeply yet. Soon. |
| ||
| Sounds like dodgy code to me - which would be good news AND bad news for you I guess...;o) |
| ||
| 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 =] |
   |