GDI drawing...
Author
I have a question of when to draw & update a window in GDI. I have a class with a function:
Game::DrawMap()
{
FillRect(backbuf, &r, (HBRUSH)GetStockObject(BLACK_BRUSH));
BitBlt(primary, r.left, r.top, r.right, r.bottom, backbuf, 0, 0, SRCCOPY);
}
For now it just paints a black background in the backbuffer and swaps it back to the primary (screen). It will do all the actual drawing later!!
Question is:
When & where should I call DrawMap and when & where should I place UpdateWindow()???
Thanks,
Ivan
<< Question is: When & where should I call DrawMap and when & where should I place UpdateWindow()??? >>
I'm learning GDI as well. If you are using double-buffering (which you are), then DrawMap should be called once a frame, probably at the beginning of your drawing, before anything else is drawn. The order for each frame is
(1) erase your back buffer
(Your FillRect and BitBlt for double-buffering should be done outside of your DrawMap function, not inside as you have it, unless DrawMap is going to contain your only graphics drawn)
(2) DrawMap to back buffer
(3) Draw the rest of your graphics to back buffer
(4) Copy back to front buffer
(5) Wash, Rinse, Repeat 30 frames a sec approx.
I'm using full screen in GDI so I don't need to worry about the window, mine is 800 x 600 at 16 bpp.
VazGames.com
Phil P
[edited by - PhilVaz on September 4, 2003 10:49:17 PM]
I'm learning GDI as well. If you are using double-buffering (which you are), then DrawMap should be called once a frame, probably at the beginning of your drawing, before anything else is drawn. The order for each frame is
(1) erase your back buffer
(Your FillRect and BitBlt for double-buffering should be done outside of your DrawMap function, not inside as you have it, unless DrawMap is going to contain your only graphics drawn)
(2) DrawMap to back buffer
(3) Draw the rest of your graphics to back buffer
(4) Copy back to front buffer
(5) Wash, Rinse, Repeat 30 frames a sec approx.
I'm using full screen in GDI so I don't need to worry about the window, mine is 800 x 600 at 16 bpp.
VazGames.com
Phil P
[edited by - PhilVaz on September 4, 2003 10:49:17 PM]
Author
Further question...
In my DrawMap function I just clear, draw and do stuff in the backbuffer and flip to the primary. I do not call UpdateWindow or RedrawWindow.
How come windows knows that a repaint is necessary??
And secondly...
Show the drawing be done at the beginning of processing keyboard/mouse input, etc...??
Ivan
In my DrawMap function I just clear, draw and do stuff in the backbuffer and flip to the primary. I do not call UpdateWindow or RedrawWindow.
How come windows knows that a repaint is necessary??
And secondly...
Show the drawing be done at the beginning of processing keyboard/mouse input, etc...??
Ivan
<< Phil: What kind of speed do you get with fullscreen GDI? >>
Dunno, haven't learned how to compute speed yet. I lock at 30 frames a sec approx, and it looks fine. No flickering/tearing. I'm using the simple thing with GetTickCount from Lamothe's book to lock at 30.
I'll stick with GDI for a little while more, finishing a PacMan with Bitmaps, and gonna do one vertical scroller driving game like the old SpyHunter from 1983. I'm 37 btw, so I remember that game.
Phil P
[edited by - PhilVaz on September 5, 2003 9:27:58 PM]
Dunno, haven't learned how to compute speed yet. I lock at 30 frames a sec approx, and it looks fine. No flickering/tearing. I'm using the simple thing with GetTickCount from Lamothe's book to lock at 30.
I'll stick with GDI for a little while more, finishing a PacMan with Bitmaps, and gonna do one vertical scroller driving game like the old SpyHunter from 1983. I'm 37 btw, so I remember that game.
Phil P
[edited by - PhilVaz on September 5, 2003 9:27:58 PM]
quote:Original post by quantWow, I used GDI the first time like a year ago, and I must have been doing something wrong. I don''t know the # of FPS, but it was SLOW. I''ll have to give it another go. I suspect it was because I wasn''t using the double buffering technique. I''ll have to give it another go, now that I have a better handle on programming overall.
Dunno about full screen speed, but i get 900fps on my 600*400 window using the gdi
<< How come windows knows that a repaint is necessary?? >>
I''m not sure about that. If I understand what that means, a "repaint" needs to be done when someone minimizes then maximizes your game if you are doing the game in a window, and/or someone moves another window on top then back off your game window. If you are constantly erasing the back buffer and BitBlt to front buffer, I think the repaint is irrelevant. I don''t know enough about Win32. But to solve those problems you can go full screen in Win GDI only as well (with WS_POPUP, ChangeDisplaySettings, and a DEVMODE struct).
<< And secondly... Should the drawing be done at the beginning of processing keyboard/mouse input, etc...?? >>
The order there probably doesn''t matter. You can update your screen, then check for input, or check for input first, then update your screen. Shouldn''t make a difference.
Phil P
I''m not sure about that. If I understand what that means, a "repaint" needs to be done when someone minimizes then maximizes your game if you are doing the game in a window, and/or someone moves another window on top then back off your game window. If you are constantly erasing the back buffer and BitBlt to front buffer, I think the repaint is irrelevant. I don''t know enough about Win32. But to solve those problems you can go full screen in Win GDI only as well (with WS_POPUP, ChangeDisplaySettings, and a DEVMODE struct).
<< And secondly... Should the drawing be done at the beginning of processing keyboard/mouse input, etc...?? >>
The order there probably doesn''t matter. You can update your screen, then check for input, or check for input first, then update your screen. Shouldn''t make a difference.
Phil P
When a window needs to be redrawn, the WM_PAINT message, is sent once (and only once). After an internal WM_PAINT message is returned from GetMessage or PeekMessage or is sent to a window by UpdateWindow, the system does not post or send further WM_PAINT messages until the window is invalidated or until RedrawWindow is called again with the RDW_INTERNALPAINT flag set.
This can happen for a number of reasons:
1.) The window is minimised and maximised.
2.) The window is resized (and moved as well, I *think*).
3.) Another window "appears" in front of the application window, meaning that some of it needs to be redrawn.
4.) When the window rect is invalidated (afaik).
There is also a message, WM_NCPAINT, which is sent to a window when it''s frame needs re-painting. I''d imagine it''s triggered in the same ways listed above.
--hellz
This can happen for a number of reasons:
1.) The window is minimised and maximised.
2.) The window is resized (and moved as well, I *think*).
3.) Another window "appears" in front of the application window, meaning that some of it needs to be redrawn.
4.) When the window rect is invalidated (afaik).
There is also a message, WM_NCPAINT, which is sent to a window when it''s frame needs re-painting. I''d imagine it''s triggered in the same ways listed above.
--hellz
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
