Extremely odd bug

Started by
6 comments, last by Blackstream 23 years, 5 months ago
I could really use an explanation if you guys have one. Here is how it is. I have my main file set up LaMothe style (GameMain, GameInit, and GameClose, not the gpdump thing). I am making this wrapper around Dx6 and I got it set up and then I drew some pixels on the Primary surface in the GameInit fucntion. When PeekMessage is called for the first time, the surface is totally wiped. BUT, if I draw any pixels after the first time PeekMessage is called, like in the GameMain funcion, PeekMessage doesn''t wipe my surface. To prove it I set up this code that would execute twice and put it just before PeekMessage. The first time I drew the pixels, PeekMessage wiped it, the second time PeekMessage was called, it wasn''t wiped. Someone please tell me what is going on. It isn''t like this is going to halt development of my wrapper or anything, but I would like to know why this is happening. Oh, and yes I am sure it is PeekMessage that is doing the wiping. If you guys can figure out what is happening, great. If you really need to see my code, I can. -Blackstream -Exerpt from the "How to get killed in gamedev.net forums" book Tip 242: Say this, with all the punctuation and I guarantee you''ll get strange looks or flames hi i have been programming for 3 months now and now i want to make a game sorta like quake 3 could you please tell me where to start thank you
-Blackstream Will you, won't you, will you, won't you, won't you take my virus?-The Mad HackerBlackstream's Webpage
Advertisement
Ok, there are several basic messages dealing with painting a window.

WM_ERASEBKGND
WM_PAINT
WM_SIZE

are a few. WM_SIZE gets called when your window is created, and it sounds like you haven''t handled WM_ERASEBKGND and let the default handler process it, or that you ARE overriding WM_SIZE and have added the erase code there, but not for WM_ERASEBKGND or WM_PAINT.

Without seeing your code, I can''t give specifics, but I''d bet money that one of those messages is where your problem lies.
No, I didn''t override WM_SIZE... That WM_ERASEBKGND is probably my problem. I don''t have any surface clearing code in any messages so I guess it is the WM_ERASEBKGND that is doing this. In the future I plan on drawing on Backbuffers and redrawing every frame, so if the WM_ERASEBKGND message did come up, I would still be okay.

Are there any other messages I need to watch out for besides the resizing, focus, and initiation/destruction messages?

-Blackstream

Just me, and my compiiiiiiiler
-Blackstream Will you, won't you, will you, won't you, won't you take my virus?-The Mad HackerBlackstream's Webpage
yeah don''t forget WM_MOVE you''ll have to update where you blt on the screen. can''t think of any others that i handle besides the power saving or screen saver messages.

crazy166
some people think i'm crazy, some people know i am
Blackstream, you DO want to override the WM_ERASEBKGND message, or else the default handler will call GDI to clear it which is wasted time.
Oh okay. Thanks all, you''ve all been very helpful.

-Blackstream
-Blackstream Will you, won't you, will you, won't you, won't you take my virus?-The Mad HackerBlackstream's Webpage
Won''t the WM_ERASEBKG _not_ be sent if you set the hbrBackground member in the WNDCLASS structure to NULL when you''re registering the window class?
Ech, it''s been a while since I messed with DirectX / OpenGL where you''d want to do this, but as I remember it, even if you specify NULL, WM_ERASEBKGND is still sent, the default handler just does nothing... but... I''m thinking that you''d want to handle it still or you might see some visual artifacts. I could be wrong, but every directx book I ever saw handled the WM_ERASEBKGND message.

This topic is closed to new replies.

Advertisement