Note that these offsets (-6-29) depend on the window manager you're
using (CTWM in my case) and will need to be altered if you're running a different
one. But you get the basic idea...
Update: the newer, winecfg-based releases still support this behaviour,
but not via winecfg (in fact, winecfg in 0.9.1 still crashes when
you try to modify such an entry). If you want to use this behaviour in these newer
releases, you'll have to edit your ~/.wine/user.reg-file. Using the same
example as above:
OK, somewhere at the top of the log it complained that it couldn't execute sof2sp.cfg, so I decided trying to configure my card directly. First up, this file belongs into the base directory. Second, it doesn't hurt having the config files for other Quake 3 engines available for comparison. Now for the hard bit, finding out which values to assign to what. Fortunately, most of the info can be found quite easily in the executable, so do strings SoF2.exe | grep -i video and lo and behold, there's only a handful of results and the one called r_videoCard looks very much like a Q3 config variable, so let's use that. But what value to use? Well, grepping for card only gives a handful of results as well, along which we get exec scalability/card_%s.cfg and scalability/videocards.defs. Both appear to access the Q3 filespace and the first one loads a file with the prefix card_, which is in all likelihood the name of the video card we have to use. So search through the *.pk3 files (they're basically just ZIP files, so unzip -l PK3-file | grep scalability should do the trick). You'll find these files in therest.pk3 (optionally there may be updates in one of the update*.pk3 files), so extract the latest versions of both videocards.defs and the file for your card (mine's card_geforce4.cfg, for instance), which we'll need later. Now we have the necessary info to bootstrap the engine. Create the file base/sof2sp.cfg with the following contents:
seta r_videoCard "card-name"
seta r_ihv "manufacturer-name"
(in my case card-name is geforce4 and manufacturer-name is Nvidia). If you start the engine now, the warnings should be gone and the game should start up. 640*480 only, but it should start up and return a fully filled out base/sof2sp.cfg file on exit. Unfortunately, changing video settings that require reinitializing OpenGL still abort, so you'll have to configure these by manually editing the config file. First up you should set a higher-resolution mode unless you're using a rather prehistoric card. This is not done via the r_customwidth and r_customheight variables, but via r_mode. I don't have a full table (and I'm not interested in one either), but mode 3 is 640*480, mode 8 is 1280*1024 and mode 9 is 1600*1200. If you want another one: experiment. You'll also want to change the colour depth to 32 rather than 16 (the default) via seta r_colorbits "32". As for the other configs: feel free to experiment.
There's still one problem: stability and performance, which was rather abysmal for me initially, with lots of display glitches, jerky gameplay and frequent crashes. I found that this could be alleviated by copying the settings of your scalability/card_*.cfg into your sof2sp.cfg file (in particular configs for texture format and card-specific bugs are vital). With these settings in place, the game performs very well at last. Also make sure you disable all manufacturer-specific OpenGL extensions that aren't your card's manufacturer (so for an Nvidia card disable all ATI-specific extensions).
Should the game start trying to redetect the bloody video card again all of a sudden, the reason for this is most likely that the renderer string returned from your graphics card driver changed. This happened to me when I upgraded from Nvidia's 5336 driver to the more Doom 3-friendly 6629 driver where the name returned by the driver contained PCI rather than AGP all of a sudden (I suppose because on my system AGPGART rather than NVAGP is active). The solution is quite simple: adapt the r_lastValidRenderer variable in your sof2sp.cfg file to reflect this change and everything will be back to normal (hopefully).
Should you have trouble with the violence lock you might want to try starting the engine with the parameters +set lock_password 0 +set lock_blood 0, which should give you access to the violence menu with an empty password, if that didn't work before. Otherwise search the engine binary for the other lock_* strings and set them all to 0 when starting the engine, that should definitely free the menu. Remember: playing SoF without full violence makes Jesus cry, so don't do it ;-).
A last word of advice which is also true for the original SoF: have a look at your ~.wine/user.reg after installation. This will contain entries for Software\\Raven Software\\SoF (and SoF2 respectively). Sometimes when you install other stuff, these will be lost, which means the violence is locked out for good and you're left with the Teletubby-version. I don't know whether this is a problem of Wine or the installer, but since it happened to me the first time I copied these values to another file and if they get lost (which did happen once again in the meantime) just copy them back in, which works just fine. No messy un-/reinstall which wouldn't work anyway since the installer reads this stuff from the registry. And that's that. Enjoy.
Update: looks like using the Soul Cube on Sarge was considered a bug by id, because the 1.3 engine that comes with the Resurrection of Evil expansion pack doesn't allow this trick anymore. Well, so you'll have to kill him with the chaingun after all...
Back to my private homepage.