Rubygame: The Blog

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!

You can update a gem-based install with gem update rubygame, or download Rubygame from Rubyforge.

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).

Updated gems are available from Rubyforge and Gemcutter (install with gem install rubygame), and source packages are available at Rubyforge.

Enjoy!

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).

The Mac Pack includes precompiled versions of:

• flac-1.2.1
• freetype-2.3.9
• libmikmod-3.1.11
• libogg-1.1.3
• libvorbis-1.1.0
• SDL_image-1.2.8
• SDL_mixer-1.2.9
• SDL_ttf-2.0.9
• SDL-1.2.14
• smpeg-r389
• ffi-0.5.1 (with gemspec tweaks)
• rsdl

However, there are a few limitations:

• 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 Mac Pack (Intel Only)
• Git repository
• Source code for the included software

Please give it a try and let me know how it works for you.

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).

• A new sample application (image_viewer.rb), and new docs (keyboard_symbols.rdoc and custom_sdl_load_paths.rdoc), plus updated install guides and other docs.

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:

Rubygame 2.6:

• Rubygame Gem and Source
• Rubygame Git

Ruby-SDL-FFI 0.1:

• Ruby-SDL-FFI Gem and Source
• Ruby-SDL-FFI Git

Nice-FFI 0.2:

• Nice-FFI Gem and Source
• Nice-FFI Git

Enjoy!

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!):

• Nice-FFI 0.2
• Ruby-SDL-FFI 0.1
• Rubygame 2.6

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.

In general, please post feedback and bug reports in the forums.

Update: Mac users will still need to use rsdl. This is a limitation of SDL on Mac, sorry.

Rubygame 2.5.3 is a maintenance release, fixing a few bugs that have been discovered since 2.5.2:

