Okay, so, I had a problem where whenever I tried to resize or move my window, rendering would halt. Which was weird, because my Render() function isn’t in WndProc at all, it’s in my main loop. I partially solved this by having WM_SIZE and WM_MOVE both call the Render() function, but the animation still stops whenever I click on the title bar or on the border of the window. I’ve been hunting for what message windows sends when it does this, as WM_ENTERSIZEMOVE is the closest I got, but that only gets sent once, not every frame like WM_MOVE or WM_SIZE. I tried making WM_ENTERSIZEMOVE turn on a bool that tells WndProc whether or not to render, but that just didn’t work at all. The main reason that this is an issue is because while the animation stops, the music (playing via OpenAL) does not, which could easily cause sync issues down the line.
I could make it so that the programs is suspended whenever focus of the window is lost, which I presume would be any case that would get in the way of rendering, but I’d much rather just make it keep rendering no matter what the user is doing (unless they’re in another window - I already check for that via WM_ACTIVATE).
(I apologize, this probably isn’t an OpenGL-specific question, but it’s been bugging me nonetheless).
Investigate the WM_NC*** messages. This behaviour is kinda normal (freezes window while you hold mouse button on title-bar, and haven’t moved the mouse since that button-press), and so far I’ve only seen it solved if you don’t have a titlebar.
Truth is, I was planning to multithread anyway, for file i/o mainly. Could you point me towards a good opengl multithreading reference? Or multithreading in general - I hear opengl itself isn’t good with threads, but that’s no reason not to multithread the rest of the game.
Anyways, either way, the rendering will still have to be done in a window - how will multithreading solve an issue caused by the window?
Anyways, either way, the rendering will still have to be done in a window - how will multithreading solve an issue caused by the window?
Because if Windows doesn’t want your GUI thread to get a timeslice, then it doesn’t get a timeslice. But if the game logic is in another thread, at least you can keep the game logic going, so that when Windows lets you draw stuff again, time will have properly passed.