Here is what I had to do to install it:
- 1. download a binary file (the data)
- 2. download another binary file depending on which video card
you have (the program)
- 3. create a new directory
- 4. extract those files into the new directory
- 5. read some install instructions FAQ for the game
- 6. get some obscure library for the sound. (this library is not in debian)
- 7. unpack and read the README for this obscure library.
- 8. find the '.so' file within the directory tree of the unpacked library.
- 9. copy the .so file from step 8 into /usr/local/lib
- 10. have flashbacks to screaming unix bigots yelling at you not to put
it in /usr/local/lib, or whatever, and beating you up, and stealing
your lunch money, and having your thesis trashed and having you kicked
out of university. curl into fetal position and cry a while.
- 11. ldd the 'racer' binary to see if it found the .so file from step 9.
- 12. no it didnt, so run 'ldconfig'.
- 13. realize i need to be root to run ldconfig, so run 'su'.
- 14. try again, this time ldd works.
- 15. notice that racer startup screen runs about 0.02 frames per second.
- 16. remember the FAQ you read says you need DRI to be at a decent speed.
- 17. remember DRI has something to do with Xwindows.
- 18. flashbacks to unix bigots, screaming ""dont say xwindows"". more crying.
- 19. poke around in /var/log/XFree86* for anything relating to DRI using grep.
- 20. notice a message in the logfile that says ""DRI doesnt work for tdfx with 32 bpp, restart X with 16bpp for this to work""
- 21. ponder the best way to do the restart of X in 16bpp mode.
- 22. look at kdm to see if you can make kdm do it
- 23. give up and kludge something in yourself to play the @#$@#$ game.
Ok, here is the 'standard procedure' that i suppose
most people might have tried so far. But step 22
requires a bit of 'creative thinking' so here goes.
Note that I have no formatted this section at all,
I merely wanted to give a feel for the sheer amount
of grinding and churning and typing my mind
went through in trying to figure out how to get
this game to run. Actually rewriting it for
readable purposes would take perhaps 5 hours.
I would have to reform all the half-intuitions
into pseudo-logical explanations of why I did
what I did. But this is a kludge, and its spirit
is by nature impenetrable and illogical. Thus:
i had no desire to ruin my wonderful kde setup and put it some
retarded 16 bpp mode, so i resolved to just login on console,
try to remember how to run 'startx' with -bpp -- --bp - 16 - - -- whatever
so that it would be in 16bpp mode, hoping that it hasnt futzed
with my kde. anyways it doesnt work. it gives me '/dev/dsp: device
is busy'. i assume kde has screwed with the sound so i will try again.
same error. in fact it is 'esd_open_sound: cannot open /dev/dsp: device
or resource busy'. with that extremely helpful bit of advice i go off
and try to start x without kde popping up. how? by making a new user.
login as root. adduser. shit wrong password. ok adduser again.
ok now add the 'racer' user to the 'audio' group. logout. login
as racer. ok now see if i can remember how to startup X. edit
~/.xsession. put in 'flwm & ; sleep 1000000' into ~/.xsession.
exit, then run 'startx -- -bpp 16'. ok. seems to work. ok then
remember that i unpacked 'racer.tgz' under the user 'don' so user 'racer'
wont have access to it. su to root, move the files over to /home/racer,
try again. ok seems to load, but seems to lock up too. flashbacks
to unix people telling me 'its not locked up just get on another
computer and telnet in and kill X and restart it.' curl into a ball
and cry some more. thankfully linux started responding again after about
10 seconds and let me kill X. try again. wonder if its slow because the
computer is slow or because its not loading dri. look at /var/log/Xfree86
files to see what they are saying now about DRI. cant figure out logfile.
erase logfiles and restart. ok it says its still not in 16 bpp mode,
it thinks it is in 32bpp mode so DRI wont work.
so i guess startx -- -bpp 16 is not really putting it in 16 bpp mode?
what next to try.... well,lets see what startx has to say by doing
startx -- -bpp 16 &> logfile. oh there is a message that flashed so fast
on the screen i couldnt read it! i thougt there had been something
there. it says -bpp is no longer supported. so try -depth now. ok
so i am assuming it was slow becauswe it was not in DRI and was in 32bpp.
notice that the program doesnt 'detect DRI and/or 32bpp' it just runs
ass slow. ok. startx -- -depth 16. ok that works.
ok racer seems to start but the startup menu is just a white blur
with a bunch of purply junky looking menu buttons on it. well, i guess
the first one must be somethin gimporatnt so i click on it. oh and
now what happens? it is ass slow, even tho i have the 'min system
requirements'. i assume it means for lower resolution so futz around
with /etc/X11/XF86Config-4 and see what resolution is in there
and see if i can make it do 640x480 now. ok erase '800x600' out of
the 16bpp mode. restart x. ok now it seems to work. game is alpha
level, shows lots of promise, seems to have good following on internet,
So there was the way I installed it. This probably took an hour. Notice
there are something like 60 individual steps to perform, many of them
requiring familiarity with alot of linux command line mumbo jumbo
and text based configuration files, including grep,
/etc/X11/XF86Config-4, ldconfig, /usr/local/lib,
~/.xsession, and on and on and on.
Here is the way it should have worked:
apt-get install racer
Anyways, that's the end of the report. The possible solutions for
these problems are many, but let me point out that at no point
is the solution the following: 'the user is an idiot and should have to learn
a bunch of tedious bullshit to make him/her smarter'. Tedious
bullshit has nothing to do with intelligence, or how much
you know about computers, or how big your unix-weiner is.
It is just tedious unnecessary bullshit that could have been prevented
in the planning stages of the various products that are involved
(x11, xfree86, linux kernel, ld.so, etc etc etc).
Note that in many linux circles, such as the
irc channels, newsgroups, slashdot, and message boards,
I would receive exactly this 'the users need
to learn every detail of unix' attitude.
No, they dont. They shouldnt. And even an expert
in Unix would be tearing her/his hair out at all
the impossibly mind numbingly boring tedium
that you have to go through to get a graphics and
sound program to work properly on linux.
It is true that linux users do not buy game
products very much. Gamers buy game products.
But really, people who
use their systems for gaming would have no problem
buying a linux version and booting it in linux if linux
actually had a snowballs chance in hell of working properly.
It would even be totally possible for the game
manufacturers to include a sort of 'miniature linux'
within their game, so that when you ran windows it would
reboot into MSDOS mode and load linux and the game
would start up. Or they could bundle vmware, much the same way
they used to have to bundle Dos-4gw protected
mode extender with DOS games in the late 1980s/early 1990s.
Lord knows gamers do not appreciate having to
be beholden to microsoft, having to upgrade drivers
all the time, or deal with windows foibles. But
they do appreciate things like install shield
wizard and directX.
The game companies cant really program
for linux. Without the fundamentally basic things,
namely a stable and correct sound and graphics subsystem,
you cannot do anything with games. By stable
I mean the API is stable over time, and backwards
compatible as much as possible. I also mean
that the API has consistent and easy to use functions,
like 'set the screen into resolution xyz with
abc many colors'. Such a basic thing as that is still
a herculean task for a linux graphics programmer,
because he/she doesnt know if she is in X,
framebuffer, or what. And even with wrapper libs
like SDL, you still cant get enough information
back from them to tell if the 'mode setting' operation
succeeded or if it left your user with a postage
stamp size window in the middle of their X display.
I also mean that the system does not hangup, become unresponsive for
minutes at a time, or require you to 'log in
from a different computer over telnet, kill X,
and restart X.'. These things are the absolute
fundamental basics of a gaming platform without
which you really have nothing worth looking at.
This is what microsoft has been attempting to do
with DirectX for the past several years, all backwards
compatible with each other to a large degree.
It is what Nintendo and Sega and Sony have been
doing since forever with their game consoles.
The PS-One is still selling for 100 bucks
a pop, and it only has 2MB RAM. Talk about technical
inferiority beating the pants off the 'technically superior'
Meanwhile linux has about 5 different graphics libraries and
3 or 4 different sets of sound drivers, let alone
sound libraries, and none of them even come close
to working as well as DirectX for the purposes
of having a stable API that actually has dependable
output. Not that DirectX is all that great, I mean
it crashes alot and so does Windows, but
at least a programmer has a fighting chance that
their program will be able to be installed in a few
steps, start up in a certain video mode and play some sounds.