Rubygame: The Blog

Quickie post because it’s late and I’m tired. More work making the system convenient today. Namely, I changed EventHook from using instance_eval() with a block to initialize (setting instance variables; which was excessive and added complications about the scoping of the “self” keyword) to using a plain old Hash.

Also made the HasEventHandler mixin module which allows you to attach a hook while automatically setting the hook’s “owner” to the receiver. Since 95% of hooks added to a sprite will have that sprite as the owner, not having to specify the owner explicitly is rather handy.

I think I also did some other miscellaneous stuff today, but I don’t remember what. *yawns*

Still laboring away in my ivory tower.

Earlier today, I spent some time cleaning up and making things easier to use. Pretty much, that meant going through the demo program I showed yesterday, and wherever I thought, “I shouldn’t have to do that manually, the sprite system should be doing it for me,” I made it so.

Tonight I’m working on CollisionHandler. I’ve got a design that satisfies me, so after publishing this post it’s back to Ye Olde Emacs for me.

[UPDATE: I have a mostly-working CollisionHandler implementation now, but it emits too many start and end events, even when it’s just resting in the corner. Will have to figure that out tomorrow.]

Nothing to report for yesterday, Day 25.

Today, I chipped away at various different parts of Rubygame, trying to make a running demo program to make sure all this code actually runs.

I actually did manage to get something thrown together, based on the infamous panda demo. It doesn’t look like much in a still screenshot, and it only looks marginally more impressive in motion, but here you go:

The panda is a physical sprite with a circle bounding shape. It falls from a short distance up and rolls along the black lines. The red box is just a background image at the moment, but it would be easy enough to make it a wall too.

Using the sprite system has, of course, given me a better idea of what areas need work to make it nice and easy to use.

Work continues tomorrow.

Lots of thoughts thunk and decisions decided today. Of course, I might change my mind about some of these later on, but for now I’m thinking…

1. I’m throwing away Transform; it was overly complicated for the present need, and was making things hard. Instead, Cameras will have a position, rotation, and zoom. It’s relatively simple to find how a sprite will appear given those bits of information. And frankly, it’s easier to use and Good Enough for 95%+ of the cases.

2. Most of the changes I’ve made to Chipmunk probably aren’t necessary. I’m going to try to distill it down to just the bug fixes and essential changes, then submit a patch to the official Chipmunk. Hopefully it will be accepted quickly if there are none of my more radical changes in it. Some of the things that will go: Matrix and the extra P attribute of Vects.

3. I’m not going to try to use Chipmunk’s BB class as a replacement for Rect. I’ll let BB remain purely for use in Chipmunk. At some point in the future, Rect might be ported to C for speed, but it’s not necessary to worry about that now; the C-Rects will have the same API as the Ruby-Rects, so it’s a simple drop-in replacement. But, I might take a look at the Ruby-Rect API and see if there’s any backwards-incompatible improvements I should make for 3.0.0.

4. The old-style sprites and groups will still be in 3.0.0. I might rename the Sprites module to OldSprites to avoid some confusion and slightly discourage their use. Existing games that don’t want to upgrade to the new-style sprites can make an alias or something to get around the module name change. Old-style sprites won’t be made compatible with Chipmunk or the new Scene system, although it’s certainly possible for app developers to make sprites that follow Chipmunk bodies – that could be done even now, with Rubygame 2.

5. Rubygame 3 is not going to be ready at the end of February. Sad, yes, but it has always been a possibility. I’m still going to see how close I can get before the month is out, but the actual release will (probably) be mid-March. I might do a “pre-release” in early March to get some feedback, with the understanding that the API could change between the pre-release and the actual release.

So that’s what I’m thinking.

Did some cleanup work around the event stuff and integer constants, and filled in a couple missing spots in the Sprite and Scene APIs. Still feeling a bit ill today. Also frustrated and disappointed at the moment about difficulties with Rubygame.

