I want to move the paddles in my game.

int move_paddle = 0;

// this is the main message handler for the program
LRESULT CALLBACK WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
	switch (message)
	{
	case WM_DESTROY:
	{
		PostQuitMessage(0);
		return 0;
	} 
	case WM_KEYDOWN:
	{
		if (wParam == VK_UP)
		{
			move_paddle--;
			return 0;
		}
		if (wParam == VK_DOWN)
		{
			move_paddle++;
			return 0;
		}
		break;
	}
	break;
	}
	return DefWindowProc(hWnd, message, wParam, lParam);
}

void init_graphics(void)
{
		// create the vertices using the CUSTOMVERTEX struct
		CUSTOMVERTEX vertices[] =
		{
			{ 775.0f, 250.0f + move_paddle, 0.5f, 1.0f, D3DCOLOR_XRGB(0, 255, 0), },
			{ 800.0f, 250.0f + move_paddle, 0.5f, 1.0f, D3DCOLOR_XRGB(0, 255, 0), },
			{ 775.0f, 350.0f + move_paddle, 0.5f, 1.0f, D3DCOLOR_XRGB(0, 255, 0), },
			{ 800.0f, 250.0f + move_paddle, 0.5f, 1.0f, D3DCOLOR_XRGB(0, 255, 0), },
			{ 800.0f, 350.0f + move_paddle, 0.5f, 1.0f, D3DCOLOR_XRGB(0, 255, 0), },
			{ 775.0f, 350.0f + move_paddle, 0.5f, 1.0f, D3DCOLOR_XRGB(0, 255, 0), },

			{ 0.0f, 250.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 0, 0), },
			{ 25.0f, 250.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 0, 0), },
			{ 0.0f, 350.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 0, 0), },
			{ 25.0f, 250.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 0, 0), },
			{ 25.0f, 350.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 0, 0), },
			{ 0.0f, 350.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 0, 0), },

			{ 395.0f, 295.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 255, 255), },
			{ 405.0f, 295.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 255, 255), },
			{ 395.0f, 305.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 255, 255), },
			{ 405.0f, 295.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 255, 255), },
			{ 405.0f, 305.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 255, 255), },
			{ 395.0f, 305.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(255, 255, 255), },
		};

pbivens67 said:
I want to move the paddles in my game.

After 3 posts and one blog we should know that.
But there still is no question.

The reason why we are pedantic about questions is (to me at least): Phrasing out a question forces you to define a problem. Which then can be solved eventually.

Keyboard input? Rendering? Is it moving to slow or too fast? etc.

Well I know that the if (wParam == VKUP) { movepaddle--; return 0; } statement works because the PostQuitMessage(0) works in the if statement it closes the window, I also noticed that if I changed the int movepaddle=0 to move_paddle=100 it moves the paddle. sorry about the italics.

pbivens67 said:
Well I know that the if (wParam == VKUP) { movepaddle--; return 0; } statement works because the PostQuitMessage(0) works in the if statement it closes the window, I also noticed that if I changed the int movepaddle=0 to move_paddle=100 it moves the paddle.

Then maybe your problem is that you call init_graphics() just once at startup, as the name ‘init’ suggests.

But you would need to call it each time move_paddle changes (or just every frame), so the vertices get updated. And you need to make sure the vertices are uploaded to GPU as well.

JoeJ said:
But you would need to call it each time move_paddle changes (or just every frame), so the vertices get updated. And you need to make sure the vertices are uploaded to GPU as well.

how should I adjust my code?

pbivens67 said:
how should I adjust my code?

I assume your problem is that you miss GLUT, which is an application framework.
Now you try DirectX, following some Microsoft tutorial eventually, and such tutorials don't use application frameworks, but the native Win32 API.
This API is not made for games, so it's a bit cumbersome to implement a game loop. It's not hard either, but also there is nothing of value to learn by doing it.

