C / C++ / MFC

If you can't update the games state fast enough to avoid slowing down user input,
it means you can't update the game state fast enough to begin with

Cyrilix wrote:

Then my question is, how do you explain the current crop of games today? They don't update the frame buffer synchronously. They won't be trying to send you 60 frames per second all the time. On heavier scenes, the frames may drop down to the 20s, and on lighter scenes, they may jump up to 150. What else, besides a while loop displaying graphics would do this?

	while(!done)									// Loop That Runs While done=FALSE
	{
		if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))	// Is There A Message Waiting?
		{
			if (msg.message==WM_QUIT)				// Have We Received A Quit Message?
			{
				done=TRUE;							// If So done=TRUE
			}
			else									// If Not, Deal With Window Messages
			{
				TranslateMessage(&msg);				// Translate The Message
				DispatchMessage(&msg);				// Dispatch The Message
			}
		}
		else										// If There Are No Messages
		{
			// Draw The Scene.  Watch For ESC Key And Quit Messages From DrawGLScene()
			if (active)								// Program Active?
			{
				if (keys[VK_ESCAPE])				// Was ESC Pressed?
				{
					done=TRUE;						// ESC Signalled A Quit
				}
				else								// Not Time To Quit, Update Screen
				{
					DrawGLScene();					// Draw The Scene
					SwapBuffers(hDC);				// Swap Buffers (Double Buffering)
				}
			}

			if (keys[VK_F1])						// Is F1 Being Pressed?
			{
				keys[VK_F1]=FALSE;					// If So Make Key FALSE
				KillGLWindow();						// Kill Our Current Window
				fullscreen=!fullscreen;				// Toggle Fullscreen / Windowed Mode
				// Recreate Our OpenGL Window
				if (!CreateGLWindow("NeHe's OpenGL Framework",640,480,16,fullscreen))
				{
					return 0;						// Quit If Window Was Not Created
				}
			}
		}
	}

Cyrilix wrote:

I was thinking of using a key array (of bools) and catching WM_KEYDOWN / WM_KEYUP to change the states of the keys from the input thread, then sending the states to the graphics thread. The input thread would have the WndProc function, whereas the graphics thread would simply check the local key array (in a while loop) to determine what happens.

Basically, it would look sort of like this:

WndProc (which runs in the input thread) catches WM_KEYDOWN where the key is VK_ESCAPE. The input thread sets key[VK_ESCAPE] = true. The graphics thread has a while loop that checks for VK_ESCAPE, and if true, it will return the thread (quit), if it sees another command such as the movement keys, then it will draw the next frame.

Cyrilix wrote:

The graphics thread always has something to do. It has to draw the frames, whether or not user input is entered. If no user input or no AI interaction (that results in a change of what you can see on the screen) is there, then it should just draw the same frame, and then keep on drawing frames forever after that.

First, I'd like to ask whether or not you're disputing my statement above, because everything I mentioned in the last few posts is in question to whether or not you dispute drawing frames continuously.

<br />
while( !bFinished )<br />
{<br />
DWORD dwTickCount = GetTickCount();<br />
RenderFrame();<br />
if( GetTickCount() - dwTickCount < 1000/120 )//we've got loads of time<br />
{<br />
  //do some other stuff<br />
}<br />
<br />
while( GetTickCount() - dwTickCount < 1000/60 )<br />
{<br />
  //Process some user input<br />
}<br />
<br />
}<br />

houari_id wrote:

but I need the position of my bitmaps in the video to be independently changed anytime I want.

houari_id wrote:

I was also failed by using CDC in the same picture control with the vmr video (the CDC drawing is overlapped by the video...)

berni2k wrote:

but how to code this?