I was trying to implement Sprite#draw. It’s much more complex than the old Sprite#draw (which was basically just @image.blit(screen, @rect)). Perhaps too complex; more than it needs to be. The idea is that Sprite#draw is provided with a Rendering Context object, which gives information about how/to where the sprite should be drawn. Part of that information is a Transform, which is the basis of how the camera stuff will work.

Ideally, the camera has a transformation, and the sprite has a transformation, and the two can be combined to figure out how the sprite appears on the screen. That all works fine in OpenGL, where the transformation can be applied as a matrix to vertices, and the image is stretched to fit those vertices.

In OpenGL, I don’t have to care; I just push the numbers and Voila!, the sprite is drawn with the transformed location/rotation/etc. But in SDL, the image has to be rotozoomed to the correct rotation and size. Which means I have to figure out what the correct rotation and size actually is.

In the past, I thought that perhaps I could cheat and use SDL_gfx’s “textured polygon” draw function. But, it doesn’t do what I hoped, OpenGL-style texture stretching. Rather, it’s just making a shape filled with the given surface as a pattern. (I probably would have been disabused of this misconception earlier, if SDL_gfx had halfway-adequate docs. Bah, I’m grumpy.)

… delirious rambling about the difficulties/impossibility of decomposing a transformation matrix into its component translation, rotation, scale, and shear …

It would be simpler to figure out if I limited the camera zoom to being uniform, i.e. the same on X and Y. So no squashy or stretchy camera effects, sorry.

Hmm, hmm, hmm. Yes, that might do it. But tomorrow, tomorrow.

… wanders off, talking feverishly to self and bumping into walls …

Had a late start, and feeling a bit under the weather today, so not a whole lot of progress on Rubygame today. I did manage to take care of some thoughtless work like putting license/copyright headers on some of the new source files.

I was also thinking about keyboard events. It bugs me that keyboard events use integer constants (e.g. Rubygame::K_A) to identify the key that was pressed. This is one of those ugly style issues that Rubygame inherited from Pygame and SDL. My main objections to this style are:

1. Awkward to use. You either have to include Rubygame or litter your code with Rubygame:: everywhere.
2. Clutters up the Rubygame namespace with hundreds of constants.
3. Similarly clutters the C code, which has a huge list of “rb_define_const(…)” calls.
4. Too C-ish!

The obvious, Ruby-ish way is to use :symbols instead. Lovely, lovely :symbols. Instead of the cumbersome Rubygame::K_LEFT, you get the much easier to read :left.

And it actually requires much less code to implement the symbols than it does the integer constants. SDL has a SDL_GetKeyName function which returns a string like “left”, “space”, “a”, “left shift”. It’s trivial to turn those strings into a Ruby symbol, and only slightly more difficult to sanitize them a bit, e.g. changing spaces to underscores to get :left_shift instead of :"left shift".

There are a few keys that don’t work so great as symbols, because of the names SDL returns. The colon key, for example, is returned as the printable “:”, rather than “colon”. So, to make that a symbol, it has to become :":", which is not so pretty. Or backslash (:"\\") or double-quote (:"\""); also not very pretty. Prettier than Rubygame::K_QUOTEDBL, but not as pretty as :return or :tab or :3. (By the way, I actually had to look up K_QUOTEDBL in the docs just now — that gives you a clue about how memorable these constant names are.)

Since Rubygame 3.0.0 is my chance to break backwards compatibility in as many ways as I want, I’m considering trying to eliminate the keyboard integer constants and replace them with the symbols instead. Also perhaps for other things, like Surface/Screen flags (SWSURFACE, FULLSCREEN).

Checked in the first draft of Scene today.

I sometimes worry that I’m making the new Rubygame system too rigid and inflexible. That it will be harder to do weird, unusual stuff with it because of its well-defined structure. That I’m dictating how people use Rubygame: “Your game must have a Scene. The Scene must have Sprites. The Sprites must have a Body and Shapes and an image.”

When I worry that way, I try to remind myself that having some structure is a good thing. The point of Rubygame is to take care of the boring stuff, the stuff that every game has to have but is a chore to write, so that game developers can focus their efforts on the interesting, fun stuff that makes their game different from any other one.