But personally i never used application frameworks, so i can give some help. I'm no expert however - just messed around with it until it worked for my needs.
So this is how i do it…

   LRESULT CALLBACK ApplicationFramework::WndProc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) 
	{
		switch (uMsg) 
		{
		case WM_MOUSEMOVE:
			// update my variables storing mouse corsoe coordinates
			break;
			
		case WM_CLOSE:
			PostQuitMessage(0);
			break;

		case WM_PAINT:
			
			
			// For me it would work to put the game loop here, becasue i make sure i get a PAINT message every frame.
			// That's fine as long as the call does not take too long (multiple seconds
), because Windows assumes the WndProc callback returns quickly.
			
			RunMyGameLoop(); // so in this call our game would process player input, update physics, and all those things games do.
			
			Render(); // Render the game using our API of choice. This would include uploading dynamic vertex buffers and transformation matrices, and doing the draw calls.
			
			break;

		case WM_CHAR:
			// adding characters to a buffer of chars, so my app can consume typed text
			globalApplication->AddChar ((char)wParam);
			break;

		case WM_MOUSEWHEEL:
			globalApplication->mouseWheel += GET_WHEEL_DELTA_WPARAM(wParam) / WHEEL_DELTA;
			break;

		case WM_LBUTTONUP:
		case WM_LBUTTONDOWN:
		case WM_RBUTTONUP:
		case WM_RBUTTONDOWN:
		case WM_MBUTTONUP:
		case WM_MBUTTONDOWN:
		case WM_KEYDOWN:
		case WM_KEYUP:
			// here i set a bit for each key if currently pressed, or clearing it if not. I use some array to map from Windows key codes to my own convetion.
			if (GetActiveWindow() == hWnd)
			{
				for (int i=0; i<sizeof(keyMap); i+=2) globalApplication->SetKeyState (keyMap[i], GetKeyState(keyMap[i+1])<0);
 // special keys like UP or SHIFT
				for (int i=0; i<10; i++) globalApplication->SetKeyState ('0'+i,	(GetKeyState('0'+i)<0)); // letters like WASD
				for (int i=0; i<26; i++) globalApplication->SetKeyState ('A'+i,	(GetKeyState('A'+i)<0)); // numbers
			}
			break;

		default:
			break;
		}

		return (DefWindowProc(hWnd, uMsg, wParam, lParam));
	}

So that's just one example of working with Win32 messages.

But i don't think it's a good example, especially the proposal to call the GameLoop() function from within the PAINT message.
Actually i don't do this. What i really do is more like this:

int WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR pCmdLine, int nCmdShow) 
{
	CreateApplicationWindow ();
	// here we create a window, and we also give the pointer to the WndProc() callback shown above to that window.
	// which may look like this:
/*
HWND CreateApplicationWindow (const HINSTANCE hInstance, const int width, const int height, const char *name) 
{
		WNDCLASSEX win_class;

		win_class.lpfnWndProc = WndProc;

		// ...

		RegisterClassEx(&win_class);

}
*/
	// then we run some infinite loop until user closes the window.
	bool done = false;
	while (!done) 
	{
		
		MSG msg;   // message
        while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
		{
			if (msg.message == WM_QUIT) // check for a quit message
			{
				done = true; // if found, quit app
			} 
			else 
			{
				/* Translate and dispatch to event queue*/
				TranslateMessage(&msg);
				DispatchMessage(&msg);
			}
		}
		
		GameLoop(); // measure realtime, react to player input, update physics, etc. I also record command buffers here, which is the Vulkan replacement of 'Draw Calls'.
		
		RedrawWindow(demo->swapchain.window, NULL, NULL, RDW_INTERNALPAINT); // this causes the call of WndProc shown above with a WM_PAINT message, which executes the draw calls, flips front back buffers, etc.
		
		// eventually wait some millisecond to sync to realtime if needed.
	}
	// cleanup - free resources and memory, destroy graphics context, etc.
	return 0; // quit the application
}

There are many ways to do this, and i don't know which is the best.
For example, maybe you noticed some older games have bad input lag if you enable Vsync. If you disable it they run fine. Maybe Dead Space is an example, iirc.
One time i occasionally found out that's actually a result of using some ‘bad’ way of dealing with this Windows stuff. I can't remember any details, but there are sure many things we can do wrong or suboptimally here.
Not really a problem as long we do it just for fun. But in case i'd release a game for Windows (did only mobile yet), i sure would need to learn a bit more about this boring topic.

So have fun with messing around, and doing trial and error until it works.

Or, draw the proper conclusion, which in my opinion is: Scrap the idea to learn a dead gfx API like DX9.
Start with DX11 instead. Microsoft provides proper SDK and examples, and they should show how to do this OS stuff properly. Adopt the code you get from those SDK examples.

Or, scrap the idea to learn another gfx API all together, and stick at OpenGL. It's fine, and there is no value in learning APIs. You have enough to do with learning programming, which has value.

But eventually move on from dead GLUT to something which is still maintained and practical for games, like SDL.
Or get a bit more from real game libraries like SFML or Raylib. They give you OpenGL, application framework, Audio, a math lib fro vectors and matrices, and just lots of useful things. Plus examples of mini games like Pong.
By using such library you save time on reinventing wheels and you have good code to learn from as well.

So choose your next steps wisely ; )

I am helping on a game using dx. I am trying my best to learn it.