Rubygame 3: Day 38

More unit tests today, this time for the Event Action and Event Trigger types. Well, most of the event triggers, anyway; there are still a few fruit left to pick there.

While I'm thinking about it, here are more things I could/should/might do (or think about) before releasing 3.0.0, in addition to the big fat list I posted a few days ago:

  • Investigate why collision start and end events are being emitted almost as often as plain old collision events. The obvious answer is that the object is "jittering" slightly, and so actually not always colliding with the floor every frame. May need to add a "threshold" of how many frames it has to be out of contact before the collision is considered to have ended.
  • Either implement or remove the behavior of MouseClickTrigger and MouseHoverTrigger to be able to test that the event occurred within a certain area (or colliding with a certain shape). I think it's pretty important to have a trigger for "when the sprite is clicked on", but if it would delay release too much, that could be dropped for now and added later.
  • Consider renaming some events names. MouseDown -> MouseClick, MouseUp -> MouseRelease, MouseMotion -> MouseMove (or MouseHover). Likewise replacing Down/Up with Press/Release for keyboard and joystick events. I'm undecided here. If I decide not to go this way, will need to rename MouseClickTrigger and such, to match the event names.
  • Think about #dup and #clone semantics for Sound and Surface. Should #dup and #clone both be "shallow", with the only difference being that one (I forget which) copies the object's frozen status? If I go that way, there would later be #deep_copy or whatnot. Or I might have #dup be a deep copy and #clone shallow. Eh. Something to think about.
  • What to do about camera backgrounds when the camera has been rotated/zoomed?
  • Should sprites keep a copy of their rotated/scaled image so that it doesn't have to be regenerated every frame? It would (I am guessing) speed things up considerably, especially for sprites that aren't changing much. I might also add a way to control how often that temp surface gets updated.
  • How do moving cameras play into that?
  • What to do about sprites changing size? Are they allowed to do that now? If not, how should I "reserve" @size for future versions? If they are, how does Chipmunk deal with it?


Have something interesting to say about this post? Email your thoughtful comments to