In this way, Rubygame is expanding from library into the realm of frameworks. Rubygame has always been about providing a set of tools, but now it’s also providing a recommendation about the structure of your game. Even more than a recommendation, it’s providing the foundation and a few I-beams for the building to rest on.

You can find this same train of thought in two of my musings from last summer:

1. Looking at Rails (July 5)
2. Defaults and Constraints (August 2)

It’s only because I know that the advantages of the new structure outweight the imposed constraints, that I can bear to go through with it. Plus, as far as constraints go, the ones imposed by this system are actually pretty flimsy.

Today saw a bunch of code written for the Sprite and Scene classes. I consider the API designs mostly complete at this point, but still flexible enough to deal with issues that come up during the actual development process.

I should really write some tests before I do too much more development work. Meh.

Much work on API design today. Yesterday I formalized the sprite API somewhat, and started on the scene API:

• New Sprites
• Scene Class

Today mostly focused on formalizing scene and event management systems, which I had done work on months ago:

• Event Handler
• Event Hook
• Event Trigger
• Event Action

I also did some work on:

• Rendering Context
• Transform Class
• Matrix Class

(Although I should caution that not everything on the wiki is entirely up-to-date or fitting with my current mental model.)

Observant observers of this blog may have noticed that I’m working on scene, event, and camera stuff, even though I originally said that they wouldn’t be included in Rubygame 3.0.0. I’m still not totally sure how much, if any, of that stuff will be in 3.0.0, but it seems likely that most of it will (maybe not Camera, but we’ll see).

As I was working on the sprite API, I realized that the sprite needed to know what Chipmunk Space is belonged to in order for it to manage whether its Body is part of that Space (as the sprite is made static or nonstatic). That led, in its turn, to the realization that the concept I previously had for a Scene class was analogous to Chipmunk’s Space class, in the same way that Sprite is analagous to Body.

So Sprite gained a @scene attribute, and my mind started to wander and probe the old thoughts. I don’t think I’ve mentioned this before, but the development-3.0.0 branch of Rubygame has, for months, already had Sprite, Scene, Event Handler/Hook/Trigger/Action, Vector, Point, Matrix, Transform, Camera, and more classes in a usable fashion. I’ve been resurrecting and reworking them to fit with this new Chipmunk Powah-ed Sprite system.

It’s fun stuff, which is probably why I was able to convince myself to work on it so much today! I’m especially happy with EventHandler and related classes.

There are 2 days left in Week 3, which was slated to be code-writing week, but it’s turned into More-API-Designing week (which is fine by me given the lack of progress last week). I certainly expect to use quite a bit of Week 4 as overflow time; it might be necessary to add another week onto the schedule.

As always, we’ll see.

I’ve got two competing ideas bouncing around in my head, and they’ve been tumbling around and switching which one is on top. I need to make some sort of (permanent) decision here!

Idea #1:

• Sprites map onto Body.
• Sprites have an image, a Body, and some Shapes.
• The Shapes belong to the Body.
• The Shapes are invisible, and are only used for collision detection.
• Sprites can be made static by removing their Body from the simulation and changing its mass/moment to infinity.

Idea #2:

• Sprites map onto Shape.
• Each sprite has an image and one Shape.
• Sprites belong to a Sprite Body, which maps onto Body.
• Sprite Body is invisible, while Sprites are visible with their image.
• Sprites can be static by having no Sprite Body (in which case the shapes belong to a behind-the-scenes Body with infinite mass and moment).

In both cases:

• Shapes can be made phantom but still generate collision events by using a new Ruby-side Shape attribute and a carefully constructed collision function (which Rubygame will set up)
• Shapes can be made phantom without collision events by using collision groups and layers in Chipmunk.

Yesterday, I was convinced #2 was superior. Today it seems obvious that #1 is the better option. Tomorrow, I might favor #2 again, or perhaps come up with yet another option! It’s madness!

