Rubygame: The Blog

A quick post before I go to bed.

I’ve implemented the deprecation warnings for the old Mixer module and its classes, as well as put notices in the documentation with the suggested alternative. It should be a fairly simple process for developers to transition to the new classes.

I’ve decided to postpone the naming functionality until a later version. It’s still a half-baked idea, and I’m still trying to work out the best way to implement it. Plus, it’s not really necessary in this release, and I can add it later without any trouble, so that’s that. I also want to add it for Surface at the same time. Maybe this will be a “minor feature” for 2.4 (event hooks would be the major feature).

So, what that means is that there is nothing left on my checklist for 2.3! All that is left is to create the branch, update the NEWS file, look things over and make sure things look okay, and then release.

I’m not sure when the release will be. Probably next weekend.

It’s been a while since I last posted, and I’ve had a little bit of time to work on Rubygame 2.3, so this seems like a good time for a status update!

Here’s what is done so far:

• The Music class and all methods. It replaces the old Mixer::Music class, which will co-exist with Music until Rubygame 3.0.
• The Sound class and all methods. It replaces the old Mixer::Sample class, which will also stick around until 3.0. Sound is a lot simpler to use than Sample, because you don’t have to manage allocating or assigning audio channels, you can just focus on the stuff you want the Sound to do (play, stop, change volume, etc.). It also allows you to make “shallow” copies to pass around, without having to load multiple copies of the audio data into memory.
• Audio will open automatically with the default settings when you first use the Music or Sound class, if it isn’t open already.
• Rubygame.open_audio and close_audio. (Equivalent functionality to Mixer.open_audio and close_audio.)
• Rubygame.open_audio takes an optional hash of symbol => value pairs for specifying the sample rate, stereo or mono sound, and the size of the sound buffer. (I’ve decided not to include the ability to specify audio format until someone specifically asks for it, with a legitimate need.)
• Documentation and tests for all of the above.

What’s left to do:

• Add deprecation warnings to the old methods and classes. (As I said last time, the warnings will only appear if you ruby ruby with warnings enabled.)
• Add the names system, where each Music or Sound can have a name (by default, the filename it was loaded from), and you can retrieve it later with e.g. Music["whiff.wav"].
• I might do the names system for Surface too, and deprecate MediaBag.
• I probably won’t add Music.set_music_command (for using external music commands) in 2.3. It can be added later, if someone specifically asks for it.

Once that’s taken care of, I’ll make a branch of the 2.2 release and add the new stuff to that (easier than branching trunk and removing all the 3.0 stuff I’ve added over the past months). And then, release!

I’ve been really busy with work and other non-Rubygame things lately, so not much progress recently. I did get Music#jump finished, and there’s not really that much more work to be done on Sound/Music for 2.3.

And, yes, I’ve decided there will be a Rubygame 2.3, which has the new Sound and Music classes alongside the old ones.

The old, deprecated classes/methods will emit a warning when you use them (if you run ruby with warnings turned on, e.g. “ruby -w”), and future versions (e.g. 2.4) will have this same policy of offering a warning if you’re doing something deprecated. This offers a handy way for game developers to check whether their game will work when Rubygame 3 comes out, and gives them plenty of time to migrate. The warnings won’t appear when running without warnings enabled, so users won’t have their consoles flooded with warnings when playing your game.

If you’re interested in following the progress towards Rubygame 2.3, you can take a look at the checklist I’m using to organize my efforts.

Regarding why I decided to have a Rubygame 2.3 instead of just “chugging along” towards Rubygame 3, it’s simple.

All ventures, whether commercial or volunteer, need fuel to keep moving forward. Commercial ventures use money as the fuel, as the means of keeping the workers motivated. As long as they are getting money for their efforts, they can keep going forward; but if they run out of money, they will slow to a halt.

It’s the same way with volunteer ventures (like Rubygame), except the fuel is feedback and user appreciation instead of money. For a volunteer developer (like me), receiving constructive feedback or a thank-you email is like receiving a pay check; it keeps the developer motivated. But if the expense (the effort involved, which consumes motivation) is more than the income (the feedback/appreciation, which increases motivation), then the project slows to a halt.

So, keeping Rubygame afloat is very similar to keeping a business afloat. I have to balance the “expenses” against the “income”. If I receive extra “income” (motivation from feedback), I can use it to move forward. And just like in the business world, one good way to get new income is to release a new product.

