Thread: Having only one function run at higher priority

So what am I supposed to do then?

probably - read this thread from the beginning trying to pay attention this time to what is being said?

Once again, you've misunderstood something. My program, whether it uses 40% of the CPU or 90% has no effect on the frame rate, until it would otherwise go above 100% where it logically would drop (and I would expect the jerky motion). I was referring to other processes in the background (and I've stated this too). To rule out my program as the culprit, I just set the ground resolution to an unusually high quality setting to have an extremely high number of position calculations and drawing (even though I've optimized my drawing function) and the frame rate really drops (the maximum quality, 1, has barely 4 fps, but even something like 30 still looks quite good, though I typically use 14 which has only 4 percentage units more CPU usage than 30. MoveObjects has no drawing functions in it at all and is no longer used in "AdvanceClock" (it used to be, but is no longer present, the optimization I made to it (if you didn't notice the lack of these in that function)). It mostly consists of stuff like this (and lots of it (highly repetitive - copy paste used)):

Code:

		PrelakeHills04.x -= (AverageXSpeed/PrelakeHills04.Scaling/6.0);
		while (PrelakeHills04.x > 0.0) { PrelakeHills04.x -= 1536.0; }
		while (PrelakeHills04.x < -1536.0) { PrelakeHills04.x += 1536.0; }
		PrelakeHills04.XMain = (int)PrelakeHills04.x;
		PrelakeHills04.y = (height/PrelakeHills04.Scaling)+(240-PrelakeHills04Info.biHeight);
		PrelakeHills04.YMain = (int)PrelakeHills04.y;

All (100%) of the drawing stuff is done entirely in the "DrawScenery" function, immediately after the function to find positions. This is the main loop:

Code:

	while(GameRunning == 1) // this is the main loop
	{
		PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE);
		if (msg.message == WM_QUIT) // check for a quit message
		{
			GameRunning = 0; // if found, quit app
			break;
		}
		
		else
		{
			FramesProcessed++;
			SecondsFrames = (float)FramesProcessed/60.0f;
			// At the start of each frame, the clock is advanced as close as possible to 1/60 of a second.
			AdvanceClock();
			
			// Next, keyboard input should be processed so I know to move the objects
			ProcessInput();
			
			// After that, the positions of the objects are processed to find out where things should be drawn to
			MoveObjects();
			
			// Then, the scene must be drawn based on those calculated positions
			DrawScenery();
			
			/*
			DebugPointerTest[1] = PrelakeHills01MainDataPointer;
			DebugTest[1] = (double)DebugPointerTest[1]; // zero, invalid
			DebugPointerTest[2] = PrelakeHills02MainDataPointer;
			DebugTest[2] = (double)DebugPointerTest[2]; // nonzero, valid
			*/
			
			// Finally, translate and dispatch any messages into event queue so other programs can run
			Sleep(1); // wait some milliseconds
			TranslateMessage(&msg);
			DispatchMessage(&msg);
		}
	}

The drawing is only done once per object per frame and at the very end. If I don't lock the frame rate to a constant value, jitter or ripping occurs due to monitor synchronization (I've got a temporary one-time-needed fix for this - tapping Z a few times to slightly adjust the "actual" variable).

I proposed the idea of setting just the "AdvanceClock" function to a higher priority since, by increasing the priority of any program, any jerkiness it has practically disappears all together. I always do this with GameBridge's software since it really gets jerky when Norton runs its automatic updates and using "Above Normal" for GameBridge's software causes all jerkiness to disappear. GameBridge's software also has the same issue as my own program with the case of other programs using the CPU causing lost frames (and this program uses 30 or 29.97 fps (not sure which, though the latter is more likely knowing NTSC TV)).

Do you really use Norton crap? You know their software is poor, right? Just seeing as how their update causes other programs to jerk speaks volumes about their quality.
And the "jerkiness" due to monitor synchronization... I don't know, but is that kind of like V-Sync?
I also notice your loop is kind of average. I made up my own fixed-rate function that locks FPS if you're interested to see it.
It kind of works on the principle to call back X times per specified time interval via a callback function, either via a global function or a class.

You're doing nothing but lieing to me, or contradicting yourself. You're not answering my questions.
And now you've finally posted what I asked for originally. Talk about squeezing blood from a stone.
Don't you try and tell me one more time that I'VE misunderstood something. What you mean is that YOU just cannot explain yourself properly.

It sound to me like you're now saying that your ONLY problem is that you're getting tearing due to not vsyncing. Fine, do vsyncing then.

The Windows message handling function you posted may have a bug. You shouldn't call TranslateMessage, or DispatchMessage when PeekMessage returns zero. This may cause the last message to be processed multiple times, unless PeekMessage clears out the message lpMsg points to in this case, which msdn doesn't say. Why the extra sleep at the end?

It's not vsyncing that I'm concerned over and that's not what I was after. I'm not lying either. I'll just leave it as I've got it for now; it's getting too far out of hand....