The reasons I currently think #1 is better are:

• It’s similar to Rubygame 2 sprites (image + shapes vs. image + rect), so is less of a jump for porting.
• It feels like it fits more naturally on top of Chipmunk, too.
• It feels natural and robust to be able to “freeze” (make static) sprites by manipulating the Body, than by doing secret reassigning of Shapes to new Bodies behind the scenes.
• Static sprites can be moved around without changing the Shape’s verts.

The reason I had in favor of #2 was that it would allow construction of objects from multiple parts. E.g. a Sprite Body has an arm sprite-shape, a head sprite-shape, and so on.

But that’s stupid. You couldn’t even move the parts independently without modifying the Shape’s verts, which is non-kosher. It just makes the most common use case — a sprite with one part, one image — more complicated to set up.

I think the multi-part idea could be better implemented with multiple Sprites/Bodies with pin joints, and that would also allow cool ragdoll type things. If you didn’t want the floppy ragdoll thing, but instead wanted the parts to keep their relative positions and rotations until you said otherwise, you could manage the rotation of the parts to keep them set right. (Sorry if this is incoherent to other people, I’m in stream of conciousness mode now.)

Keeping the rotation of parts in line would be more easy with a rotational slew method, analagous to the positional slew method. Whereas positional slew changes the body’s velocity such that it will be at the given position next frame, a rotational slew would change the body’s angular velocity such that it will be at the given rotation next frame.

I think I’ll go implement that now. (Yay, I get to get my hands dirty some more.)

P.S. What’s up with the word “slew”? I have no idea what it means in this context. Perhaps slembcke can give us some insight? ;)

I’ve checked in my transformation Matrix class. Those who are curious can take a peek at the C code, but more importantly the header file. Those who are very curious can compare with the Ruby implementation of Matrix3 I had been tinkering with in the past.

In addition to the speed advantages of simply using C over Ruby for the hard math, I also decided to discard the bottom row of the 3x3 matrix, which would always be [0, 0, 1] for valid transformations. In addition to saving a little bit of memory that would otherwise need to be allocated for 3 floats that never change, I was also able to simplify the multiplication math by assuming the bottom row will always be [0, 0, 1]. The zeroes handily eliminate some factors in the equations, and X * 1 can just be simpified to X.

I also took the opportunity to horribly pervert Chipmunk’s Vect struct by adding that extra Boolean field, called P (for point!), that marks it as being a point rather than a vector. (Actually, I used an int for that. I did feel a little bad about allocating a whole byte when I only need a bitfield, but then I was informed the system wouldn’t have allocated less than a byte for it, anyway.)

In actuality, that Boolean field is standing in for a third value that is 1.0 for points and 0.0 for vectors when using homogenous coordinates, as Scott Lembcke noted earlier tonight. If this were “real” matrix math, the third value would be a factor in the equations when applying the transformation matrix to a vector/point. But rather than waste some multiplications, I’m just using it as a Boolean and rerouting to a simplified equation if it’s 0.

All in all, it was fun to get my hands dirty with some geeky math stuff.

Miscellaneous tip of the day, mostly putting it here so I’ll remember it later!

In recent versions of Emacs, you can use lisp expressions to process the replacement result when running a search/replace regexp command (e.g. replace-regexp). The syntax for that is:

\,(expression ...)

The real handy part is that \0, \1, …, \9 work even inside the expression, allowing you to run an expression on the result of your search.

As a contrived example, if you wanted to change every vowel in the buffer to upper case, you could replace-regexp with the following search regexp and replacement regexp:

[aeiou]
\,(upcase \0)

In a real use case, I wanted to convert words like “m11”, “m12”, “m23”, etc. to “m00”, “m01”, “m12” — subtracting one from each digit in the name. Here are the search and replacement regexps I used:

m([1-9])([1-9])
m\,(- (string-to-int \1) 1)\,(- (string-to-int \2) 1)

Pretty handy!

Did some more Chipmunk R&D work today.

