Looks like I might not have to use the OpenNI proprietary blob for skeleton tracking in my research project afterall… Ties in with Gnome 3 nicely as well!
Will have to get experimenting with that bad boy! =D
The Wine “not-emulator” allows you to run Windows software under Linux, but the version in the Debian testing repos (themselves cutting edge) is pretty old, at time of writing it’s a 1.3.6 variant, while Wine 1.5.0+ is now available. Unfortunately, upgrading can be a bit of a pig if you want to build Wine yourself, so a far better solution is to find some Debian binaries and install them. So let’s do that…
Wine binaries are available for a whole heap of different platforms, distros and architectures from http://www.winehq.org/download/, but in this case I’m installing on Debian, so if you are too, head on over to http://dev.carbon-project.org/debian/wine-unstable/ and grab the following packages (either 32 or 64 bit, depending on your architecture – I’m using 64-bit LMDE so I’ll use the 64-bit package names for this quick guide):
Before you can install any new Wine stuff, you’ll first have to uninstall the wine package. Do that through whatever means you feel most comfortable with, ya know, synaptic, apt, dpkg etc.
Once that’s done, you’ll want to install all the libwine packages through dpkg (to be honest, you might not need them all – but it doesn’t hurt, and you’ll certainly need most of them).
To install all the libs, open up the location you saved all the .deb files to in the console, and run:
sudo dpkg -i libwine*
Once that’s completed successfully, in the same location run:
sudo dpkg -i wine-bin*
And finally, in the same location again, run:
sudo dpkg -i wine-unstable*
Almost done!
At this point we’re 99% complete, we just need to launch winecfg and let it install the Gecko engine for web-browser shenanigans (again, you might not need this – but there’s no harm in it, and Wine’ll moan at you about it if you don’t). So just run:
winecfgAnd when it prompts you about gecko, just click on [Install].
New cutting-edge Wine goodness is now yours to play with, although from this point on you won’t get automatically updated as wine won’t be installed from any repository. For this reason, it’s worth holding onto all the debs so you can uninstall them with ease via a swift sudo dpkg -P *.deb (-P for purge) if at a later date you want to go back to the repo version.
As Bryant would say – Drink some for me, eh, pal? 
Every time I’d put my LMDE-running machine to sleep, the wireless wouldn’t come up for maybe a minute or so… which is both new and rubbish. So, how to fix it?
Simple: Change your IPv6 settings from Automatic to Ignore, like this:
If you’re not using Gnome 3 (like in the above screenshot), then maybe try modifying /etc/network/interfaces – really, it’ll depend on your Linux distro where the config is located.
But once IPv6 is disabled, your wireless won’t have to wait for the DHCPv6 timeout, which is the cause of the slow reconnection.
Source: https://bugzilla.redhat.com/show_bug.cgi?id=708450.
When I migrated this site from shared hosting to a VPS, I initially went with some really cheap hosting, and I got what I paid for: The site went down often, like every week or so. Sometimes for days at a time. Support tickets went ignored and unanswered, and I was generally a sad puppy.
After a month or two of this I’d had enough, and decided to migrate the site hosting away from Cheap-O-Host to a company called Linode – and I’ve got to say – it’s been absolutely flawless ever since. I can’t even remember the last time the site went down.
This isn’t to say I haven’t had issues with Apache bogging down and basically killing the site by trying to use more RAM than the VPS has available. If I got more concurrent connections than I had RAM for, then some il-advised Apache settings meant that the server would get into swap territory, and the entire thing would grind to a halt from which the only escape was to log into the VPS from the web interface and reboot it. But this wasn’t Linode’s fault – it was mine for trying to do to much with too little.
I finally solved the problem by disabling all the apache modules I didn’t need (which lowered the RAM usage per Apache process, as well as lowering the server’s attack surface), and limiting the concurrent connections to a number that would happily fit within 512MB of RAM – and since then, not a cough or a hiccup. Everything has been running beautifully.
In fact, at the time of writing, my VPS uptime stats are:
# uptime 21:15:38 up 244 days, 12:26, 1 user, load average: 0.10, 0.07, 0.06
244 days without as much as a reboot! Sweet!
I’m just writing this post to commend Linode because I got yet another monthly email (from siteuptime.com) today saying “site up-time: 100%” and… well, if something goes wrong then people (and definitely me included, here) tend to jump up and down and make a noise – but when something goes right – we generally don’t say anything at all. Which makes the cost of failure getting slagged off, and the reward for success merely not getting slagged off.
As that’s not a particularly good system, I wanted to say something positive about Linode, because it’s not an accident that their systems so rarely go down – I’m sure that it’s entirely due to their hard work, professionalism, and investment & re-investment in the company infrastructure. And I absolutely cannot fault them on that.
So well done, Linode! You guys rock! =D
P.S. For anyone trying to minimise their apache footprint, the minimal set of apache modules I found I needed to run a wordpress site are:
And my final, working Apache prefork MPM settings in apache2.conf for a VPS with 512MB of RAM are:
# prefork MPM # StartServers: number of server processes to start # MinSpareServers: minimum number of server processes which are kept spare # MaxSpareServers: maximum number of server processes which are kept spare # MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves <IfModule mpm_prefork_module> StartServers 4 MinSpareServers 1 MaxSpareServers 1 MaxClients 13 MaxRequestsPerChild 5000 </IfModule>
Cheers!
April 2012 Update: Iain’s cracked the play-without-playfield-texture-or-don’t-play-at-all issue; the trick is to use PlayOnLinux, which forces use of Wine 1.2.2 for FP! See details in the comment here!
I used to play Visual Pinball back in the day on Windows, and when combined with PinMAME for the ROM side of things it was awesome! But when I moved to Linux the PC gaming basically stopped. However, the other day I picked up Williams Pinball Classics for the 360 – and it’s absolutely brilliant! So this got me thinking about whether Future Pinball (the newer incarnation of Visual Pinball) can run in Linux – and with some tweaking, it can!
Without the tweaks you’re likely to get two specific problems:
The good news is that both of these can be fixed with a little bit of tweaking! The bad news is that unless you have a videocard with a lot of VRAM (I’m going to guess 1024MB minimum, as the issue occurs on my 512MB card under Gnome Shell) then tables which you download (but strangely not the Sci-Fi table that comes with FP) are likely to be missing the larger textures such as playfields. This is pretty odd as I can fire up FP in a XP virtual machine with 128MB of video RAM allocated (with far less performance, FPS-wise) and the textures will display without issue – they just don’t like to appear through Wine! So if this is a deal-breaker for you then you might be better off trying Future Pinball under an XP virtual machine, or calling the whole thing off. But if you want to get Future Pinball working in Linux, then we can make it happen…
Note: Wine automatically guesses the availble video RAM on your graphics card, and I’ve got to say, I have no idea if its guess is accurate. I took a look at the Wine useful registry keys and I don’t even have the direct3d key to modify the video RAM settings (because installing DirectX in Wine is considered bad-form, apparently), so I’ve no idea how to tell wine to allocate a reasonable amount of video RAM. Perhaps this will change in the future.
To play Future Pinball you’re going to need a copy of the Wine (Wine Is Not an Emulator) “emulator”, which you can grab from your distro repositories or from WineHQ directly. So either run the following (or your distro’s equivilent package installing command) or grab it from synaptic package manager or such:
sudo apt-get install wine
Once it’s installed, if winecfg doesn’t automatically run, launch it yourself with the command (don’t sudo this!):
winecfgThen, get it to autodetect your drives by going to the Drives tab and clicking on, you guessed it, [Autodetect], like this:
Wine configuration - detecting drives. Your setup will obviously look a bit different depending on the drives you have mounted.
Once that’s done, click [OK] to close down Wine Configuration. By default, Wine creates a hidden folder called .wine in your home directory where it places its files, including the folder that acts as your C: drive in the folder ~/.wine/drive_c.
Now we need to go and grab the Future Pinball installer from here: http://www.futurepinball.com/download.html. At the time of writing the most recent version is: FuturePinballSetup_v1.9.1.20101231.exe. Although this ships with a few demo tables (very, very barebones) you’ll want at least one table to play, so snag a copy of the Sci-Fi Table installer as well from here: http://www.futurepinball.com/downloads/Sci-Fi%20Classic.exe.
Once these are downloaded, navigate to the directory you downloaded them to from the commandline and run:
wine ./FuturePinballSetup_v1.9.1.20101231.exe
Accept the licence, click Next/Next/Finish etc. and that’s done. Future Pinball will now be installed in ~/.wine/drive_c/Games/Future Pinball.
Now install the the Sci-Fi table by running:
wine ./Sci-Fi\ Classic.exe
You’ll want to change the installation directory from the default of C:\Program Files\Future Pinball to C:\Games\Future Pinball during the install wizard for this. Don’t bother creating a Tables folder though, as the table itself contains a top-level Tables folder – so just pointing it at C:\Games\Future Pinball will be fine.
By default, Wine will attempt to run things as Windows XP (as opposed to 2000, or ME, or Vista or 7 etc). This is fine, but as things stand we’re still not going to be able to play any pinball just yet because Future Pinball itself wants to run as Administrator when running in Windows… but we don’t have a Windows Administrator account (in fact, this same issue appears when running FP in Windows natively – if you don’t “Run As Administrator” it, you can’t start a game) – and unfortunately no, sudo won’t cut it So next we need to workaround this by adding a dll and telling Wine to prefer it.
To do this, download the file: oleaut32.dll and place it in your ~/.wine/drive_c/Games/Future\ Pinball/ folder, then run winecfg again. This time you should see “Future Pinball.exe” in the applications pane of the Applications tab – so click on it to select it:
Now click on the Libraries tab, then on the New Overide for Library dropdown. Find the listing for the file oleaut32, click on it then click [Add] (you can leave the default settings as “native, builtin”. With that done, you should see something like this:
With the new DLL taking precedence over the Wine built-in we’ll be able to start a game of pinball, so just hit [OK] to save and close the Wine configuration settings and we’re ready to get our flippers on =D
Wine doesn’t natively support PulseAudio, although it’s fine with Alsa. So to play with sound we’ll need to bypass PulseAudio with the pasuspender util. To do this, all we have to do is launch Future Pinball like this:
pasuspender wine ~/.wine/drive_c/Games/Future\ Pinball/Future\ Pinball.exe
With that done, just press F4 to bring up the table selection window and you should see something like this:
Now click on [Load and Play Table] and we’re good to go.
Future Pinball is like an arcade emulator, so you have to “insert a coin” before you can play. The main keys are:
So to start a single player game you might press 5 to insert a coin, 1 to start a 1 player game, then Enter to launch the ball – and you’re off! This isn’t my video, and it’s prolly not running on Linux, but this is the kind of stuff FP is capable of:
FP doesn’t close down cleanly in Wine, so you have to assist it with a bit o’ the old kill -9
Update: FP will close down properly on Wine 1.5 onwards, so you won’t need to perform these steps. When I originally wrote this I was using Wine 1.3.something.
To find the process ID (PID) run:
r3dux@r3d-laptop:~$ ps -ef | grep wine r3dux 11553 2721 0 09:38 pts/0 00:00:00 pasuspender wine /home/r3dux/.wine/drive_c/Games/Future Pinball/Future Pinball.exe r3dux 11554 11553 51 09:38 pts/0 00:03:40 /home/r3dux/.wine/drive_c/Games/Future Pinball/Future Pinball.exe r3dux 11557 1 0 09:38 ? 00:00:02 /usr/bin/wineserver r3dux 11563 11561 0 09:38 ? 00:00:00 C:\windows\system32\winedevice.exe MountMgr r3dux 11661 2721 0 09:45 pts/0 00:00:00 grep wine
Then to kill the pasuspender/Wine process, enter:
sudo kill -9 <PID-of-pasuspender-process>
So in the above, I’d run:
sudo kill -9 11553
This will get rid of all wine processes so that after a few seconds when you run ps -ef | grep wine you only see this:
r3dux@r3d-laptop:~$ ps -ef | grep wine r3dux 11669 2721 0 09:47 pts/0 00:00:00 grep wine
And on the off-chance that pulseaudio stops working, just run the following and it’ll restart for you:
pulseaudio -kMany thanks to Christopher Leatherly and everyone who had a hand in Future Pinball for its existence, to Mahen for his posts on the WineHQ Future Pinball entry for the fixes needed to get everything running, and to everyone who’s worked on Wine =D
Cheers!
I did try to install FP through the fpwine FP installer script, but it’s legacy because some of the wine options called are deprecated, so I found a modification of the script on ubuntuforums-fr.org, which with suitable tweaking (DCOM98.EXE would throw a fit on install) would install FP into its own ~/.fpwine “shell” but although that added overrides for the oleaut32.dll, ole32.dll, rsaenh.dll and crypt.dll, I still couldn’t get all the textures working in downloaded tables (which would work fine in an XP virtual machine). If I could specify how much VRAM I had to Wine, I think the issue would be solved.
Also, a workaround to minimise VRAM is to disable loading the textures into the editor (available in FP from Preferences | Editor Options…) – but at least for me, it doesn’t minimise VRAM usage enough. And if you’re trying to minimise VRAM and get textures working you’ll probably want to enable non-power-of-2 textures (Preferences | Video / Rendering Options…), try starting tables off at minimum detail settings (i.e. no High Quality textures), and re-start Wine/FP between table reloads as alledgedly it leaks memory (including VRAM), which is only going to make things worse each table you load.
Finally, the fpwine script likes to install version 5.6 of VBScript (vbs56men.exe), which I found completely knackered the table scripts, so I’ve found its best to avoid installing it and leave Wine alone with its own VBScript functionality.
I’m -sure- this is all doable somehow… I just haven’t managed to crack it yet, and it might be the case that Wine needs further work before it can be cracked at all.
The Sci-Fi table works perfectly, but it still feels like 4th and inches to get everthing working 100%…
Comments rss
Trackback
