Two things to say in this post:
- SDL_mixer makes me want to stab something. Again, but for a different reason.
- 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.