With cordite in the air, splintered steel, shell casings and powder burns, there’s only one explanation...
If you have any trouble with SG, this is the place to ask.

Moderator: Pardner

Dirty Harry's Dirty Tricks for SG in linux

Postby Dirty_Harry » Sat Jan 16, 2010 5:12 am

The only difficult aspect about
making smoking guns run good
on a single core CPU
is ensuring that the CPU cycles
are spent on the correct process at the correct time.
Otherwise, input is unresponsive or sticky,
or frame rate tends to drop
when closing with another player.
However, when configured correctly,
input is hair trigger responsive
and frame rate is solid!
This post describes how I achieved it.

First, I will assume that you have the appropriate
pre-compiled binary drivers provided by NVIDIA or ATI
installed and configured correctly for those graphics cards.
This is required for optimal performance on those chipsets.
On most other chipsets the xorg drivers work fine.
If the xorg drivers work fine automatically
then there probably is not /etc/X11/xorg.conf
However, if one is using the pre-compiled drivers
then there will be an /etc/X11/xorg.conf
If it exists then it requires careful crafting.

In the
Section "ServerLayout"

there should be the following two lines:
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"

And those sections should be defined separately such as:

Section "InputDevice"
Identifier "Mouse0"
Driver "evdev"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "evdev"
EndSection

evdev driver should be responsible for input events.
Consequently, the xf86-input-evdev
software project, spell, or package should be installed.
And the xf86-input-keyboard and xf86-input-mouse
software projects, spells, or packages should be uninstalled.

Basically, the way it works is that xorg-server, the X server,
connects with hald, hardware abstraction layer daemon,
and receives input events through /dev/event* devices.
They look like:

crw-r----- 1 root root 13, 64 Jan 12 19:42 /dev/event0
crw-r----- 1 root root 13, 65 Jan 12 19:42 /dev/event1
crw-r----- 1 root root 13, 66 Jan 12 19:42 /dev/event2
crw-r----- 1 root root 13, 67 Jan 12 19:42 /dev/event3
crw-r----- 1 root root 13, 68 Jan 12 19:42 /dev/event4

udev automatically create those device nodes
when it loads the module evdev, psmouse, or any
similar related module.
The days of using device node such as:
/dev/psmisc /dev/psaux /dev/psmouse /dev/mouse
are gone.

Now we are 1/3 the way done with configuration.
At this point input should work properly.
Fancy mouse buttons and scroll wheels should work.
However, input might still be sluggish and unresponsive
and frame rate might not be solid.

To ensure input is processed promptly
the processes that handle input
should be mean, bossy and able to grab the CPU
whenever they need it.
As root execute:

renice -20 $( pgrep -u root events/0 )
nice -20 /etc/init.d/hald restart

or

nice -20 /etc/init.d/hald-daemon restart

The kernel process events/0 will now run with nice -20
and the processes started by hald run at nice -20
Nice values range from +19 which is very nice
to -20 which is very nasty.
If X is also running
then giving that a nice value of -5
will also help without allowing it to pig out.

renice -5 $( pgrep X )

Changing the nice values for processes only lasts
for as long as those processes are running.
Therefore, if the processes are stopped, restarted
or the box is shutdown, restarted, or rebooted
then those processes when next run
will usually have a default nice value of 0
Most processes run at nice value 0
Kernel started processes usually have
a default nice value of -5.

Okay, you are now 2/3 of the way there.
This last part tends to improve the graphic performance
of many games where the program tries to hog
all the available CPU cycles.
The way to help this situation is to use a kernel
that has more jiffies per second.
A jiffy is the longest amount of uninterrupted time
that the kernel will allocate to a process.
Of the possible jiffy configurations there is:
tickless ( allocate as needed )
250 jiffies per second
300 jiffies per second
1000 jiffies per second.

The way that a CPU multitasks is like opening a book,
reading a single line, bookmarking it, closing the book
then repeating the steps with another book.
So on a single core microprocessor
multiple processes do not actually run concurrently.
They run sequentially.
However, the kernel will allocate in sequence jiffies to
processes based upon the process's need, priority,
and nice value.

One might think of jiffies as a game of duck duck goose.
At 250 jiffies per second a person is walking normal
around the circle touching people on the head.
At 300 jiffies per second the walk is faster
and the touch is more of a tap.
At 1000 jiffies per second the walker is sprinting
around the circle while slapping people upside the head.

Yes, having more jiffies per second wastes some RAW
CPU power by having the kernel race
from process to process.
However, it makes a good improvement
for creating solid graphic output on single core boxes.

