Game programming should be fun.

As promised in the previous post, I have set up a new Rubygame discussion group to replace the forums and old mailing lists. It’s hosted on Google Groups, so you can treat it as either a forum or a mailing list, whichever you prefer.

Thanks to Roger Ostrander for volunteering to manage the mailing list. If anyone else would like to help out with that, you can still contact me at jacius@rubygame.org.

The forums will be made read-only on 2011-07-23. No new posts will be allowed on or after that date. The forum database will be backed up and preserved offline.

Some time after 2011-07-23, the forums software (phpBB) will be taken offline. Posts that are of lasting value (as judged by me) to the Rubygame community will be preserved on the web site for posterity. Other posts will no longer be available online.

The following alternatives are available to replace some of the uses of the forums:

For showing off software you have created that uses Rubygame, you can edit the Showcase wiki page

After the forums close, there will no longer be any non-realtime discussion/support venue for Rubygame. But, I will create a new mailing list for that, if at least one person volunteers to moderate the list and deal with spam. If you are willing to do that, contact me at jacius@rubygame.org.

For the past few weeks, I have been working on renovating the Rubygame web site. Today, I have finally deployed the biggest chunk of that effort: migrating the home page and blog to Jekyll. I have also recently migrated the wiki to Github, and will soon be shutting down the forums.

This strange flurry of activity has a simple explanation: I’m putting Rubygame into a state of indefinite hibernation. Back in January, I made a post calling for a new project lead. I did receive several offers to “help out a bit”. Unfortunately, no one was interested in taking an active role to drive Rubygame forward, which is what it really needs.

But, I did receive quite a few emails from people expressing their appreciation for Rubygame and their hope that it would continue to be available, even if not actively developed. (Thank you to everyone who wrote; it’s certainly nice to hear.) So, all these changes to the website are steps to reduce the amount of regular maintenance needed to run the site, so that I can leave Rubygame inactive but available for the indefinite future.

I wrote in an earlier post about the potential for Rubygame to have multiple engines in the future. (I called them “backends”, but I think “engine” is a better term.) Rubygame could have one engine that uses OpenGL and OpenAL, one engine for Android devices, etc., to make it more portable. I don’t know if this is something I’ll actually pursue, but it’s an interesting concept, so I felt like writing about it in more detail.

Added SDL::SaveBMP and SDL::LoadBMP methods. These were convenience macros defined in the SDL headers. They have been reimplemented as Ruby methods by Bart Leusink.

The easiest way to install Ruby-SDL-FFI is with gem install ruby-sdl-ffi. (If you want to use Ruby-SDL-FFI or Rubygame on JRuby, you may need to install the ffi stub gem first.) Gem and source tarballs are also available, and you can get the source from Github too:

It has been months since I’ve even looked at the code. Rubygame 2.7 has been sitting in the repository for months, 90% complete, but no one with the drive to finish it. It is still difficult to install on Mac and Windows. There are few or no high-quality introductory guides or tutorials to get people started. The IRC channel is silent, questions in the forums are going unanswered, and users are leaving.

A few months ago, I was ready to pull the plug on Rubygame and move on to other things. I wrote up the announcement, and even started on a post-mortem to analyze why Rubygame failed, and try to learn from it. But abandoning Rubygame after 6 years is tough, and there has been a trickle of activity lately. Not much, but enough to make me hesitate, to give me a modicum of hope that Rubygame can recover.

Ruby-SDL-FFI 0.3 is now available. The biggest change is that Ruby-SDL-FFI apps (and Rubygame apps) can now run on Mac OS X with no special interpreter. In the past, Mac users had to run apps a special Ruby interpreter called RSDL. Now, this is no longer necessary — Mac users can now use the standard Ruby interpreter, even JRuby. (Eternal thanks to erisdiscord and jlnr for their advice and tips!)

This solution has only been tested on Mac OS X 10.5 (Leopard) on an Intel Mac. If you try it on a different setup, please leave a comment to let me know whether it works or not.

Release notes:

Ruby-SDL-FFI can now work on Mac OS X without the need for a special interpreter (i.e. rsdl). If this causes issues for you, you can disable it by setting the RUBYSDLFFI_NOCOCOA environment variable to "true".

Added the SDL::set_app_name() method. This sets the application name in a platform-appropriate way, or does nothing if the platform is not supported. On Mac OS X, it changes the text in the menu bar. Support for other platforms may be added in the future.

Ruby-SDL-FFI now reads the RUBYSDLFFI_PATH environment variable for additional library load paths. It should be a colon-separated (Linux/Mac) or semicolon-separated (Windows) list of directories to search for libraries

The SDL::Palette class is now Enumerable. You can iterate over it with #each, #collect, etc. You can also read a specific index using #at (but not #[], which is reserved for struct access)

SDL.GL_GetAttribute() now returns an integer, like it should. Before, it would return an FFI::Buffer.

SDL.GetKeyRepeat() is now easier to use. It returns an Array of two integers: [delay, interval]. Before, you had to pass two output buffers, then extract the integers afterwards.

Fixed a NoMethodError in SDL.WaitEvent().

Ruby-SDL-FFI now uses FFI::Buffer instead of FFI::MemoryPointer in many places. This should give a slight performance boost on JRuby, and potentially other platforms.

The easiest way to install Ruby-SDL-FFI is with gem install ruby-sdl-ffi. (If you want to use Ruby-SDL-FFI or Rubygame on JRuby, you should install the ffi stub gem first.) Gem and source tarballs are also available, and you can get the source from Github too:

Rubygame 2.6.3 is now available. This is a maintenance release which fixes several bugs, mostly related to how events are converted from SDL into Ruby. It also adds a way to prevent Rubygame from automatically initializing SDL when Rubygame is first required. Also, Nice-FFI 0.4 has been released, which should fix issues that Rubygame some users have had with the SDL libraries not being found, even when they were installed correctly.

Changes in 2.6.3:

Fixed: MouseMoved events always reported that all buttons were being pressed, even when they were not. [#38]

Fixed: MousePressed and MouseReleased events would raise an error for mouse buttons larger than 5. [#40]

Fixed: KeyPressed and KeyReleased events always reported that all modifier keys were being pressed, even when they were not. [#41]

Fixed: Rubygame would generate spurious WindowUnminimized, InputFocusGained, and MouseFocusGained events (or the opposite) whenever any one of those events actually occurred.

Fixed: Surface#convert would raise NameError if no Screen was open, due to a typo. [#42]

Rubygame will now skip auto-initialization if the RUBYGAME_NOINIT environment variable (ENV["RUBYGAME_NOINIT"]) is set to "1", "true", or "yes" (case insensitive). You must set the environment variable before doing require "rubygame". This is intended for special cases where auto-initialization is not wanted.