Small news is that I found out that it actually is possible to reassign a Shape to a different body. In fact, there was already a Shape#body= accessor that I somehow missed.

Bigger news is that I added a new method, Poly#set_verts, which allows the vertices of a Poly to be changed after creation. I tested it out in one of the demos, by making a shape that changes size at random. Sudden, dramatic changes in shape can cause undesired effects (like falling through the wall), but there’s no real problem with gradual (or even moderate) changes in shape.

Thanks to Poly#set_verts, I’ll be able to allow sprites to be resized and otherwise transformed, which is nice!

Speaking of transforming Polys, I’ve been working on a Matrix class for Chipmunk, to store transformation information. It’s complete except for a bug in the matrix multiplication math that’s causing some incorrect values. Once I fix that, I think it’s ready to go.

Unfortunately, Chipmunk does not distinguish between points and vectors. While their data structures are equivalent (both have an X and Y component), there are behavioral differences when it comes to transformations. In particular, vectors should not be affected by translation (movement) operations, while points should be.

I’m not sure how I’ll handle this. The obsessive compulsive streak in me thinks that there should be a new Point class, but that would require, I think, more changes to Chipmunk’s guts than I want to make. Perhaps I could add an integer field to the Vect struct, which would indicate whether it was representing a vector or a point. Not the cleanest solution in the world, but serviceable.

Might make another report later about my fuzzy, shifting thoughts on sprites and sprite bodies, but now it’s back to the code mines to figure out this matrix math.

Some progress formalizing the sprite system design today.

Thoughts and/or decisions (or tentative decisions) runing through my head:

1. BB (bounding box; similar to the current Rect) will not be a valid collision shape for this release. It’s not a full Shape in Chipmunk, and it would require a significant amount of effort to make it such, and with little gain. I hope to add it for some future release, but for now sprites will simply have to make do with the slightly less efficient Poly shapes (which are still faster than Rubygame’s Ruby-implemented Rects).

2. Sprites will not support resizing for this release, I think. Changing the sprite’s Shape on the fly could lead to complications with Chipmunk. But… well… hrmm. Okay, so this one isn’t really cleared out of the way yet. I might change my mind on it.

3. There will be two classes, Sprite and the still tentatively-named Sprite Body (which I formerly called Cluster). Sprites have an image and a Chipmunk Shape, but don’t bounce around the scene (they can still act as solid obstacles, though). Sprite Bodies take one or more Sprite in a parent-child relationship, and provide a Chipmunk Body that bounces around. This is basically what I described before with Clusters; I’m repeating it again to say that I’m pretty sure that this is the design I’ll be using for the release.

4. Sprites can be used without a Sprite Body. But because of a Chipmunk limitation (Every Shape must be child to a Body), we have to do a little bit of sneakiness behind the scenes, creating a (possibly temporary) Chipmunk Body to hold the Sprite’s Shape. But that Body won’t be added to the Chipmunk Space, so it won’t bounce around.

5. Sprites will default to generating their shape as a Poly rectangle based on the dimensions of its image. If a different Shape is provided, obviously the provided one will be used instead, and there is no need to generate one.

6. There will be (I think) a convenient way of creating a Sprite Body with a single Sprite as a child, setting up the proper relationships. So basically, it would be a “make me a bouncy sprite using this image” sort of thing.

7. I’m thinking right now that Sprite and Sprite Body probably will not be intended for subclassing. Instead, the kosher way to use them would be to make your own class with Sprite and/or Sprite Body instance attributes. This is still up in the air.

There are probably more thoughts in my head, but it’s rather late and I can’t think of them clearly, so I’ll leave off for now.

Not much to report, just vague ideas about sprites and Chipmunk floating around in my head during my spare moments the past few days, waiting for it all to click together.

Technically this is the end of week 2, and according to the schedule I should be starting on the actual development part now. But, since I can’t really develop something that has no design, I’ll be spending some of the development time trying to hammer out a tangible design.

Not sure if the schedule is still do-able; it really depends on when this design forms itself in my brain. It doesn’t help that I’ve been too busy to put in much time during the past week or so. We’ll see.

