Enigma and the Liberated Pixel Cup competition

[forthevin]

Hi everyone,

I have a couple of questions regarding Enigma and the Liberated Pixel Cup competition that is currently running. For those that don't know, the LPC is a competition for free-as-in-freedom games, with a month for creating free art (which is nearly done, as of this writing), and a month for programming free games using that art (which is going to begin in a couple of days). You can find more info at http://lpc.opengameart.org/. I would like to use Enigma in this competition, and in that regard, there are a couple of details I am uncertain about and would like your opinion on.

The first is whether Enigma can be used in the competition. Any entries in the competition is required to be free software, and as far as I can see, Enigma fits the bill, although I would like to check with you before I enter the contest.

The second is the best way to employ Enigma and games created with it. I haven't had much luck getting Enigma running under Ubuntu 12.04 (something about a parsing error, I think), but Debian Stable seems to work just fine. Downloading Enigma and running the game source file on it seems a bit bothersome, but should be fine for the judges, and other users can simply download a binary if they can't be bothered to download Enigma and set it up. Is there any other options, or any advice regarding that?

Thanks for your time.

[TheExDeus]

Yes, ENIGMA is totally free.

And when you compile a game you can get its binary. Don't know how it works on Linux, but on windows its in temp folder. Sadly, ENIGMA can't output 100% clean (without console and with icon) binaries and I don't know when or if it will change. Icon problem was because of winres (which is apparently fixed) and console window problem is because of wrong settings in makefile.

[Josh @ Dreamland]

ENIGMA's been broken on 12.04 since its release due to that bug. I'm finishing up work on a replacement parser, but am not sure how quickly I can finish. As for readiness for a competition, I have entered a couple Ludum Dare competitions with it, and didn't encounter major problem. If you don't think you will be hindered by the list of missing functions, then I don't see any other problems.

And yes, ENIGMA is free as in freedom. It is licensed under the GPL, V3.

As for distribution, a 32-bit binary compiled on Debian should be compatible with a 64-bit Ubuntu 12.04 computer. If the judges have some computer that uses X11, a 32-bit Debian ELF should technically work for all of them. You could compile a 64-bit one, too, if you like.

For the Ludum Dare, I released a Windows 32 bit EXE, a 32- and 64-bit Ubuntu ELF, and a 32-bit Mac ELF, and everything blew over fine. With a heightened focus on free software, though, there are likely to be many more Linux users, which means a much higher probability of someone finding an issue with that system.

Edit: I see the contest begins on the first of next month; it seems unlikely that I will have the Ubuntu/Arch compilation issue worked out by then, but we'll see.

[forthevin]

Thanks for the answers. The missing functions will not be a problem; I will work my way around them or implement basic versions if the need arises.

I found the binary in /tmp, and it ran without problem in both Debian Stable and Ubuntu 12.04. I also tried to compile from LateralGM (from the menu, Enigma->Compile if I recall correctly), but the only result was a null-pointer exception. What is the easiest way to compile for Windows and Mac from Linux? Also, how do I control whether ENIGMA compiles a 32-bit or 64-bit binary? I have run ENIGMA on a 64-bit computer, so I assume that the binary in /tmp is 64-bit.

[Josh @ Dreamland]

I believe RetroX wrote up a compiler descriptor for MinGW; you could try to apt-get install mingw and use it. I've never personally tested it. To switch to it, open ENIGMA settings and switch to the API tab. Select it under "Compiler."

There is a 32-bit gcc descriptor file which should work fine. If not, all you need to do is add -m32 to the parameters in the existing Compilers/Linux/gcc.ey.

[forthevin]

I tried compiling 32-bit from 64-bit Debian Stable, but it complained about incompatible libraries. Installing 32-bit versions of the libraries should solve the issue, but I am uncertain about how to do that properly in Debian Stable. I set up a 32-bit Debian Stable using VirtualBox instead, which took some time, but worked well.

I tried using the MinGW compiler descriptor on 32-bit and 64-bit Debian Stable. On 64-bit, there were packages missing in Stable that are available in Testing and Unstable, and on 32-bit, there were some issues with finding the right libraries (specifically, finding "ffi.h" and associated headers, since "ffi.h" was placed in /usr/include/i486 or somewhere similar). I think with further work the cross-compilation could be made to work in 32-bit Debian Stable.

In any case, thanks for the help. If anyone is interested, I have forked enigma-dev on github for the game, such that I can make quick fixes and improvements during the competition (some of the changes might be applicable to the main repository), and I may release some betas during the competition.

[Josh @ Dreamland]

I'm worried it might take more than just installing those libraries, if they have a different name than the native equivalents. I'm unsure, though; let me know how that works out.

As for the missing MinGW libraries, I'd completely forgotten about that. I'm glad they're actually offered on Debian; on Windows, I have to include them in an archive. Keep in mind you can add include/linker search directories in the descriptor file; if you find the right directories (and those directories are common between distributions), I'd be happy to pull your changes.

Odds are, if they are not common between distributions, you can use something like pkg-config to get the directories. In that case, you'd just put, eg, [snip]cxxflags: `pkg-config --cflags ffi`[/snip] in the descriptor to allow it to find them.

[forthevin]

Sorry for the very long response time, I ended up using virtual machines in order to compile for Windows and Linux 32-bit. That also allowed me to test that the compiled game worked as it should.

In regards to 32-bit libraries, it seems like compiling from 64-bit to 32-bit is considerably more complicated than from 32-bit to 64-bit. Since it is easy to setup 32-bit Linux in a virtual machine, this is not a big issue.

I tried cross-compiling for 64-bit MinGW using the jdi-branch on 64-bit Ubuntu 12.04. The two libraries that are missing are zlib and ffi. According to this link (https://bugs.launchpad.net/ubuntu/+source/mingw-w64/+bug/1022397), the zlib library seems like it is going to be included within the next couple of months, which solves that part. As for ffi, I remember working with ffi and trying to get that to work on Debian Stable, but I didn't get very far. Maybe someone who's better at setting up toolchains and stuff can figure that out.

All in all, using virtual machines is a little more bothersome initially than cross-compiling, but it seems like it is easier to get working, and it also enables testing on those platforms. The only issue with that is Mac OS X, which requires either doing illegal and fragile stuff with Hackingtosh, or getting Apple hardware and compiling it there. But that seems more like an issue of Apple sucking than anything else.

As a side-notice, getting the 64-bit Debian Stable binary working on 64-bit Fedora 17 was easy, and only required yum-installing 3 libraries and making a single symlink (the libdumb .so had a different name on Fedora than on Ubuntu).

Finally, thank you for your work on the jdi-branch, it makes things much easier.

[IsmAvatar]

Do also consider documenting some of your findings on our wiki so that it's easier for others to reproduce your work and get stuff working in the future. If you're unfamiliar with wikification, just put text down, and inform someone (like me or Polygone) and we'll clean it up and wikify it for you.

[forthevin]

I have added a new wiki page called "Cross-compilation", and added my most recent findings. 32-bit compilation may potentially be easier than I thought, but I still prefer using a VM.