If I could release Rubygame 3, I think the amount of feedback and appreciation would be quite large – Rubygame 3 is becoming very, very cool. But right now, I don’t have enough motivation to get all the way to Rubygame 3, so I have to invest my motivation wisely, and try to gain more of it.

Fortunately, I _do_ have enough motivation to reach Rubygame 2.3, and releasing that would probably give me enough fuel to reach Rubygame 2.4, and so on, until finally reaching Rubygame 3. So that’s my current plan.

I’ve figured out what the problem was with my Music#jump method: SDL_mixer’s Mixer_SetMusicPosition expects the time to be given in seconds (and docs say as much), but I was giving it in milliseconds. So, yes, it’s pretty much my own fault. On a semi-conscious level, I knew that it wanted seconds. But, the times that SDL_mixer wants for fading are in milliseconds, so I automatically added the erroneous conversion.

So now it’s working. Well, for Ogg Vorbis, it’s working great. My ears are literally aching from testing jumps with an MP3 file, because of the jagged screech it makes when seeking to a new time. But I don’t think there’s anything I can do in Rubygame to fix that. Ogg Vorbis is cooler anyway, so just use that!

P.S. Apparently, SDL_mixer will will just crash if you try to set the position to a point after the end of an MP3 file. But, for Vorbis, it just plays from the beginning. Except when it ‘locks up’ the file, in which it won’t play until you rewind from the beginning.

Naturally, SDL_mixer doesn’t have any methods for finding out such useless items as how long the song is or the current position in the song, which makes it a wee bit difficult for me to prevent users from crashing/breaking Rubygame with invalid times.

If I had a voodoo doll representing SDL_mixer, I’d be poking it in the eye with a needle. Over and over and over.

For some reason, my Music#jump method isn’t working. It’s supposed to jump to a specific point in the song, but right now it either: a) restarts the song from the beginning, or b) does nothing.

The only effective way to debug why something isn’t working with SDL_mixer is to flail around and poke random things until it works, and then figure out which thing made it start working.

Well, that’s not quite true – there is the possibility of digging through the SDL_mixer source itself, and seeing if there are any clues in there. The docs aren’t very reliable; even when they’re technically true, they often omit important information. Sometimes reading the header file is enough to give you the left-out information, but in this case, I’m actually sifting through the core source, trying to figure out what unspoken taboo I committed that is causing SDL_mixer to snub me.

Not fun times.

Two things to say in this post:

1. SDL_mixer makes me want to stab something. Again, but for a different reason.
2. There might be a Rubygame 2.3.

Okay, so: I do not like floating point exceptions. I try to avoid them. They are not my friends. Unfortunately, SDL_mixer seems to like them a lot. And it likes to share them with me.

I’ve been working on an improved Music class. It’s similar to the one that was introduced in Rubygame 2.1.0, but with a nicer API that’s consistent with the new Sound class. It has been going well, and 80% of the work got done just today.

But I hit a snag: when I run the specs that test the fade_out ability, SDL_mixer shares a cheery, yet mysterious, “Floating point exception” message — then drags the ruby process down with it, crashing instantly.

If I recall correctly, I ran into another “Floating point exception” when writing the Sound class, also in the context of fading. Last time, I think the problem was trying to fade in over zero milliseconds. Naturally, SDL_mixer doesn’t have error checking to detect that sort of thing (*rolleyes*), so it would just explode.

So, it occurred to me that a similar issue might be at play here. It took me a few hours to fix it, and I’m still not sure why it does it, but it seems that SDL_mixer dies if you fade in over a very short time period (less than 45ms, but greater than zero ms), and then immediately fade out.

The short fade-in time partially breaks SDL_mixer by itself – the song will play silently first time around, then play normally if it repeats. But if you fade out right away (as I was doing in my specs), SDL_mixer will just explode.

So, basically, SDL_mixer is not my friend. I find it quirky and flakey, and I wish there were another comparable SDL audio library that could replace it. But until such a library comes around, it looks like I’m stuck with SDL_mixer. (Although eventually I might like to use OpenAL. Or heck, maybe ditch SDL altogether…)

Okay, enough ranting.

The second thing I wanted to say was: I’m considering releasing a Rubygame 2.3. Basically, it would add the new Sound and Music classes – co-existing with the old ones, which would be deprecated and maybe emit warnings. It would also have a few bug fixes, probably, but none of the new Sprite or Chipmunk stuff that’s going to be in 3.0.

