• FEATURED

View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Win32 - capturing screenshots and odd resolutions

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

10 replies to this topic

Posted 25 June 2012 - 01: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.

### #2frob  Moderators

Posted 25 June 2012 - 02:46 PM

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.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

Posted 25 June 2012 - 03: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 retrieve the width, height, numBits and format but it looks exactly the same as in all other resolutions.

### #4Martins Mozeiko  Members

Posted 25 June 2012 - 05:52 PM

How are you processing lpvBits argument from GetDIBits function?

Posted 26 June 2012 - 01: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.

### #6Amr0  Members

Posted 26 June 2012 - 05: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 );

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

Edited by Amr0, 26 June 2012 - 05:27 AM.

Posted 26 June 2012 - 11:43 AM

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.

Edited by SymLinked, 26 June 2012 - 11:52 AM.

Posted 26 June 2012 - 02: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)

Edited by SymLinked, 26 June 2012 - 03:40 PM.

### #9Bacterius  Members

Posted 26 June 2012 - 03: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.”

### #10frob  Moderators

Posted 26 June 2012 - 03: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.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

Posted 26 June 2012 - 03:38 PM

Thanks Baterius, I was about to do that but figured it out now.

The above mentioned resources are correct and I'll edit my response. The error was my fault and was caused by me assuming FreeImage would just accept my buffer as is, without calling SetPixelColor() on each individual pixel. The latter works which I guess means I have to read up on how FreeImage stores its bitmaps instead.

Sorry for the misinformation on my side. Everything claimed so far was correct, I was just looking in the wrong spot.

Edited by SymLinked, 26 June 2012 - 03:40 PM.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.