Ruby Packaging on Windows

By phelps.db Date 2010-07-29 21:12

My problems have most likely been discussed by someone else on some hidden previous thread, but as there is no convenient way to search the gosu forums I will raise them myself. The google code site for gosu does provide a wikipage about packaging ruby games. However, to put it simply, it's just not helpful enough for a few small reasons. So, I am taking the advice explicitly stated on that page:

>If you have any trouble, feel free to ask on the Gosu boards. Ocra is still a project in development and everybody can benefit from sharing your experience.

After leaving the blessed land of Ubuntu and venturing cautiously into the dark realm of my Windows partition, I spent hours wrangling with the beast to try and package the new Ultimate Comet V2.0. Unsuccessful, I once again resolved that Windows sucks. But I also resolved to try again, and I need some help.

Problem 1: fmod.dll

I had trouble getting my game to find fmod.dll, and the instructions on the wikipage were vague and unhelpful to me (call me an idiot all you want, but that solves nothing).

I put fmod into a "lib\" subdirectory and compiled it along with main.rb using ocra main.rb lib\*. The wiki page says I must also change the path environment "like this":

ENV['PATH'] = File.join(GAMEROOT,"lib") + ";" + ENV['PATH']

Frankly, I don't know when or where this goes. I don't even really know what it means, and when I don't understand code, it feels like crap trying to use it (ever feel that way?). Furthermore, "GAMEROOT" appears to be something I have to define myself, I just don't know what path it's supposed to be, because it sure isn't something that ruby recognized.

This is assuming that changing the environment variable will solve all my problems.

When I tried compiling fmod.dll along with the .exe through ocra main.rb fmod.dll, Windows even broke from command line protocol and popped up a message saying "fmod.dll is either not designed for windows or it has an error. Blah blah blah..." and then the game would crash with the first attempt to use a sound returning the "could not load fmod.dll" error.

Problem 2: Quitting in an "unusual way"

Even running the source code on Windows was unsuccessful. The game would run, it would get to the menus, but when I try to start up an actual adventure it would crash and windows would pop up saying something like "ruby.exe - runtime error: the application asked (something) to quit in an unusual way."

Turns out, it appears the same exact problem occurred for Dahrkael in Deathly Dimensions (he made a post 2009-12-17 12:55).

Why do my games crash like this when someone attempts to start a level, and not when the game initially starts up? And why Windows, aside from its obvious shortcomings? The source code works just fine on Ubuntu 9.10 and Snow Leopard. Granted, I was only able to test it on one Windows computer so far.

By erisdiscord Date 2010-07-29 23:32 Edited 2010-07-29 23:41

Short answer: put that code at the very beginning of your file. GAMEROOT is something you will have to calculate yourself, and it is the folder where all your game's stuff is. The more in-depth answer follows.

GAMEROOT: To get the folder your game lives in, I believe File.dirname($PROGRAM_NAME) will do what you want—it does on Mac and Linux, but I don't have experience with Ruby on Windows.

ENV['PATH']: ENV is a Hash-like object that grants access to your program's environment variables—basically information about the environment the program is running in that it passes on to its children. These variables can be modified by any process, but changes only apply to that process and any child processes it spawns after the change. These values can only be strings.

PATH in particular is a colon-separated (Unix) or semicolon-separated (Windows) list of directories that tells the operating system where to search for an executable when it's called. Apparently, on Windows, it's also used to find dynamic libraries.

Putting it all together: ENV['PATH'] = File.join(GAMEROOT, 'lib') + ';' + ENV['PATH'] is essentially prepending your own search path to the list of search paths. File.join(GAMEROOT, 'lib') can be seen as a fancy way of saying "#{GAMEROOT}/lib", but it will use the platform's native directory separator instead of a hard-coded one. The semicolon is, of course, to separate your path from the rest.

If your lib folder is going to be in the same folder as your executable, the code you'll actually want to put at the top of your main file would look something like this:

game_root = File.dirname $PROGRAM_NAME
ENV['PATH'] = File.join(game_root, 'lib') + ';' + ENV['PATH']

If you intend to distribute the same code for other platforms, then you'll want to put this in a conditional that only runs if the game is running under Windows.

I'll delegate solving "quitting in an unusual way" to someone else, because I'm afraid I'd have no idea without poking at it myself. Otherwise, if you'd like any clarification, I'll be glad to provide.

By jlnr (dev) Date 2010-07-30 01:24

I remember with RubyScript2Exe I just put fmod.dll next to my EXE and everything worked magically. I only used ocra once, but I can't remember if that game had sound effects? If not then sorry, I wasn't even aware of that problem :)

As for the crash, that usually happens when the GC decides to free objects in a totally unstructured order, i.e. sounds before the window. I usually protected against all these cases. Is there a convenient way for you to just disable sounds globally and see if the crash permits? Then I know whenter it has to do with the Audio subsystem.

By phelps.db Date 2010-07-30 19:26

Got it working. The Windows XP/Vista/7 compatible executable is now available for download at the site. Happy Ultimate-Comet-ing.

The Environment Variable problem I was able to fix just as described. On top of that, I needed to get myself a new fmod.dll file through the gosu site because the one I had before must have been the wrong saved link, which solved the second part of problem 1.

As it turned out, problem 2 where Windows said "This application has requested the Runtime to terminate it in an unusual way" occurs because of game keyboard configuration settings that Windows apparently did not understand. The solution was simply for me to delete control_config.yaml from the bundle and let the program initialize and rewrite the control_config.yaml itself, thus ensuring that operating system dependent Gosu::Button constants would not conflict. The original control_config.yaml was created in Ubuntu, so obviously it would not carry over.

Thank you for the quick feedback. Now, on to the Mac Version.