DirectDraw7 scaled Blt problem
Author
Ok... so I'm working with a framework built around DD7, and in one specific situation, where the system is low on video ram, my scaled blt can fail. Now both surfaces are valid and have already been created. The target hardware is guaranteed not to change. What I'm wondering is, does a Blt require any video memory outside of the target and destination surface, or are there any other low memory situations that could cause the Blt to fail? The error code returned is vague and of no help :(.
- How do you know the system low on video memory?
- What do you mean by "can fail". Does it not fail consistently?
- What is the error code?
Whether a blit requires video memory outside the target and destination surfaces is implementation dependent--DD doesn't specify anything as to how the operation is internally performed (by the driver and the card).
- What do you mean by "can fail". Does it not fail consistently?
- What is the error code?
Whether a blit requires video memory outside the target and destination surfaces is implementation dependent--DD doesn't specify anything as to how the operation is internally performed (by the driver and the card).
Author
The framework I'm using provides information on resource usage, and to the best of my knowledge is acurate and working (has been in use for a long while). The problem only pops up intermittently when there is less than 9mb of video memory free, and only then after the system has been running for a long time. The surface in question is an 800x600x16 surface being scaled blted. The error code being returned is DDERR_UNSUPPORTED. I know the operation is actually supported, however, because the operation works 99% of the time.
Well, I don't think it'd be a memory-related problem, because 9 MB is a lot of memory. It probably has to do with running for a long time. Are you sure the parameters to the blit do not change (memory corruption due to out-of-bound writes, for example)? Perhaps a combination of invalid parameters causes the driver to report such an error.
Other than that, I'd try updating the drivers if they're not the latest.
Other than that, I'd try updating the drivers if they're not the latest.
have you tried blitting smaller sections instead? If it's a one-shot memory problem you may get around it by slicing up the image into a 2x2 grid of images which you draw one at a time. Each one is then 1/4 the pixels and memory required, I would think.
Author
Thanks for the ideas guys. After some further testing, I've found that not scaling, but just cropping into place will not cause the error (though it won't give the desired effect). Also, if I force both surfaces into system memory, it works, although is slower than desired. Also, the paramaters to the blit are defined in constant ints at compile time, as they are never ment to change. I'm 99% sure the target system is running the latest drivers available to it.
The card this system is running wouldn't happen to have an NVidia chip would it? I found that GeForce 2 and 3 cards(at least) have a rare error that occurs. It has to do with scaling non-power of 2 video surfaces, in DD7. When I scale say 32x32 to any size it works fine, but if its 30x32 it will randomly cause a problem. Often times it runs for an hour with no problem but then it suddenly locks.
It doesn't happen in system memory to my knowledge. Your test seems to confirm what I've been thinking.
Another thing which seems to aggravates it is using DDBLT_WAIT. When I removed that I had about 1/5 of the hangs.
The power of 2 thing took a while to figure out though. The more times you blit the surface to the screen the worse it seems to be. That was how I finally isolated the problem. When I had a bunch of 32x32 graphics in memory it wasn't causing problems but then when I accidentally had a 30x32 bitmap being stretched to fit a 32x32 RECT it suddenly started hanging.
It doesn't happen in system memory to my knowledge. Your test seems to confirm what I've been thinking.
Another thing which seems to aggravates it is using DDBLT_WAIT. When I removed that I had about 1/5 of the hangs.
The power of 2 thing took a while to figure out though. The more times you blit the surface to the screen the worse it seems to be. That was how I finally isolated the problem. When I had a bunch of 32x32 graphics in memory it wasn't causing problems but then when I accidentally had a 30x32 bitmap being stretched to fit a 32x32 RECT it suddenly started hanging.
Author
No, it's an S3 chipset I believe. And I'm working with much larger surfaces, I'm scaling an 800x600x16 surface down to about a third of that. There is never a system lock though. It only fails to blit and keeps going on it's merry way. I am also passing in the DDBLT_WAIT flag to the blit operation, however.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
