Thread: Graphics: Dealing with multi resolutions?

Hello all. I have a question regarding writing applications involving graphics to support multi resolutions.

SUMMARY:
Essentially I want to adjust my application's graphics' sizes depending on the screen resolution.

DETAILS:
Specifically I am writing a Solitaire game using the Win32 GDI and I wrote/created the code/graphics under a 1024x768 resolution. It looks perfectly as I had hoped utilizing every inch of the game window while properly being able to display all cards. However, when I switch to a lower resolution, such as 800x600 I now have the problem of my images being a bit too large for the new resolution. I have tried:

1) Utilizing the StretchBlt() function instead of BitBlt() to draw each card to the screen. By setting the destination rect smaller cards are scaled down.

Problem: Game now taking up too much CPU as I guess StretchBlt() is just that much slower?!? Instead of 2-5% on card/pile drags I'm getting 75-95%.

2) Drawing the game (every card) to a back buffer using BitBlt() as usual then using StretchBlt() to draw the back buffer to the screen (shrinking backbuffer from 1024x768 to destination rect of 800x600) hopefully increasing speed by reducing StretchBlt()'s from about 30 cards every repaint to just 1 backbuffer -> screen.

Problem: Still too much CPU usage. 75-95% instead of 2-5% with pure BitBlt()'s.

So, uh what can I do to make my application look just as nice on 800x600 -> 1024x768 -> 1600x1200? Do I have to create 3 separate bitmaps of cards? A low resolution one of smaller cards; a medium resolution one; and a high resolution one with bigger card images? Then depending on the resolution load the specific bitmap? (This of course would make my application larger, which I wanted to avoid).

I noticed the Solitaire game that shipped with windows resolves this problem by designing the game in 800x600 resolution and just uses the same card sizes for 1024x768. While this works at higher resolutions the cards get smaller and smaller and so much of the screen is wasted where bigger cards would be more appropriate.

Hopefully, the explaination above of what I'm trying to do isn't too confusing.

Yeah, thats what I tried to do. When my game state is changed (ie a card is moved) I attempted to StretchBlt() all my cards to a back buffer then use BitBlt() to copy the back buffer to the screen. Doing this with the BitBlt() function works great never causing CPU usage to go above 5%. When I replaced BitBlt() with StretchBlt() all of these StretchBlt() calls are sucking up CPU usage at 75-95%. I can't really just StretchBlt() the cards that have moved because as they move they cover up and reveal other cards thus needed those new revealed cards to be redrawn. So basically I am clearing the back buffer each redraw and refilling the entire back buffer again with my game... doing this using all StretchBlt()s just seems too much work for my CPU?!?

Is my game logic faulty? Should I not be clearing my back buffer and redrawing my entire game every repaint()?

Oops nevermind.. after tinkering I found a solution to my problem. Since I cannot delete this thread I might as well make it useful by posting my solution.

1) Create a device context.
2) Select my bitmap image/object into it that contains 52 card images.
3) Create another device context.
4) Load a compatible bitmap into it for drawing.
5) StretchBlt() first device context (1) into the second device context (3) scaling it as desired. (ie to convert my 1024x768 bitmap for use in 800x600 resolution scale down to 80%)
6) Use the second device context for BitBlt()'ing to a back buffer instead of the first device context.

Summary: Achieves the effect of StretchBlt()'ing an image while keeping the speed of BitBlt().


P.S. sorry if my whole thread was confusing.. its kinda hard to write into words what I was trying to achieve.