CONFIG_HZ_1000=y
CONFIG_HZ=1000

Those are the lines that should be in the kernel .config file.
When doing a make menuconfig to create a linux kernel
configuration file the option is underneath the menus
one would reach by traversing
Linux Kernel Configuration --->
Processor type and features --->
Timer frequency (1000 Hz) --->
Be sure to unset [ ] Tickless System (Dynamic Ticks)
which will appear at the top of the
"Processor type and features" menu

Not all POSIX provide an easy method to compile
a custom linux kernel.
Usually they provide only pre-compiled linux and modules.
Still if there is a choice for using the kernel optimized
for single core workstation 1000Hz task-swapping
then use that if the processor is single core.

3/3 Steps complete
Okay, now for the bonus steps!
Time to edit
~/.smokinguns/smokinguns/q3config.cfg

seta com_maxfps "30"
seta cg_drawFPS "1"

What that does is locks maximum frames per second at 30
And the second line causes the FPS to show on the screen.
While playing with full detail
my FPS stays between 27-30
Seeing is believing.
So if the FPS plunges below 20
then there is still a problem with
how it is configured.

I will listen to no whiper-snaper yap
about 30FPS being slow.
Movies and television tend play at 24 FPS.
Anything over 15 FPS
looks like a moving picture to almost anyone.
30 FPS is plenty fast to track, anticipate and attack
other players in smokin' guns.
By limiting the FPS this helps ensure that smokin' guns
process and X process do not hog the CPU.
And if 30 FPS is still not fast enough for you
then quaff some whiskey while playing. :)
I sometimes play smokin' guns while compiling software
or running qemu in the background.
When other CPU intensive processes
have a nice value of 10 to 15
then they can eat the spare CPU cycles
while causing no impairment to the enjoyment of
smokin' guns game play.

Smokin' guns does not require a
liquid cooled, over clocked, quad core x86_64 4Ghz PC
with super expensive graphics card that
requires it's own separate power supply and blower.
If the box has near optimal configuration
then it should play fine
even on legacy single core non SMP boxes.
However, with changes involving linux, hal and xorg
finding that optimal configuration can be tricky.
But at least we no longer have to manually program MTRR
to write combine when access graphics memory. :)

Sorry, if this is more technical
than the explanation of the single action 6gun.
Some POSIX might have better automatic optimization
for video and gameplay than others.
However, by following the steps above
then nearly any POSIX should be suitable
for playing smokin' guns.
So I am not making a recommendation
for changing to some other POSIX.
Learning how to tweak the one that is already installed
will be faster than doing a fresh install
of a different POSIX
Besides, all GNU, glibc, linux based POSIX
have basically 90% of the same software on them.
So it is like comparing Fuji apples to gala apples.
I prefer gala. :)

Do not forget to pump
the graphics detail all the way up!
With this configuration the frame rate should
be unaffected by the graphics detail setting.
Enjoy.
I will be looking forward to blasting you with a sawedoff.
Dirty_Harry
Newcomer
 
Posts: 1
Joined: Fri Jan 15, 2010 12:00 pm



Postby Tequila » Sat Jan 16, 2010 6:18 am

Hello and Welcom Dirty_Harry,
Thanks to share your advanced experience
;)
User avatar
Tequila
SG Team
 
Posts: 1100
Joined: Thu Nov 15, 2007 11:33 pm
Location: Montpellier, France



Postby RailedRobin » Sat Jan 16, 2010 8:10 pm

Nice to see you on the forum Harry, and thanks for the technicals!
A bullet may have your name on it, but dynamite is addressed "to whom it may concern."
User avatar
RailedRobin
Quick Draw
 
Posts: 54
Joined: Tue Jul 18, 2006 9:57 pm
Location: The frozen north



Postby /dev/random » Sat Jan 16, 2010 9:04 pm

I believe these are micro adjustments. If your CPU and graphics card can't handle the software you want to run, upgrade your hardware.
I can run SG fine with maximum settings and even 4xAA and 16xAF, 1440x900 and average 70fps on my single core 2GHz CPU. So why should I bother using a realtime kernel? If I turn off AA I get stable 125fps.
The only software optimization I recommend is closing unneeded software or even uninstalling it. This really saves valuable RAM and CPU cycles.

And as a final note, don't forget that FPS are still important in Quake3. Even if not for jumping in SG, you still might want to use a high cl_maxpackets value.
User avatar
/dev/random
Smokin' Amigo!
 
Posts: 410
Joined: Thu Jan 22, 2009 1:58 pm




Return to Doc's Office

Show Sidebar
Show Sidebar

User Control Panel

cron