Why release an intermediate version? Basically, Rubygame 3.0 has gotten too big to release. Releasing a new creation is like passing a kidney stone: really painful if it’s big, but not too bad if you break it up into smaller pieces.

As a version, Rubygame 3 is defined by one characteristic: it breaks backwards compatibility with Rubygame 2 in some way. If a release doesn’t break backwards compatibility, the major version number doesn’t change, so it would still be in the Rubygame 2 series.

The number of changes so far that actually break backwards compatibility are actually pretty few. Like the new Sound and Music classes, the new Sprite class could co-exist with the old one, and the only problem would be confusion about having redundant classes in Rubygame. The old classes might emit a warning the first time you use them, and encourage developers to use the new ones, but old programs would still run.

If I did that, Rubygame 3 would basically just be flipping the compatibility switch off – classes that were deprecated before Rubygame 3, would be removed. Poof.

All the features that I’ve been planning would have been added in 2.3, 2.4, 2.5… It seems rather anticlimactic, but it also seems do-able.

So, that’s what I’m thinking about.

Based on Beoran’s suggestion and helpful tip, I’ve added better Unicode support to keyboard press events in Rubygame 3. The @string attribute for KeyDownEvent contains a UTF8 byte string of the glyph that was generated by the key press (if any).

This should make it much easier to do text entry, especially in non-English languages. Combined with the TTF#render_utf8 method, it should be feasible to create simple GUI text entry and display for many, many languages.

I’m just organizing a list of “to do’s” before releasing Rubygame 3, in preparation for resuming development work. Some of these are must-do’s (marked with an exclamation mark), others are might-do’s (question mark). They’re in no particular order. Also, this is not a definitive list. Other things might be added, some things might be removed as time goes on and I re-evaluate Rubygame’s needs.

• Fix how sprites are undrawing themselves from the screen!
• Investigate slowness in updating dirty rects on the screen.
• Make it more convenient to specify the camera mode.
• Make backgrounds transform with the camera.
• Prepare and submit Chipmunk patches.
• Update Rakefile to compile and install chipmunk with Rubygame. Might want to change the .so name to avoid overwriting where I shouldn’t.
• Mixer::Music needs a few tweaks. Also, the Mixer module is going away, so I need to move Music to be under Rubygame.
• Get rid of Mixer. Move the initialization function to be, perhaps, Rubygame.init_audio ?
• Rename Sprites module to OldSprites ?
• There a ROADMAP item about the old sprite group’s #collide_group, with the killa and killb stuff ?
• Change the docs template! They should properly have a Sourceforge.net button/link since I’m hosting them there (as per their policy).
• Clean up Rect API and code?
• Named event hooks?
• Named shapes?
• Lots of unit tests/specs!
• Lots of documenting!

In recent months, I’ve been getting several emails a week from users asking if it’s possible to use Rubygame with Rails. While I was originally skeptical about how Rubygame could be useful inside a web framework, I gave it some serious consideration, and decided there was some significant potential there. (Namely, the potential to piggyback on the success of Rails.)

Working on the side for the past month, and particularly this past week or so, I’ve managed to make significant progress on the next generation of Rubygame: Rubygame on Rails.

(click for a larger version)

Rubygame on Rails is a plugin to extend the functionality of Rails, allowing users to create Rubygame applications that run entirely in the web browser. RGoR reimplements nearly the full Rubygame API using 100% javascript and W3C-valid HTML with embedded SVG.

Unfortunately, web browsers have some limitations that I haven’t been able to work around yet.

Due to the varying rendering implementations of web standards, RGoR applications sometimes look dramatically different on different operating systems and browsers. Due to severe issues in this regard, I was forced to drop support for IE entirely. However, I don’t foresee this as a problem, since the demand for games on the Windows operating systems has traditionally been fairly low.

Other caveats:

• RGoR apps may be vulnerable to certain types of XSS (cross-site scripting) attacks.
• Performance in the browser is somewhat reduced from performance with SDL, by a factor of up to 12,000x in some cases.
• Currently, the only audio support in RGoR is playing MIDI versions of 1990’s pop songs.

However, I hope to fix these and other issues in future releases.

I still need to clean up a little bit of the code and package it up, but expect a release candidate for Rubygame on Rails within the next week!