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.