A Virus Named TOM
 This topic has been pinned, so it's probably important
flibitijibibo  [developer] Sep 18, 2013 @ 11:14am
PSA (Mac/Linux): Winter Wonderland DLC
Currently, the Winter Wonderland DLC does NOT work on Mac or Linux. This is a known issue.

If you would like an excruciatingly detailed explanation of the issue, keep on readin'. Otherwise, this may bore/torture you, so you can stop reading here. The main point: it was a Mono dependency issue, and we apologize for the inconvenience.

Anyway, here's what's up:

The issue is caused by a .NET/Mono dependency within XNA, and as a result, the original AVNT game. Rather than loading the texture data via the XNA content pipeline (.xnb files), the DLC is loaded directly as PNG and JPEG files, using the Texture2D.FromStream() call:


This seems harmless at first, but the problem is this method's dependency on the "System.Drawing.Imaging" .NET library in MonoGame:


The above block of code is MonoGame's "generic" method of loading texture data from a stream.

This library depends on a native library called libgdiplus, which sounds like it'd just be a matter of adding this one library, but then you look at the dependency list...

This is the unedited `ldd` output of Fedora 17's libgdiplus library:

[flibitijibibo@flibitTower ~]$ ldd /usr/lib64/libgdiplus.so.0
linux-vdso.so.1 => (0x00007fffd7bfe000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2542125000)
libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f2541e79000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f2541bd8000)
libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f25419ce000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f2541693000)
libtiff.so.3 => /lib64/libtiff.so.3 (0x00007f254142f000)
libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007f25411df000)
libgif.so.4 => /lib64/libgif.so.4 (0x00007f2540fd4000)
libpng12.so.0 => /lib64/libpng12.so.0 (0x00007f2540dad000)
libexif.so.12 => /lib64/libexif.so.12 (0x00007f2540b67000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f254094a000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f2540715000)
libc.so.6 => /lib64/libc.so.6 (0x00007f254035e000)
librt.so.1 => /lib64/librt.so.1 (0x00007f2540155000)
libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f253febd000)
libpng15.so.15 => /lib64/libpng15.so.15 (0x00007f253fc93000)
libz.so.1 => /lib64/libz.so.1 (0x00007f253fa7b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f253f780000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f253f562000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f253f35d000)
libSM.so.6 => /lib64/libSM.so.6 (0x00007f253f155000)
libICE.so.6 => /lib64/libICE.so.6 (0x00007f253ef39000)
/lib64/ld-linux-x86-64.so.2 (0x0000003ddf600000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f253ed0f000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007f253eb0b000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f253e905000)

You'll notice such gems as Cairo, FreeType, TIFF, both libpng 1.2 and 1.5, pixman, and glib.

All of this, just for a couple of PNG/JPEG files. I'm not kidding.

Well, actually, if you self-build libgdiplus, you can actually shrink this list down a little bit (for instance, you can require only _one_ version of libpng!), and I've actually done this before in the Linux version of Proteus, with an admittedly decent level of success:


However, even if we were to grab _all_ of these libraries for Linux, we still need to account for OSX, and getting this set up on OSX is nothing short of pure, unadulterated agony. I don't want to know what Jon had to do to make Proteus OSX happy.

So, uh, I sort of just disabled the DLC for the 1.0 ports. Christmas is in a few months anyway, right...?

I wanted to try and open it to where you could at least _attempt_ to load it if you had this library somehow, but it turned out to be _very_ error-prone and crashy, so the "DLC load error" is pretty much built-in at the moment.

"So what's the solution," I hear you ask. My current idea is to load the images ourselves using SDL2# and SDL2_image; SDL2_image would only add 3 library files (SDL2_image, libpng, libjpeg), and we already use SDL2# for MonoGame. I would like to implement this in the MonoGame library, as this is a pretty nasty issue for what could be a very large amount of XNA games out there. Instead of passing a stream, we would create a new method, `Texture2D.FromFile(string)`, where we pass in a file name and then let MonoGame do the rest. It looks simple on paper, but it could take a lot of time to get the data marshaling working on multiple architectures... this is actually why Proteus for Linux is only available in 32-bit!

That's partially why I wrote this whole mess, to be honest. If you managed to get through this without your eyes running for the escape pods, and you're really interested in fixing this issue yourself, I'd love to see someone implement this! I will definitely be busy working on general support issues (both for this game and FEZ), so if you're _really_ eager to see this DLC working, feel free to make a patch for MonoGame-SDL2, and I'll try update AVNT's MG-SDL2 library! That's not to say that I'm just abandoning this bug, but I will definitely admit that this is currently a low-priority issue for the Humble launch.

I've even hooked AVNT up to the FromFile method already, which you can find here:


You can implement this method, and the library you compile should be compatible with AVNT. Errors are printed to stdout.

If someone else ends up patching this, I'd be happy to credit you in some form on future releases, and I'm sure the team at Misfits Attic would be just as appreciative of your work.
Last edited by flibitijibibo; Dec 11, 2013 @ 5:06pm
< >
Showing 1-12 of 12 comments
dilworks Oct 2, 2013 @ 6:07pm 
Love the very detailed explaination (I'm also a coder, but not in .NET/Mono, and I don't code videogames, just boring business applications). And yes, it sounds like a world of hurt!

But whatever, I'll be very busy tortuing my brains with the base puzzles in the meanwhile before even thinking into DLCs :)
mrmitchellgiles Nov 17, 2013 @ 6:16pm 
when did it get a dlc?
Niban  [developer] Nov 21, 2013 @ 8:09am 
Last Christmas. It was a reskin with a couple of achievements that were part of a scavenger contest. Doing each of the achievments dressed TOM up with a more ridiculous costume asset. http://www.avirusnamedtom.com/WinterWonderland.html
Pomefrum Dec 12, 2013 @ 9:03pm 
Thanks for the explanation.
Ru.sh Jun 2, 2014 @ 5:01am 
Any news on this issue or anyone coding away at a solution already?
Niban  [developer] Jun 2, 2014 @ 5:26am 
Clerk6999 Jun 22, 2014 @ 11:48am 
what does this do?
CrossingMoon Jun 24, 2014 @ 3:10pm 
Niban  [developer] Jun 27, 2014 @ 10:06pm 
The Winterwonderland DLC reskinned the game in a Christmas theme. There were 4 achievements added, and each one unlocked an aesthetic change tor TOM, like elf ears.
Holysword Jul 4, 2014 @ 8:50pm 
Nobody fixed that in almost a year?
flibitijibibo  [developer] Jul 5, 2014 @ 1:40pm 
Originally posted by Holysword:
Nobody fixed that in almost a year?
DLC fix got somewhat postponed a bit by my XNA reimplementation's new renderer. Certain games (like AVNT) have a CPU/GPU tradeoff that I want to get rid of first.
MrZap5 Dec 15, 2014 @ 3:11am 
I never had this problem that is intereting
< >
Showing 1-12 of 12 comments
Per page: 15 30 50