Was toying with another idea for close integration with Chipmunk. The gist of it is that Sprite would have a Chipmunk Shape where it currently has a Rect. It could be used by itself in that way, but there would also be a new class, tentatively called Cluster, which would be a collection of one or more Sprites. Cluster would be a wrapper around Chipmunk’s Body class, allowing the Cluster’s sprites to move and bounce according to the physics simulation.

Anyway, that’s one possible way of laying out how Shapes and Bodies relate to Sprites, but not necessarily the direction I’ll go in the end.

As well as that little bit of thinking work, I managed to while away several hours implementing a transformation matrix class that works with Chipmunk’s vector class. I’m not sure I’ll actually want or need it in the end, but it was good to take a break from the thinking, and actually write some code.

Yeah, it’s actually day 12 now, but I didn’t post anything for days 10 or 11, so I’m gonna do that now. What little there is to say, that is.

Actually, yesterday (Day 11) was a bad day for me in general, and I didn’t get anything done on Rubygame 3, so let’s just forget about that 24 hour period and just talk about Day 10 instead.

Day 10 was mostly just thinking about how Rubygame and Chipmunk should fit together. Like I said last time, I’m not happy with how closely I was designing the new sprite system around Chipmunk. But if I’m trying not to bend Rubygame out of shape to fit Chipmunk, and I don’t want to bend Chipmunk out of shape to fit Rubygame, the trick becomes: how do I fit them together at all?

Collision detection has especially been on my mind throughout this. Chipmunk has a perfectly good collision detection and response system. Rubygame has a different, barely adequate, collision detection system stolen inherited from Pygame. These two systems are not particularly compatible!

Chipmunk’s collision detection system is clearly superior; after all, Chipmunk is specifically built for collision detection and response. Maybe I should throw out Rubygame’s moldy old collision system, and build something new on top of Chipmunk. But now I’m back around to tight-integration with Chipmunk again!

*pounds head on desk*

Lots of thinking about sprites today, and how they fit in with Chipmunk. But then near the end of today, I realized I was trying to fit the sprite system closely around Chipmunk, which is not what I want to do. So I’ve split off my notes about Chipmunk sprites from my notes about the new sprites in general.

Chipmunk is really cool, but I definitely don’t want to make the whole sprite system based around the physics engine. Plenty of games have no use for rigid body dynamics. So the new sprite system will be easily integratable with Chipmunk, but not dependent on it.

Well, that’s not strictly true. I might take advantage of Chipmunk’s BB (bounding box) class to replace Rect. I haven’t decided yet. If I do, BB would become a valid collision shape for sprites, equivalent to Rects now, but it would also support collision with polys, circles, and lines. If I go that route, BB will need some more functions added to it to make it even close to as versatile as Rect.

So, plenty to think about. The thinking continues tomorrow!

I was too busy today to put in any time on Rubygame 3. It’s sad, I know, but not a big deal. The schedule has plenty of breathing room for days like today.

Ported the rest of the Chipmunk demos today, but didn’t have time for much more than that. Tomorrow will be the start of Week 2, which according to the revised schedule is sprite API design. I’ll probably be writing little throw-away tests using Chipmunk during this time, as well.

More Chipmunk work today. I ported over demos 2, 3, and 4 to Ruby & Rubygame.

Demo 3 – 300 pentagons bouncing through a field of triangles, pachinko-style – ran a bit slowly, so I reduced it to 200. Since the C w/ OpenGL version of the demo runs just fine, I’m guessing the bottleneck here is the SDL drawing functions (300+ draws per frame can be a bit much). I’m sure the ruby binding isn’t quite as fast as the native C, so that might be part of it as well. I might try using ruby-opengl for the demos, to more closely emulate the C demos, but that’s not really a priority.

I’m getting a better grasp on how Chipmunk is used, which is nice. I’m currently pondering the different aspects of collision detection and response:

1. Generating an event when objects collide.
2. Responding physically when objects collide.

