banehallow
Banehallow 4 posts
None |
#7232
Day 004 screen black when resizing window 1 year, 10 months ago
Hi everyone,
I'm current on Day 4 and I ran into an issue. Sorry if I am posting in the wrong forum -- please feel free to move this to the appropriate section. When I move the window, the animation stops. This is expected, and Casey's does the same. However, upon resize, everything goes black until the resize operation is done. I don't see this exhibited by Casey's executable (around 52:16 in the video for day 4). It looks like the painted area "expands" as he drags to make the window larger. I've looked over the code a couple times and the video as well, but I can't seem to figure it out. Do you guys see anything? Thanks!
None |
Connor_Rentz
Connor 54 posts
It's been so long ;) |
#7233
Day 004 screen black when resizing window 1 year, 10 months ago Edited by Connor on June 11, 2016, 2:13 a.m.
I don't think that this is a problem with the code. The same thing had me confused but when I copied the source from day four I got the same results as you. Maybe it's a windows thing. But I doubt it's the code. I wouldn't worry about it in the end though :P
<C |
mmozeiko
Mārtiņš Možeiko 1636 posts
1 project
|
#7235
Day 004 screen black when resizing window 1 year, 10 months ago
On Windows moving or resizing window happens inside internal modal loop: https://msdn.microsoft.com/en-us/...ary/windows/desktop/ms632622.aspx
DefWindowProc doesn't return until resize/move operation is done. That means your game code in WinMain doesn't run at this time, so it cannot render anything. In Casey's video area "expands", because window size is smaller than bitmap he renders into. So whatever was put in bitmap will remain unchanged. But if he'll resize window large enough, then you'll still see black borders around. |
banehallow
Banehallow 4 posts
None |
#7236
Day 004 screen black when resizing window 1 year, 10 months ago
Okay, that's good to hear. Yea, must be some strange bug. I'm on Windows 10, so I thought maybe that was the issue? So I tried the code on Windows 7 and got the same thing. I think I'll just keep proceeding on. Thanks!
None |
banehallow
Banehallow 4 posts
None |
#7237
Day 004 screen black when resizing window 1 year, 10 months ago mmozeiko Hey mmozeiko, thanks for the link. Right -- that's what was so weird. I expected that behavior too, but I didn't see it. What I saw was that the entire screen goes black. To me, it makes sense that it goes black because in Win32ResizeDIBSection, I'm freeing the previous chunk. It looks like the whole memory block is getting zeroed out as well. Strangely enough, it seems like Casey's copies the contents of the previous buffer. I don't remember him writing any special code for that though.... In any case, I shouldn't get hung up on this and should just push forward. Thanks all for your help! This community is great. None |
mmozeiko
Mārtiņš Možeiko 1636 posts
1 project
|
#7238
Day 004 screen black when resizing window 1 year, 10 months ago Edited by Mārtiņš Možeiko on June 11, 2016, 3:37 a.m.
Oh, I see what is the issue - CS_HREDRAW and CS_VREDRAW flags for WNDCLASS style member. These flags means that window will redrawn during resize or move if some part of window becomes visible because of moving. Without these flags OS simply doesn't update window on WM_PAINT message while resizing. If these flags are set (that's what you have) then OS will display actual content on resizing - which as you correctly say is black because of memory allocation in WM_SIZE.
|
banehallow
Banehallow 4 posts
None |
#7239
Day 004 screen black when resizing window 1 year, 10 months ago mmozeiko Wow. I just rewatched the video again, and at 43:00 I noticed that Casey does not have anything for the style. After removing that line, my program now works just like Casey's! Thanks mmozeiko! I feel like I am following everything line by line, but clearly I miss things here and there :D Thanks again! None |
pulp_user
Simon 3 posts
|
#13767
Day 004 screen black when resizing window 4 months ago Edited by Simon on Dec. 16, 2017, 1:55 p.m.
Hi guys, I know I'm late to the party (about a year and a half), but I have questions:
If I wanted to keep rerendering the scene while inside the modal loop, how would I do that in the best way? I went a bit into the direction of just doing all the calls inside the WM_PAINT message handler, but that would basically mean that I would duplicate my code. Would it be viable to have my whole game logic and rendering in a function, that I could call from inside the message handler? I am currently doing a classical GUI application, and the expected behaviour for them is to repaint while resizing. I hope there are people that will see this reply, if not, I'm just going to post a seperate thread. |
mmozeiko
Mārtiņš Možeiko 1636 posts
1 project
|
#13768
Day 004 screen black when resizing window 4 months ago
Most common way is to create window timer when modal loop is entered, and remove it when it exits. And inside WM_TIMER handler call your game rendering function.
There are more options, but they are more complex. |
pulp_user
Simon 3 posts
|
#13784
Day 004 screen black when resizing window 4 months ago
I did use a timer now, after trying some different things like WM_USER messages or PostQuitmessage. I create a timer when I first receive WM_ENTERSIZEMOVE and in every WM_TIMER that I get until a WM_EXITSIZEMOVE comes in. I was really confused about PeekMessage not returning while one resizes the window, which feels very counterintuitive (I always thought that all messages went through PeekMessage -> TranslateMessage -> Dispatch Message). Since timers have a minimum duration of 10ms I am still interested how to solve that "properly", in a way that wouldn't limit the framerate while dragging. That said: The timer solution is working like a charm currently, so this would be a purely academic endeavour - who needs >100fps while dragging anyway? So thank you very much for posting the timer solution here!
|