Sorry your browser is not supported!

Does anyone else have a problem where your programs have a game loop that runs over and over and that loop takes up close to 100% of your cpu's time? That's great when the game is running I guess, but my game is a windowed mode game so I can do other tasks while the game runs and it's impossible to load another program when my game is running because the cpu is totally hogged up by the DB game. Any suggestions?

Thanks,

Oak

its not a bug, its a feature.

SYNC OFF, will solve your problem, but you will have to work out a replacement timing routine.

But if you're just drawing a few sprites to the screen and checking for mouse clicks in a chess style game, why on earth would sync on cause such an enormous resource drain? Even firing up Unreal or Battle for Middle Earth (memory hog) they don't suck up 90% of my cpu.

Maybe it's the sync command. I havn't looked into it, but is there any way to check if the game is windowed and if it is, to not sync to the screen?

Because its a feature. It really is. But if your program is sitting idle use sync off. There are ways to see if your window has focus or if there has been any input. You can't play a game with sync off cause then your program only gets attention when windows feels like it. Sync on hogs the cpu so windows don't do what sync off does. Makes your program #1 priority.

Also, other sync setting seem to affect the system as well (though I haven't played around to figure them all out). FastSync for example:


Setting the Sync Rate too high (assuming it's on) seems to force the system to start calculating the next frame(s?) before the previous frame is finished drawing, which results in lower performance than setting the Sync Rate at a happy number that doesn't overlap frame calcs.

One program had these results ompc:
Sync Rate 250: FPS < 120
Sync Rate 150: FPS = 110 to 166

DirectX does that. There is no workaround.

Windoze traditionally has very poor resource management when compared to operating systems that were designed to be multi-process/multi-user from the beginning. It follows the "give until it hurts" philosophy when it comes to CPU time, memory allocation, max disk I/O rates, etc. Controlling how much CPU time can be allocated to a given process, how much physical memory it can consume, etc. is an exercise in futility and often cannot be done on Windows since it wasn't designed that way.

When Win NT was on the drawing board, the rumor was big changes were in the works because a principal designer was one of the VAX/VMS architects from Digital Equipment Corporation, and VMS had superb resource management. You could set limits on CPU usage, memory usage, etc. Process priorities determined access to resources and bumps/decrements in priorities followed algorithms that allowed the administrator to build fairness into resource allocation. Unix development followed a similar thread (bad pun, sorry).

Alas, it wasn't meant to be. Big flaws in NT 3 grew into V4 which grew into Win 2000 and XP, which grew into... well, you get the picture. It's very hard to do any kind of resource management on a Win platform. The concept doesn't exist in most cases. You can still bring any Windows server to its knees with a simple program that consumes the physical memory or hogs the CPU.

Maybe this isn't such a bad thing for PC's anyway -- if you're running a game then that's really where your attention is focused anyway. Think of the PC as a dedicated game console while you're playing. It's not really a problem with SYNC in DBPro, it's what does or doesn't happen when you issue (or don't issue) SYNC. You can cause the same problems with a Visual Basic program or C# program or any other programmingh language, without ever bringing DirectX into the picture.

[end of sermon, sorry about that]