Rubygame 2.6.2 has been released. This bugfix version restores two methods that were accidently lost during the FFI port:
Fixed: Rubygame::Screen.set_mode and Rubygame::Screen.instance were accidently lost during the FFI port. (Note: those methods are deprecated, but kept for backwards compatibility. New code should use Rubygame::Screen.new or Rubygame::Screen.open instead.)
Thanks to mattis in IRC for bringing this problem to my attention!
Bug fix releases of Rubygame and Ruby-SDL-FFI are now available.
Rubygame 2.6.1 changes:
Fixed: Rubygame::Mixer.open_audio was using a different default audio format than it did in 2.5.3, which caused an error on Mac. (Note: Rubygame::Mixer.open_audio is deprecated, but kept for backwards compatibility. Use Rubygame.open_audio instead.)
Fixed: Rubygame no longer tries to load audio features if SDL_mixer is not available. Trying to load them would cause an error, and didn't match the old behavior.
Ruby-SDL-FFI 0.2 changes:
The values of SDL::AUDIO_U16SYS and SDL::AUDIO_S16SYS are now correct on both big-endian and little-endian systems.
SDL::Gfx::arcRGBA is now considered optional (as it should have been in version 0.1). Loading will continue even if it is not available, such as when using older versions of SDL_gfx.
The minimum supported version of SDL_gfx is now 2.0.13. It was 2.0.17 before.
SDL::Gfx::rotozoomSurfaceXY and SDL::Gfx::rotozoomSurfaceSizeXY are no longer considered optional, because they are available in all supported versions of SDL_gfx (2.0.13 and higher).
One of the things I noticed as I was updating the Rubygame installation instructions was how much of a hassle it was for Mac users to acquire all the dependencies. There are precompiled DLLs available for Windows, but Mac users still had to install a whole development environment just to compile libraries to use Rubygame. Obviously, that's a huge barrier to using Rubygame!
Well, no more!
Over the past couple days, I have compiled and packaged up everything (hopefully) that Mac users will need to use Rubygame, complete with a handy (albeit rather basic) install script! It will install the libraries, rsdl, precompiled ffi gem, and rubygame for you. The README also tells you how to install them yourself, in case you don't trust my simple script (which uses sudo, so it will ask for your password).
So far there are only Intel versions. Sorry, these won't work on the older PowerPC Macs. I hope to create a Universal (Intel + PowerPC) Mac Pack in the near future. If there's anyone out there who would like to help with that (especially if you have a PowerPC Mac and are comfortable compiling software), please leave a comment or contact me.
The rsdl version has been compiled for the default version of Ruby that's included with Mac OS X (1.8.6). If you want to use it with a different version of Ruby, you will have to compile rsdl yourself. If anyone has suggestions for making this more flexible, I'd love to hear from you. In the long run, I'm looking into ways to eliminate the need for rsdl entirely.
This was prepared on Leopard. I have no idea if it will work on other version of Mac OS X.
Anyway, here's the first version of the Rubygame Mac Pack!
Rubygame 2.6 has new been released! Hurrah! There are also final release versions of Nice-FFI 0.2 and Ruby-SDL-FFI 0.1. They've all been uploaded to Rubyforge and are now available for gem install rubygame. (Note: JRuby users will need to install the ffi stub gem to resolve the gem dependencies.)
Starting in Rubygame 2.6, Rubygame is now pure Ruby, with no compiled C code. Instead, it uses Ruby-FFI (or compatible FFI implementations, e.g. on JRuby) to directly access SDL and related libraries. That means:
It is much easier to install. You can install it directly from RubyGems (gem install rubygame) on any operating system, and you don't need a C compiler or SDL headers. Installation instructions for many platforms are available on the wiki.
It is now possible to use Rubygame on JRuby, and possibly on Rubinius.
Rubygame will be slightly slower than before. But, the hard work is still being done by SDL, so the speed decrease is only minor. The increased portability and ease of future development greatly outweighs the small speed loss.
Despite the major architectural change, Rubygame 2.6 API is meant to be backwards compatible with Rubygame 2.5 and earlier. If you find an API incompatibility, you should report it as a bug.
However, there are a few minor incompatibilities that are already known,
and most likely cannot or will not be fixed:
Surface#flip now needs SDL_gfx to run. Before, it needed only plain SDL, but the code for it was too slow when reimplemented in Ruby.
Rubygame::VERSIONS[:sdl_gfx] now reports [0,0,0] when SDL_gfx is available, instead of its real version number. SDL_gfx does not currently provide any way to detect its version number at run time. We suggest checking capabilities instead of version number, anyway. Use Surface#respond_to? to make sure that the methods you want are available, or be prepared to rescue from NameError.
The biggest news for Rubygame 2.6 is of course the port to FFI, but there are also some smaller improvements:
Surface#set_at now behaves correctly when given a color with an alpha value, setting the pixel to the given color (and opacity, if the Surface has an alpha channel). Unfortunately, there is a long-standing bug that Surface.new doesn't create Surfaces with a correct alpha channel. You should use my_surface = my_surface.to_display_alpha if you need an alpha channel. (The bug has been around so long that fixing it could break backwards compatibility, so it won't be fixed until Rubygame 3.0.)
Rubygame automatically initializes itself when loaded, and cleans itself up when your app exits. So, you don't need to call Rubygame.init or Rubygame.quit anymore! Besides being more convenient, this also prevents a crash for old or sloppy games that don't call those methods. It is still safe to call them manually, of course.
Music.load now automatically opens audio when used, so that MP3 files will load correctly. This fixes Bug #29 (thanks for the report, MadVillain).
As I mentioned, the easiest way to install Rubygame is with gem install rubygame. (If you want to use Rubygame on JRuby, you must install the ffi stub gem first.) Gem and source tarballs are also available, and you can get the source from Github too:
A test release is now available for Rubygame 2.6! I don't want to write a lot about it now; I'll save that for the final release. But, I'll give you a brief introduction.
I don't normally do test releases, but this is a special circumstance. Architecturally, Rubygame 2.6 is a radical departure from previous versions of Rubygame: there is now absolutely no C code in Rubygame. There is nothing to compile. This should make Rubygame a lot easier to install on all platforms, as well as easier to develop and improve.
This is possible thanks to the wonderful Ruby-FFI library, which allows Ruby code to directly interface with C libraries, without the need for a compiled wrapper. I'll have plenty more words to praise it later, but suffice it to say for now that it's really quite marvelous. JRuby and Rubinius also have (mostly-)compatible FFI libraries, which means that once a few wrinkles are ironed out, you will be able to run Rubygame with those implementations as well!
Along with the Rubygame 2.6 test release, I have prepared test releases of Ruby-SDL-FFI and Nice-FFI, two supporting libraries that I've been developing. The purpose of the releases is to make sure that all these libraries also work correctly for other people, on other platforms.
Downloadable gems are available. You must install them in this order (Update: Now that Rubygame 2.6 has been released, you don't need to install these manually anymore — just do gem install rubygame!):
If you are on MatzRuby (not JRuby or Rubinius), you will also need the "ffi" gem. It should be installed automatically as a dependency of Nice-FFI, but if not you can install it with gem install ffi.
You will still need to have SDL and related libraries installed on your system. Rubygame (actually, Nice-FFI, but Rubygame uses that) is programmed to look for SDL in the most common places on Linux, Mac, and Windows, so hopefully you won't have to do anything special.
Rubygame 2.6 is intended to be backwards compatible with previous versions of Rubygame. Please try it with as many games as you can. If something works in Rubygame 2.5 but not in 2.6, that indicates a bug in Rubygame 2.6 and you should tell me about it!
It should work on MatzRuby 1.8 and 1.9. It may not work on JRuby and/or Rubinius yet. I'll be trying to get those to work soon, but there are a few subtle differences in FFI implementation that I need to figure out first. Please let me know whether it works for you.
We recommend taking some time to think about the theme before you start coding. Come up with a good idea for a small game that you can create in just one weekend. It's good to keep a brief log along the way, since it's interesting for others to read about, and it can also help you focus your ideas! Twitter is great for quick log entries; we recommend tagging your tweets with #RubyWeekend. Or if you have a blog, post the URL in the forums.
We're also hanging out in IRC during the contest: #rubygame on freenode. Come join us if you want to chat with other participants! (But don't let IRC eat all your time!)
RubyWeekend is a friendly weekend competition in the spirit of Ludum Dare and PyWeek. The idea is to create a small original game in a single weekend, programmed in Ruby. The theme of the contest is announced at the start of the contest period, and participants create a game that fits the theme, within the time limit (2 or 3 days). The short time period encourages participants to think small and use their time wisely.
All game code should be written in Ruby, but you can use any Ruby libraries or extensions you wish — Rubygame, Gosu, Shoes, Gamebox, Gemini, Ruby-OpenGL, etc. You could even make a web-based game with any of the many web libraries and frameworks available for Ruby: Rails, Merb, Ramaze, Sinatra, etc. Ruby has a wide (and growing!) variety of options for game programming, so let's show them off!