Back to General and Gameplay Programming

Win32 - capturing screenshots and odd resolutions

General and Gameplay Programming Programming

Started by SymLinked June 25, 2012 07:34 PM

9 comments, last by SymLinked 11 years, 10 months ago

SymLinked

1,233

Author

June 25, 2012 07:34 PM

Hi!

I've implemented a simple screenshot capture method, where I do the following:

Get the screen DC by calling GetDC (NULL);
Use CreateCompatibleDC () to create a device context.
Grab width/height of the screen by calling GetDeviceCaps ().
Calling CreateCompatibleBitmap (screenDC, width, height);
Calling SelectObject (deviceContext, bitmap);
Finally, calling BitBlt (deviceContext, 0, 0, x, y, screenDC, 0, 0, SRCCOPY | CAPTUREBLT); and GetDIBits () to get the data pointer.

This works fine except that it doesn't work in odd resolutions like 1366x768 where everything shows up as white/black lines. Anyone got any ideas what's causing this? Is the data output from GetDIBits() padded in this case or something? It looks like there's an extra byte per channel or something which distorts the image as I'm assuming 32-bit, but that's hardly the case as the image is 32-bit.

Any advice is greatly appreciated!

frob

46,223

June 25, 2012 08:46 PM

Read up a little about the bitmap format.

The format has some details that you may have missed.

The data probably IS NOT CONTINUOUS.

Every pixel entry can potentially have some unused space on it; as you noticed only 24 bits are valid but 32 bits are used. Every scan line may potentially have some unused space on it. e.g. The data may have space for 1024 but the window is only 1022 pixels long.

You need to account for both.

SymLinked

1,233

Author

June 25, 2012 09:46 PM

That sounds logical, but how exactly would you detect when this happens? It's definatly not different bitrates, I already account for that - it's something else.
I've Googled and Googled but come up with nothing.

I retrieve the width, height, numBits and format but it looks exactly the same as in all other resolutions.

bubu LV

1,436

June 25, 2012 11:52 PM

How are you processing lpvBits argument from GetDIBits function?

SymLinked

1,233

Author

June 26, 2012 07:31 AM

Just a memory copy, which works in all other resolutions I've tested except 1366x768. Even the bitmap header says the size of the lpvBits data is what I expected (ie, 4 * width * height) so I'm not sure how I would be able to read it any differently.

Amr0

2,230

June 26, 2012 11:24 AM

Yes the symptoms conform with padding unaccounted for. In addition to per-pixel padding, the BMP format uses per-row padding. You can calculate the number of bytes used per row of pixels like so:



rowSize = DWordAlign( bpp/8 * width );

[size=2]You may find these useful: Mirror: GDI-based mirror window (src code included), GDI Memory Bitmap

Blog | MayaFPS: First Person Controls in Maya | Curver - Fastest Line-art Tool Ever! | RefreshBrowser: Notepad++ plug-in for webdevs

SymLinked

1,233

Author

June 26, 2012 05:43 PM

Thanks Amr0!

But the return value of DWordAlign with the argument of (32 / 8 * 1366) is the same as the argument so it has no effect.
GDI Memory Bitmap is a very useful resource though, I'll keep poking and see what's different from your implementation!

Thanks again.

SymLinked

1,233

Author

June 26, 2012 08:42 PM

If you have 4 bytes per pixel, and are using a 1366 width - everything is already aligned to 4 bytes. It would have been different if it was 3 bytes per pixel but that's not the case here.
I'm still looking for suggestions. (Edit: Fixed. See my last response for solution)

Bacterius

13,181

June 26, 2012 09:00 PM

Code, please. Without the actual details of how you obtain this result we can't do any better than vaguely theorize on why you aren't getting what you want. The shearing clearly indicates you are getting out of sync with the pixels on a per-row basis, and the color corruption is just weird.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

frob

46,223

June 26, 2012 09:17 PM

The image sheering looks like a textbook example of not accounting for the row length. Each row has a few pixels from the next row, causing the row below it to be shifted a few pixels.

Win32 - capturing screenshots and odd resolutions

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Win32 - capturing screenshots and odd resolutions

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines