Status of Subatomic Particle Simulator: PARKED

Well, there have been occasional minor updates on the status of the VIGoV Subatomic Particle simulator since it was exhibited in January 2014, but no real progress, despite optimistic sentiments voiced in the first half of that year. Since then, I have gone on to do first-year physics in university, including a little Quantum Mechanics. This opened my eyes to just how little of an idea I had of what I was doing when I wrote that code. Examining it again, I’m even less sure of what I was trying to do in certain parts.

In short, I don’t believe it to be salvageable. It was a huge project for someone who had never done university-level physics, and, while it was an educational experience, with some interesting (and sometimes impressive!) results, it can’t really be taken any further. The basic ways in which the simulation is carried out appear to be very flawed, but I don’t know how to fix them, despite what I may have told myself in the past. That is why I am suspending development for a couple of years.

Over the next few years, I will be learning about Quantum Mechanics in university. Then I may be able to continue the project, or at least rewrite some sections of it from scratch, on a sounder footing. Until then, I am frankly afraid to touch the code.

So, while I had fun programming it and learned quite a lot, I feel it best to park the Subatomic Particle Simulator indefinitely.

Rayman 2 i nGaeilge!

UPDATE: Version 1.1.1 has been released. Please download that version instead.

Well, I’ve finally got some good old-fashioned game modding to report here. I have finished my translation of Rayman 2 from French into Irish, done with the help of the tool sna_nochar, created by MixerX and distributed on the Rayman Pirate-Community. As a sample of what has been done, here is the first ten minutes or so of the very last β-test of the translation:

I did miss one Lum on purpose, just to test that cutscene (I had previously tested the cutscene where one gets all 5 Lums on the first try). Then, after making this video this morning, I ran through the rest of the game (skipping some optional bits with no dialogue!) to find any other bugs. I am pleased to announce that the translation is now ready, and available for download from this server:

The installation instructions are fairly simple, they are written in the Readme.txt file in the above ZIP, in both English and Irish.

By the way, I used VMWare to record the video. I realised it was easier to test my translation in a virtual machine, since I could switch back and forth to a text editor to make changes, without crashing the game. But running the game in a virtual machine caused the physics engine to run too fast at times, which made gameplay really awkward…

That said, the camera glitch seen in the video happens even without a VM, and seems to be caused by the camera reaching the island too early in the cutscene. I guess my rig’s just too powerful!

My chimera Debian system

Well, it’s been a long time! Since my last post, I’ve discovered that there should have been a fifth “D’oh!” in there – turns out that the way the PCIe slots are arranged on my motherboard means that it’s impossible to pass through one graphics card without the other. That probably explains the blank screen I got when booting into the hypervisor. It all boils down to the fact that I should have bought a higher-end motherboard.

But none of that matters one jot anymore, I’ve moved onto other matters! The hoops through which I tried, and failed, to jump in the last post, were mainly so I could play Rayman Legends. I did wind up being able to play this via Wine, although it was very slow. For a fast-paced game like this, the atmosphere was destroyed. Still, I made do, playing the daily and weekly challenges occasionally.

This all changed when I discovered that VMWare Player exists in a freeware version, and that it gives very good 3D acceleration, even under Linux hosts. Though I had to install various proprietary drivers* to make this work reliably, I was happy. I got Windows Vista up and running in a VMWare virtual machine, and Rayman Origins and Legends both work perfectly under it. Thank you VMWare!

Anyway, since then, I decided to sod the whole Linux Mint Debian Edition thing, especially since they decided to switch their base from testing to stable. I changed my sources list to point directly to Debian Jessie repositories. Since Jessie was frozen last November, this didn’t cause me any problems – until Jessie went stable last month! I proceeded to point my package manager to the “Stretch” repositories and installed a plethora of updates.

I had already started compiling my own kernels some time ago, in order to be ahead of the curve (I’m on Linux 4.0 at the moment). I had to modify the sources of some of the VMWare modules in order to make them compile against the newer kernel. So when VMWare asked me to update a few weeks ago, I expected that these patches would have gone in upstream. I was wrong. The update actually overwrote my patched source with older versions, causing me to have to search out the patches again (this one and this one, if you’re interested). This annoyed me, since Linux 4.0 is now actually the latest stable kernel, so one would expect professionally-developed software to work with it out of the box.

What annoyed me even more is that VMWare Player started crashing on startup after I pulled in the above-mentioned plethora of updates from the Stretch repositories. It became apparent that there was a certain package which I needed to downgrade to make it work with VMWare. In order to downgrade it, I had to add the oldstable (“Wheezy”) repositories to my sources list, in addition to the “Stretch” ones. It was then a simple matter of heading into the package manager and selecting the older version of libgtkmm. This made VMWare work… for a while.

I got one session of Rayman Legends played, then it started crashing again. More Googling revealed that there were issues with libcurl. At first I couldn’t believe this to be the cause, since that post was from 2013! But after a week of being unable to find any other possible causes, I decided to try also downgrading libcurl to oldstable. In order to do this, I also needed to downgrade a number of GNU R packages that depend on it, which I installed some time ago. For some reason, the package manager couldn’t seem to figure out that it was possible to downgrade them all at once, so I had to mark them for downgrading separately, which was tedious. Still, I did it, and downgraded libcurl. And, surprise surprise, VMWare worked! Seemingly even the Jessie version of Curl is quite old…

So, I now have something of a chimera Debian system:

  • It’s basically a Stretch (i.e. testing) system.
  • But there are 21 packages in it from oldstable; these are libgtkmm, libcurl, and several R packages.
  • I also compile my own kernel, so that is a package that comes from neither the testing nor oldstable repositories.
  • And there are several relics of Mint Debian Edition still lurking in the system files – GRUB identifies the system as “LinuxMint GNU/Linux” for example.

So this is fine, but I am annoyed that I have to use any oldstable packages. VMWare in fact comes with its own versions of these packages, but is unfortunately programmed to prefer system ones, even if they make it crash. Again, the current version was released very recently, and I think it’s reasonable to expect that it would at least make provisions for systems that use packages that are too new for it (e.g. version check, fallback on the libraries with which it ships).

~It’s been ages since I last updated this blog. Several things have happened. Notably I finally removed GSL from the Subatomic Particle Simulator, disentangling the legal issues. Unfortunately the inbuilt C++ version of the Gamma Function, that I now use instead, had not yet been implemented by Microsoft in the version of the Visual Studio compiler preferred by Valve. In other words, the Simulator won’t compile on Windows for the moment. I suddenly find myself with more free time, maybe I should tackle that now…

*I’ve been through a few GPUs since by the way – I wish I’d updated this blog! Suffice it to say I have a GeForce GTX 980 now!

My experiences with XEN VGA passthrough

The following post gets quite technical, and employs a bit of jargon. You can read the whole anecdote if you want, or just scroll down to the bottom if you want some advice related to Linux Mint Debian Edition, XEN and VGA Passthrough.

I recently built myself a new computer, and after jumping through many hoops (involving Intel’s Haswell Refresh I believe – seems trying a “Devil’s Canyon” processor with an 8-series chipset isn’t a good idea – D’oh #1!), I got a machine up and running with Linux Mint Debian Edition 64-bit. There is an nVidia card in one PCIe slot, an AMD card in another PCIe slot, and an integrated GPU on my Core i7 that is disabled in the BIOS. Once I had this all set up, I thought it would be child’s play (well, not really, but quite simple) to follow this tutorial and get Windows Vista up and running, and using my AMD card, while leaving the nVidia card for Mint.

Boy, was I wrong! At first everything seemed to be going smoothly, but I had a niggling feeling that it was going too well – this was, after all, a tutorial for normal Mint, not the Debian Edition. My first stumbling block came at step 17, which didn’t give the output hoped for. However, I assumed that this was because I skipped steps 9 and 10, opting for Synergy instead. I forged on, and ended up unable to pass through any devices to the VM – D’oh #2!

At this point, I had Vista up and running, able to control it via VNC, but with no VGA passthrough. Therefore, I backtracked, and I’m not sure what I did, but I ended up with a “no such file or directory” error upon attempting to start the VM, with the unhelpful question “Is xend running?”. Seemingly I could no longer use the XM toolstack for whatever reason. Therefore, I switched to XL with the command:

sudo sed -i 's/TOOLSTACK=.*\+/TOOLSTACK="xl"/' /etc/default/xen

Of course, now problems with QEMU versions started to rear their ugly heads. XEN couldn’t find the right QEMU binaries anymore, and following the instructions wasn’t enough, because I was on Debian rather than Ubuntu. My suspicions were correct after all! I was eventually able to start the VM with the following config file:

firmware_override = '/usr/lib/xen-default/boot/hvmloader'
memory = 8192
name = 'vista'
vif = [ 'mac=00:16:3e:68:e1:01,bridge=xenbr0' ]
disk = [ 'phy:/dev/mapper/guest-vista,hda,w' , 'file:/home/mgkeyes/Vista.iso,hdc:cdrom,r' ]
#device_model = '/usr/lib/xen-default/bin/qemu-dm'
device_model_version = 'qemu-xen'
device_model_override = '/usr/bin/qemu-system-x86_64'
#pci=[ '02:00.0', '02:00.1' ]
pci=[ '02:00.1' ]

Now, you may notice that I’ve commented out the line passing through both the GPU and its sound chip, in favour of one passing through only the sound chip. This is because the sound chip is passed through successfully, and detected by Windows. The GPU, on the other hand, causes the VM to not boot, with the only way to shut it down being:

sudo xl destroy vista

Unfortunate, especially after I had spent so much time trying to get the Radeon driver blacklisted so the card was even available for passthrough.

I was puzzled. Surely my card should pass through fine. After all, all Radeon HD 7000 are supported, and I had bought a card from that series, albeit a low-end one. Or so I thought. What I had bought was a “Radeon R7 250”, which I misinterpreted as “Radeon 7250”. Turns out it’s part of a new series of cards altogether – D’oh #3! It is with considerable shame that I divulge this.

=====The rest of this isn’t really related to VGA passthrough, but it is interesting, and somewhat related to XEN. You can still scroll down to the bottom to see my lessons.=====

So, having cursed my inability to properly research components for my new build, I decided to wait until, some time down the line, support for these cards is properly programmed. (But in the meantime, I wonder how I will play Rayman Legends…) Having given up on the VM’s graphics, I had a look at the host’s. The “nouveau” open-source drivers were being used, which caused the Cinnamon desktop environment to run in software mode, and when I tried to install and run Steam, it didn’t even start for me. Therefore, I decided to give the proprietary nVidia drivers a try. After all, they had worked well on my old system, with the same card (a GeForce GTX 550Ti by the way).

Bad idea. Cinnamon, instead of running in software mode, crashed upon login, leaving me in “Fallback Mode”, which was very unpleasant. To make matters worse, Firefox also crashed any time it was even slightly over-taxed, making even regular browsing quite a frustrating experience. Also the screen went irrecoverably blank any time I tried to exit to command-line to install an updated version of the driver (obtained from nVidia’s site). Defeated, I returned to the nouveau driver, an action which itself involved jumping through a few hoops.

On the up-side, it turned out that I could get proper OpenGL rendering by installing the libgl1-mesa-dri-experimental package. This got Cinnamon out of software mode, allowed me to run Steam, and even play through Portal! Afterwards, I tried a few other things, like playing recordings in MythTV, but ended up coming across this little kernel bug, which affects the version still being shipped with this distro (3.11). Still, I was happy, and was looking forward to seeing what would happen with Portal 2.

What I saw was really ugly, and unfortunately the system became too unresponsive to take a screenshot. nouveau decided to spam all ttys (accessible by Ctrl+Alt+F(1-6)) with error messages, making it basically impossible to even try to kill the game from the command line. After a hard reboot, I thought it might be the same kernel bug again, so I disabled the option “Wait for Vertical Sync” in the advanced video settings. It seems I was on to something, because this time the game didn’t go ugly, but it did freeze with three dots left in the loading progress bar for the first map.

Having already found that exiting to command line no longer turned the screen blank, I decided to have another shot at installing the updated driver from nVidia’s website. It installed successfully, but a reboot produced – you guessed it – a blank screen! D’oh #4!

At this point I realised that I was still booting into the XEN hypervisor, which wasn’t much good to me when VGA passthrough wasn’t working. Therefore, I decided to try the normal kernel, and what did I get? Cinnamon running perfectly and Portal 2 playable! I do have a few visual glitches in normal apps, but I can overlook them (for now).

Now, I publish this in the hope that others can benefit from my experience, so I’ll try to boil it down to a few little lessons that I have learned, and that I hope others may be able to take away from this:

  • DO YOUR RESEARCH! If you see something like “Devil’s Canyon” on a processor, be sure you know exactly what it means. Don’t assume that “R7 250” means the same thing as “Radeon 7250”. This is probably obvious to most, but I failed to do it, and, as mentioned, I am ashamed of that.
  • Try not to assume that tutorials for normal Mint work with the Debian Edition.
  • device_model_version = 'qemu-xen'
    device_model_override = '/usr/bin/qemu-system-x86_64

    seems to work on Linux Mint Debian Edition with the correct QEMU packages installed. These packages include qemu and qemu-system.

  • AMD R7 250 cards DO NOT WORK with VGA passthrough at this time, and it’s probable that other members of the Rx 200 series don’t either.
  • Proprietary nVidia drivers don’t work well with the version of the Linux kernel used in the XEN hypervisor (at least in Debian, or it might just be a Linux Mint Debian Edition thing).

I hope this has been in some way helpful, or at least amusing! Suggestions for improvement or clarification are more than welcome.

Subatomic Particle Simulator now on GitHub!

Well, I have just spent an entire weekend using Windows, amounting to probably more hours than I had spent with this operating system in the previous six months! Of course, this meant that I had to endure loads of automatic updates, their drain on bandwidth and automatic restarts! It was worth it though to get the Subatomic Particle Simulator up, working just as well as it does on GNU/Linux! It’s nice to know that I’ve made this thing cross-platform.

More good news: In the process of porting the code, I realised that the best thing to do was to fork the Source SDK repository on GitHub, and that way avoid all the problems of contaminating a working copy to compile the simulator. It is here, so you can now clone it in a ready-to-compile state, or even download a ZIP file if you would prefer.

Again, same legal restrictions apply – due to incompatible licences, it is not currently possible to (legally) distribute binaries. Once again, I apologise for this, and hope I can sort it out in the future.

PS. If you would like to express your opinions on how legal restrictions like this should apply in the future, please go to this new campaign website.

Release of Source Code of Subatomic Particle Visualiser

Well, this is kind of embarrassing. In October, I implemented the GNU Scientific Library as part of the science project I mentioned in the previous post. Since I was working towards an actual deadline, I guess I was too hurried to thoroughly check what licence the GSL uses. Apparently, I assumed it was licensed under the LGPL, which many GNU libraries tend to be. However, it is actually under the much more restrictive GPL, which forbids me from distributing it combined with any proprietary programme. The code given by the Source SDK for the server DLL (the only thing I actually modified) counts as proprietary, since it is distributed under a licence that forbids selling. Therefore, while experimenting with the two pieces of software together is fine, if I were to distribute my compiled server library, I would be in breach of the GPL.

Therefore, the long and the short of it is that my only option is to distribute my code and the GNU Scientific Library on their own, and let you, the user, actually compile it. To that end, here is an archive containing my code plus the GSL code, in a directory structure that will let it fit right into a fresh download of the Source SDK, plus instructions for getting it up and running:
It is currently designed to compile only on GNU/Linux. A Windows version will be made in the coming days.

Here is a game directory to put in your SteamApps/SourceMods folder:
Once you put it there, don’t forget that you need to add in a bin folder, with the libraries compiled from the source code. They can be found in “sp/game/mod_episodic/bin” and “sp/game/vigov_simulator/bin”, under the Source SDK directory structure.

I apologise for not being able to release a compiled game. In order to do so, I would need to either pick a different game engine or a different mathematical library (or write the code myself…). I may do one of those in the future.

My return to the blogosphere

The time has come for me to return to this blog and explain my absence for the last few months. I was spending a lot of time working on a project for a prestigious science and technology exhibition. As such, between that and school work, I had basically no time to blog, or upload anything more than trivial logo videos to my YouTube channel.
Well, the project is now “finished”, and a selection of the fruits of my labour has been uploaded to YouTube.

The files for this game/tool will be uploaded to this site in a few days’ time, when I have had a chance to sort through them.

Here are some of the things I could have mentioned had I been actively blogging:

  • The change in Saorview frequencies, and how it left everyone with eight extra dud channels in their EPG.
  • The introduction of RTÉ One HD, and the stretching of classic programmes that came therewith.
  • The court cases involving the NSA.
  • Halloween
  • Christmas
  • The New Year

So what’s on the cards now? Well, apart from school, there’s:

  • Sony Pictures Television History Mark IV – I know, when does it stop, right? Well, significant info has been discovered since Mark III was made. Hopefully I can reuse lots of animation from previous videos – the thought of starting from scratch really doesn’t appeal to me!
  • Updates to the spreadsheet-based corporate timelines published on this site.
  • That new Aperture Ireland release I promised but never delivered. Speaking of which, I wonder if Valve will ever get around to porting Portal 2 to GNU/Linux…

Post-release development activity on Aperture Ireland

Just a note to say that advanced chambers are now being developed for our Portal 2 mod Aperture Ireland. A patch has also been released to allow installation with the SteamPipe version of Portal 1. Please read the full post on ModDB for more information.

On the political side of things, Continue reading “Post-release development activity on Aperture Ireland”

How to destroy a Universal logo

There are a few ways of using animation tricks to “destroy” the 2013 logo of Universal Studios (or a Blender remake of it, at least).

Here it is, Warner Bros. Animation style:

…And Mozilla style (which is kind of related, since, you know, Mozilla started off inside Netscape, which was an [AOL] Time Warner company for many years):

Got any more ideas? I’ve released the BLEND file for the Universal remake, so, if you have Blender, go nuts with it! It’s released under the CC BY-SA 3.0 Unported Licence.

Portal comes to SteamPipe

I just found out that Portal 1 seems to have been moved to SteamPipe, and therefore received a GNU/Linux port. This means that Aperture Ireland is closer to having a more efficient install mechanism and the Content Porter is closer to having a more viable replacement. Just a small bit of good news!

EDIT (Two days later): I see L4D2 seems to have made the transition now as well. Portal 2 can’t be far off so!