Q2 Win32 Tutorial: Dont be a CPU hog!

[bitshifter]

This tutorial will show how we can lower the CPU usage while playing Quake2 on Win32.

Step 1) Open the file /qcommon/common.c and add the new global variable:


...
cvar_t *showtrace;
cvar_t *dedicated;
cvar_t *share_cpu; /* ++ bitshifter */
...

Step 2) Scroll down to the Qcommon_Init procedure and add this code:


...
#ifdef DEDICATED_ONLY
dedicated = Cvar_Get ("dedicated", "1", CVAR_NOSET);
#else
dedicated = Cvar_Get ("dedicated", "0", CVAR_NOSET);
#endif

/* ++ bitshifter */
share_cpu = Cvar_Get ("share_cpu", "0", CVAR_ARCHIVE);
...


Save and close the file.

Step 2) Open the file /qcommon/common.h and scroll down and add this to the MISC section:


...
extern cvar_t *share_cpu; /* ++ bitshifter */
extern cvar_t *developer;
extern cvar_t *dedicated;
extern cvar_t *host_speeds;
extern cvar_t *log_stats;
...


Save and close the file.

Step 3) Open the file /win32/sys_win.c and add this code to the WinMain procedure:


...
while (PeekMessage(&msg,NULL,0,0,PM_NOREMOVE))
{
if (!GetMessage(&msg,NULL,0,0))
Com_Quit();
sys_msg_time = msg.time;
TranslateMessage(&msg);
  DispatchMessage(&msg);
}

if (share_cpu->value) /* ++ bitshifter */
Sleep((DWORD)share_cpu->value);

do
{
newtime = Sys_Milliseconds();
time = newtime - oldtime;

} while (time < 1);
...


Save and close the file.

Step 4) Compile your sources and go test it out

By default the share_cpu value is zero, causing it to be a CPU hog (like normal).
You can ask the console its current value by typing: share_cpu
You can set the value by typing: share_cpu 10
You can clear the value by typing: share_cpu 0
The value determines how long the task scheduler sleeps.

Of course we are trading FPS for CPU time, but on fast PC is no problem.
A steady 24 FPS is all you need to have smooth playable game.

On my 3+ ghz Pentium 4

share_cpu 10
CPU usage 50~60%
FPS 25
REF ref_soft
REZ 1024 768 FS

0 sets it to off
10 sleeps 10 milliseconds
...
20 sleeps 20 milliseconds
...

Any comments or criticism is greatly appreciated.
Have fun

PS: How do i define colors in code?

[Paril]

Not a bad idea, although it's kind of counter-productive.

Sleep(0) is actually all you need, because what that does is lets other programs take priority until you start working again.

Depends what you mean by colors - the old Quake didn't have coloring, it was stuck on a 256 indexed palette. Recommend you upgrade to working with a modern engine (and.. uhh, not ref_soft, because it's software, obviously, you'll get much better results being hardware-accelerated).

24 FPS isn't smooth - 60 FPS is smooth, and always will be. It's so close to the way our eyes perceive motion that it appears to be completely smooth. Anything below it and our eyes will see tearing and other artifacts.

Something you're completely overlooking is the fact that modern engines already have FPS limiting via r_maxfps. However, you see, 24 FPS will make the client suffer - the client requires at least 60 FPS to run its internal networking properly and to maintain good physics (the server runs FPS-dependent physics, a long time grudge against the Quake engine). So, no matter how you look at it, you'll need at least 60 FPS on the client side - although you can use modern engines, which have asynchronous rendering, to maintain your "smooth" 24 FPS renderer with a 60 FPS client.

Also, get a better computer. I'm sorry, but, Pentium 4 is the 90s. Everybody is running at least a dual core with hyperthreading these days - I myself am running a six core AM3 processor, and it was cheaper than the Pentium 4 was when it was out.

-P

[knightmare]

It would be better to put the sleep command in CL_Frame, when it's waiting to render the next frame.

The Pentium 4 wasn't from the '90s, it was introduced in 2000 (yes, the godawful Socket 423 Williamette P4 that used Rambust memory). It was actually slower clock-for-clock than a Pentium III. Intel even got sued over this. They finally mothballed it in 2006 when they switched to an architecture that wasn't driven by megahertz-mania marketing, one that was derived from the *gasp* Pentium III, which was derived from the Pentium Pro.

I still often use a 7-year-old Pentium M (also based on the PIII) laptop today, which is a testament to that architecture's endurance. I even upgraded it with a better video card off eBay, and it runs KMQ2 quite well at 1680x1050.

[m]

Okay, way off topic but since this thread is filled with top-notch code-monkeys...

Make a Q2 mod that works with the monsters like this, PLEASE!

www.youtube.com/watch?v=-syxOHFqN0k

Add all the KMQ2 tweakin' goodness and all the wonderful Paril weapon goodness from Brazen and that other (name eludes me) cray weapons mod. The game in the video above is about the most fun I've had playing in ages. The Q2 baddies would work great for this kind of deal.

Oh and while I'm making unreasonable demands, come help me put on a barn roof (only half actually and don't mind the forty foot height) , fix the tractor, replace the aircraft carrier quality anchor cable on one of our zip-lines and cut the 20 acres.

No really, I'd love to map for this style 3/4 isometric Q2 single player, it has endless possibilities. Even the standard weapons load-out would be gnarly.

[Wixen1 [Q2C]]

Man. that video takes me back some 15-20 years, when I played a game called "towers" I think!!.
Some 2D, very dark maze and the enemies was kindda dots or so..lol..oh yeah..those DOS times was really something!!
-W1

[knightmare]

I could easily add a top-down camera mode client-side, as I already have an over-the-shoulder mode implemented. However, decoupling the aiming from the camera could be tricky (i.e. a non-rotating camera that just pans to follow the player). There's no good way to source vectors for aiming lasers, as the MD2 player models don't use tags for the weapon attachment.

Also, the camera would always be directly over the player, unless it was given a large bounding box (only moving when the player moves far enough away) and only used in specially-designed open-ceiling maps (but you'd probably have that covered, Maric).

[Paril]

The whole PIII thing must be why I thought it was introduced in the 90s. I had a P4 for quite a long time, not sure how I lived with it..

-P

[m]

Aug 1, 2011 15:05:05 GMT -5 knightmare said:

I could easily add a top-down camera mode client-side, as I already have an over-the-shoulder mode implemented. However, decoupling the aiming from the camera could be tricky (i.e. a non-rotating camera that just pans to follow the player). There's no good way to source vectors for aiming lasers, as the MD2 player models don't use tags for the weapon attachment.

Also, the camera would always be directly over the player, unless it was given a large bounding box (only moving when the player moves far enough away) and only used in specially-designed open-ceiling maps (but you'd probably have that covered, Maric).

If it was easy, I'd love to try it. This may sound like a pathetic excuse but it's likely the only way I'd see myself spending any real time making single player stuff. I'm sure that's no real incentive for someone else to put labor into a "maybe".

That said, I love to see if you could add the KMq2 "stuff" into the Tread Game Definition File. I hacked mine to work as properly as possible with Jump pads but that's about mu h4x0r skill limits.

There was this project that's gone quiet, it was a side scrolling Q2 thang... errrrmmmmm!