C / C++ / MFC

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?

Lord_Vader wrote:

1st)In MS visual studio the stack is 1MB as far as I now.

Lord_Vader wrote:

Why does this happen?

Lord_Vader wrote:

2nd)If someone has a linked list with thousand of elements how he can
reach the whole list using a recursive function?