Gosu 0.7.21 is out in all common flavors, and has some interesting new features:
2010-05-13: Ruby: Updated CptnRuby to use translate() for scrolling 2010-05-13: All: In light of transformations, Font#drawRot is deprecated now 2010-05-13: C++: Fixed alpha support in Gosu::saveToPNG 2010-05-13: All: Added Image.getData().toBitmap() (C++)/Image#to_blob (Ruby) 2010-05-13: All: Added support for custom entities as registerEntity(name, bitmap) (C++)/register_entity(name, image) (Ruby) that can be placed in text as &name; 2010-05-13: All: Added HTML-like text markup for Font and Image#from_text (and C++ equivalents): <b>, <u>, <i> and <c=aarrggbb>/<c=rrggbb> 2010-05-10: All: Added four matrix transformations that affect all contained drawing: scale(), translate(), rotate() and a free-form transform() 2010-05-31: Linux: made gem Rubinius-compatible
Especially the matrix transformations and text formatting open up lots of creative possibilities, and can remove lots of ugly scrolling code. Please toy around and write beautiful games :)
It looks like it's something like HTML entities, to go with the HTML-like formatting. For instance: font.register_entity('smile', smile_image) might draw a smiley face (one assumes) wherever it sees ⌣ in your string.
erisdiscord, let me know if the behavior of nested transforms is what works for you. I just got the feeling that the order of their application should be the other way around for composite stuff. :/
In fact, it appears that the behavior is precisely the opposite of what I am expecting. Take this hypothetical but totally pointless window class:
class Window < Gosu::Window def initialize super 320, 240, false
@x, @y = 0.0, 0.0 @theta = 0.0
@vx, @vy = 0.0, 0.0 @omega = 0.0
end
def button_down id case id when Gosu::KbLeft then @vx -= 1 when Gosu::KbRight then @vx += 1 when Gosu::KbUp then @vy -= 1 when Gosu::KbDown then @vy += 1 when Gosu::KbPageUp then @omega -= 1 when Gosu::KbPageDown then @omega += 1 end end
def button_up id case id when Gosu::KbLeft then @vx += 1 when Gosu::KbRight then @vx -= 1 when Gosu::KbUp then @vy += 1 when Gosu::KbDown then @vy -= 1 when Gosu::KbPageUp then @omega += 1 when Gosu::KbPageDown then @omega -= 1 end end
def draw translate @x, @y do rotate @theta do draw_quad \ -8, -8, Gosu::Color::WHITE, +8, -8, Gosu::Color::WHITE, +8, +8, Gosu::Color::WHITE, -8, +8, Gosu::Color::WHITE, 0 end # rotate end # translate end end
To me, coming from OpenGL, pressing page up and page down should cause the square to rotate in place; what happens is that it rotates about the origin. I assume the transformations are being applied in reverse order? It's kind of weird.
I find the order of transformations pretty coherent: inner transforms are applied before outer transforms -> first, you rotate and then you translate the result. At least this is what I would expect from reading the posted code :)
I didn't think much about it with a all-in-one-place example like that. Now I face the situation that a game object cannot change the most outermost transform (for scrolling) but only wants to do an innermost rotation (around its origin), and I suspect the order is really not handy the way it is. :/
If I change this, I better be fast with 0.7.22 *cough* :)
Except with drawing order handled automagically, of course. You're right that the nested transformations aren't terribly useful the way they are, at least not for any use case I can contrive. Nested translations or rotations should still be fine, but mixing the two will only end in tears.
No worries for now; translation was the most important thing to me, because there's a lot more of that in the kind of game I want to make. If you change the order for 0.7.22 I'll consider it a bonus. Maybe I can make big bosses. :)
Reversed the order of matrices now. It's a bit weird to have to read them from the inside out, but that's of course the only way to nest it into functions. Duh, what a stupid oversight—fixing it made my composite objects so pretty. (I need to rotate them so had a 2x2 matrix system built in just for the rotation) :)