For any given colliding object, you might want one, both, or neither of those. Or you might only want them to occur under certain circumstances (e.g. collide with the floor, but not with other players). It can get complicated, but Chipmunk has some nice features to make it simpler, especially layers, groups, and types.

Tomorrow I’ll port over the rest of the demos, and maybe make my own with those (in)famous pandas. Fun times!

Much to report today! I’ve revised the schedule for Rubygame 3; you can compare with the old schedule.

• Week 1: Chipmunk research and development. Learning Chipmunk and expanding its Ruby interface as needed.
• Week 2: Sprite design. No (permanent) code will be written, just throw-away code to get a feel for ideas.
• Week 3: Sprite development. Added functionality and integration with Chipmunk.
• Week 4: Clock development (mostly complete already), general cleanup / prep for release, and overflow time for the other development periods.

The biggest change was to move up the Chipmunk work to week 1 (in progress), and push back Sprite design to next week. The reasons for this were two-fold:

1. I didn’t really know enough about how Chipmunk works or is used to make intelligent design choices regarding the new Sprite classes.
2. Doing nothing but design is boring! Getting my hands dirty and working with code is more interesting for me right now.

Since I’m not getting paid for any of this, excitement and the pleasure of making something cool are my only incentives. Knowing that a design is solid and easy to use is nice, but it’s too long-term of a reward. I need to keep myself interested long enough to actually finish it!

I’ve put in 4 or so hours today. A little bit of research/learning, some expanding of the Chipmunk interface (including a nice patch by Tom Lea I found on the Chipmunk forums), as well as finishing up porting Chipmunk demo #1 (a box falling down stairs) to Ruby & Rubygame.

Everyone loves screenshots, so here it is:

Nothing fancy, and the floor and right wall are drawn off-screen, but it’s a nice visual representation of progress.

What wonders and magic will tomorrow hold? I guess we’ll find out.

Very little accomplished today. Late start, interruptions, and low focus. Hoping for better tomorrow.

Today was more reading of the Chipmunk docs (and source code) and making notes, especially about collision detection and handling:

• Chipmunk Stuff

I only got in 1 one-hour session today; I was hoping to get another one in the evening, but it didn’t happen. I hope to get my Chipmunk knowledge up to snuff by tomorrow, enough to start applying that knowledge to the sprite design.

Today went much better than yesterday. I had 2 one-hour sessions this afternoon, during which I scanned the Chipmunk docs and jotted some notes:

• New Sprites
• Chipmunk Stuff

The second session was interrupted when a (somewhat rude and arrogant) user entered the IRC channel, bemoaned that it was “disgusting” that no one understood how to use Rubygame, and then proceeded to complain about “it not working”, which turned out to be mostly user error (of course, this was promptly denied by the apparently infallible user).

On the plus side, he did offer enough fodder for me to file a bug report about window icons not working right on Windows XP if they’re set after the Screen is made (which is the only way Rubygame allows them to be set, currently). I might do something about that later, but it’s low priority. (I could probably foist it on one of the assistant developers; it’s mostly just a copy & paste job.)

Seriously reconsidering my decision to hang out in the IRC channel while working.

P.S. I also imported Chipmunk 4.0.2 into the rubygame trunk (trunk/ext/chipmunk). I resisted the temptation to touch the code, though.

So, today is/was supposed to be the first day of work on Rubygame 3.

Instead, I’ve spent the whole day trying to fix my wiki scratchpad, which I use to organize my thoughts while designing things. It has apparently has been down since my web host upgraded to Rails 2 (yes, I had forgotten to freeze my gems), but I haven’t used it in a while, so I never noticed.

I also managed to partially break this blog. Then fully break it while trying to fix it. I’ve finally got it back to being only partially broken. It’s readable, but no pretty stylesheet. [Update: Of course, as soon as you complain about something, it’ll fix itself just to make you look stupid.]

So, nothing accomplished on Rubygame today. The wiki is fixed now, though; hopefully it will still be working tomorrow, and I can actually get some designing done.