• Updated gemspec to list (install-time) dependency on Rake. [#24]
• Fixed: MouseMoved and JoyBallMoved were wrongly using unsigned ints for relative x and y positions. [#26]
• Fixed: Clock#framerate returned Infinity under some conditions.
• Fixed: Panda demo used the wrong order of steps for redrawing sprites.

Thanks to Adam Luter and Keith McAuley for their bug reports!

Full docs are online at docs.rubygame.org. Source tarball and gem are available for download at Rubyforge and download.rubygame.org, or you can install with gem install rubygame.

Enjoy!

• NEWS
• Rubygame 2.5.3 Docs
• Download @ Rubyforge
• Download @ Rubygame.org

The winners of RubyWeekend #3 are…

1. Ant Frenzy by Garepjotr (10 points)
2. A Tiny World by ippa (9 points)
3. Free Radicals by shawn42 (7 points)
4. Mite Makes Right by LoganBarnett (3 points)
5. Droplet by jacius (1 point)

(Scores are tallied from the voting thread. First-rank votes are worth 3 points, second-rank votes are 2 points, and third rank votes are worth 1 point.)

Congratulations to our winners: Garepjotr, ippa, and shawn42!

Didn’t get a chance to play the games? Download them from the forums!

The entries for RubyWeekend #3 are in, and it’s time to vote!

The entries are (in order submitted):

• Ant Frenzy by Garepjotr
• A Tiny World by ippa
• Mite Makes Right by LoganBarnett
• Droplet by jacius
• Free Radicals by shawn42

You can download the entries from the forums, play them, then head to the voting thread and cast your votes!

The theme for the RubyWeekend #3 game contest has been announced: A Tiny World!

If you’re participating, you have until June 28, 23:59 UTC (72 hours from now) to create a game in Ruby that matches the theme. Then, package it and upload it to the RubyWeekend #3 forums.

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!)

After being on hiatus for nearly a year, the RubyWeekend game creation contest returns this weekend, June 26-28!

The contest period runs for 72 hours this time, to allow everyone around the world plenty of time to create a small game:

• Start: June 26, 00:01 UTC
• Stop: June 28, 23:59 UTC

Watch the RubyWeekend #3 forum in the next few days for rules and more details.

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!

Remember to watch the RubyWeekend #3 forum in the next few days for rules and more details.

Rubygame 2.5.2 fixes a single, somewhat major bug:

• Fixed: HasEventHandler#handle (and other methods) dealt with NoMethodError exceptions in a stupid way.

Thanks to Kiba for reporting this bug.

Full docs are online at docs.rubygame.org. Source tarball and gem are available for download at Rubyforge and download.rubygame.org, or you can install with gem install rubygame.

Enjoy!

• NEWS
• Rubygame 2.5.2 Docs
• Download @ Rubyforge
• Download @ Rubygame.org

I’ve just released Rubygame 2.5.1. This version fixes two bugs, one potentially serious, and one minor.

• Fixed: Clock.delay would delay forever if the delay time and granularity were very small.
• Fixed: Clock.delay would always be “nice” to other Ruby threads during the final part of the delay, even if nice = false.

Thanks to shawn42 (Shawn Anderson) for discovering and telling me about the first bug.

Full docs are online at docs.rubygame.org. Source tarball and gem are available for download at Rubyforge and download.rubygame.org, or you can install with gem install rubygame.

Enjoy!

• NEWS
• Rubygame 2.5.1 Docs
• Download @ Rubyforge
• Download @ Rubygame.org

Ah, I finally get to kick back and relax: it’s vacation time! I’m avoiding real work as much as possible for the next 2 weeks to a month, and just slacking off and tending to fun things.

Now that Rubygame 2.5.0 is out, the next order of business is to clean up the web sites! Rubygame has moved a few times in its 4+ year history, and has left a bit of a slime trail as it went. (Note: many of the following links will become redirects within a few days of posting this.) Rubygame was first hosted on SEUL.org, then added an Infogami wiki to augment the static site. Then it moved to Sourceforge, and then added a wiki on SF. Then I added this blog to augment the SF site, and then mostly abandoned SF, hosting the source on Github, releases on RubyForge, and docs here at rubygame.org. Phew!

Now I’m getting around to making this an actual coherent site, instead of just a blog, forums, and other random things scattered around. I’m also cleaning up as many of the old sites as I can. I accidently permanently borked the Infogami site a couple days ago by deleting the site template (oops), so now it’s just… nothing. The SEUL and SF sites will become transparent redirects to the new site, which will start off as an updated version of the current SF site (since I’m still happy with my work on that).

After that’s taken care of, I’m going to try to convert this blog and the one over at blog.jacius.info to WordPress, since Mephisto is kinda clunky, plus I’m kinda tired of having to restart Mongrel when something goes wrong on the server. Finally, I’ll probably set up MediaWiki to have a modern, community-editable Rubygame wiki. (Yes, the blog, wiki, and forums for Rubygame will all be running on PHP, and no, I don’t see any irony there. Call me when there’s a Ruby-based blog, wiki, or forum app in the same league as the PHP ones.)

I should also come up with a Rubygame logo. I’ve got a new concept in mind (my motivation for finishing up this one is getting stale), so I’ll be experimenting with that on the side.

This next one is a bit of a stretch, since there are other things I’d like to do, too, but I’d also like to take another stab at the API Documentation app I tried to write last year. I detest having to work with (or against, as it were) RDoc for the Rubygame documentation. Every Rubygame release involves me fiddling for hours trying to get RDoc to format output the way I want, and the final result is mediocre, even when it’s working perfectly.

So, I was thinking of writing a web app to manage documentation. But I made the mistake of trying to do it in Rails (hah, hah, silly me), so the project crashed into a smoking heap of garbage and nils-where-I-didn’t-expect-them. (I guess that’s what happens when you try to ride Rails to someplace it doesn’t feel like going.)

I had been thinking about retrying it with Merb, to see if that was any better, until I heard it would be merging with Rails in the future. I might try Ramaze instead. Or heck, even Sinatra would be better than Rails. A bit more code to write, maybe, but fewer headaches and stomach ulcers. (If I wanted headaches and ulcers during my vacation, I’d go back to work early.)

But, I’m not sure I’ll take on that project yet. After all, I could use the time I’d spend on that, to work on Rubygame 3.0, Rebirth, a game, or some other fun thing!

We’ll see.

Oh, I forgot to mention the most important thing to do during my vacation: have lots and lots of afternoon naps in the sunshine with a cat on my lap.

Rubygame 2.5.0 is now ready to go!

The main focus of this release is improving the Clock class. Clock now has a more responsive and accurate algorithm for measuring framerate, better support for multithreaded games (set Clock#nice = true), a new ClockTicked event class (for use with EventHandler), and a way to calibrate the Clock to minimize wasted CPU power.

I’ve also written an in-depth tutorial about using Clock, entitled Managing Framerate. It covers several aspects of using Clock, including:

• framerate monitoring (finding out how fast your game is running)
• framerate limiting (setting the maximum framerate, to avoid wasting CPU power)
• calibrating Clock (to reduce CPU usage even more)
• framerate independence (so characters don’t move slower if the framerate drops)

In addition to the Clock improvements, I’ve also added the Screen.get_resolution method to retrieve the user’s desktop resolution (useful for automatically deciding how large to make the Screen). Thanks to Stephen Paul Weber (singpolyma) for the suggestion and for the initial patch!

There are also a few other smaller changes, so you may want to have a look at the NEWS for the full release notes.

Full docs are online at docs.rubygame.org. Source tarball and gem are available for download at Rubyforge and download.rubygame.org, or you can install with gem install rubygame.

Enjoy!

• NEWS
• Rubygame 2.5.0 Docs
• Download @ Rubyforge
• Download @ Rubygame.org

I ended up having to do some not-so-minor changes to Clock today (to satisfy my OCD rigorous Quality Assurance procedures), so I didn’t quite have enough time to prep the Rubygame 2.5 release tonight. The code is done (pending further review in the morning), it’s just a matter of packaging it up and posting to various sites and mailing lists. I’ll take care of that in the morning.