DirectDraw + Pitch

When would the pitch change? Do I have to use the value returned by the lock function every time or can I assume that the value returned by the lock function will stay the same as long as the application doesn't change the surfaces layout?
If I create a surface, do some blitting, restore it when it has gone and than continue blitting, will the Pitch value stay the same?
So one call to a lock function can give me the Pitch value for the rest of the "life" of the surface?
upanishadiiiAsked:
Who is Participating?
 
nils pipenbrinckConnect With a Mentor Commented:
if you're blitting from one surface to another make sure, that your surface is _not_ locked! this might work on your driver, but the behaviour is undefined. I would expect that the blits are queued until you unlock your surface, but that's only a guess...

To the pitch..  it's very unlikely, that the pitch will change from one loock to the next, but - happy windows world - I would ever use the pitch from the current lock.. just to be sure... (does it really makes a difference in your code? my rendering stuff is pitch independant, and it was neither a coding nor a performance problem..)

Nils
0
 
upanishadiiiAuthor Commented:
Or if it changes, when would the Pitch change?
0
 
pjknibbsCommented:
Why would you *not* use the value returned from the Lock function? I don't see why it's any harder than storing the value you first got and using it ad infinitum. I'd imagine the Pitch for a surface at a particular colour depth and resolution will be fixed, *providing* you're running in exclusive full-screen mode--if this is on a window on the desktop the user could change resolutions or colour depths between the two Locks, which would certainly change the Pitch.

Incidentally, if by "blitting" you mean the normal DirectDraw ->Blt() functions, I don't think they work on locked surfaces.
0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
upanishadiiiAuthor Commented:
I use direct surface acces to put my image on a surface, and I get it from a file. I need to do a lot of iterations before the image appears on the surface, and if I could 'trust' a certain pitch value, I only need to preform a memcpy function in the time the surface is locked and unlocked. I was told that the time between lock and unlock should be minimized strongly. So therfor I need this value.

I've solved it this way. I keep the previous Pitch Value returned from the Lock function in a variable and I check if it changes the next time. If it does change, I have 1 "extensive" lock-unlock procedure, otherwise I just copy previous buffered data based on the previous lock value to the video memory. I think this is the best solution for my case. I've checked and in all situations I encountered the pitch value stays the same about 752 for a 748 pixels width surface. If it should change, my function will intercept this and give an image based on the new pitch value.


So in my case I need to build my data buffer after the lock function if I can't trust the pitch value, otherwise this data has been build before and I only need to flush them to the video memory.

Off course the blitting appears after I unlocked it, sorry for the misunderstanding.
0
 
nils pipenbrinckCommented:
I do a memcpy for each scanline I copy to the framebuffer.

internally my bitmap is pitch==width, and I convert it on the fly when I copy it to  the framebuffer..


nils
0
 
upanishadiiiAuthor Commented:
That was my initial Draw Procedure, but I tried to make it faster by having an exact framebuffer in memory before the lock function, than just copy the whole thing and unlock instead of converting it on the fly. This because I had been advised to minimize the time between lock and unlock. If that is done, the blitting would be faster.

If you say it doesn't matter where I contruct the buffer and just use the pitch returned from Lock to set the framebuffer up on the fly, I guess I could keep using that. Are you sure there was no performance problem?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.