Gosu 0.7.40 released

By erisdiscord Date 2011-11-20 09:16

Perhaps it's time to refactor slightly: new base class (Drawable) that is inherited by Image and Macro. That way there's no worrying whether an image is actually an image, right? C:

At least once all the draw methods work for recorded macros.

By jlnr (dev) Date 2011-11-20 10:02 Edited 2011-11-21 22:07

Spooner brought this up too, but I am not convinced yet. With a shared base class, the interfaces of Image and Macro would be the same, except Macro wouldn't have #to_blob and #insert (the new interface for things like Texplay). #gl_tex_info could be there, but return nil as large Images already do. Or maybe BigImage could be a third class, but then calling Image.new to create it would be weird.

Or I could actually implement #to_blob and #update for Macro. (#to_blob would require render-to-texture to be there, #update is easy.) That would probably take the same amount of time and keep the class count down.

The annoying thing is that all the differences lie in the arguments to the methods, so it would actually be more correct if Macro had an interface that is similar but technically unrelated to Image, with the color and mode arguments missing because they won't ever work accurately. Usually they're at the end of the argument list...except for #draw_as_quad. So that wouldn't be super clean either.

Weird, weird, weird. :)

By Spooner Date 2011-11-20 13:22

In 0.8 the arguments would be hashes, so the "missing parameter" argument is a terribly short-lived one :).

By jlnr (dev) Date 2011-11-20 16:16

The hashes are only coming for constructors in 0.8, not Image#draw and friends. I haven't had time to do benchmarks yet either, but it seems we could have a modular drawing thing at the same performance cost. (img.rotate(6).scale(2).draw(x, y, z), which I scheduled for 0.9 :P)

By Spooner Date 2011-11-20 16:22

Oh, sorry, I thought we were getting img.draw x, y, z, scale: 2, rotate: 45, mode: :add in 0.8. I think I remember you mentioning you liked the idea of method chains though :(

The issue I have with img.rotate(6).scale(2).draw(x, y, z) is the probably performance issue of lots of ruby method calls every time I draw something (maybe not that important; sometimes it is hard to judge real CPU impact). However, if I can do manipulated_image = img.rotate(6).scale(2).translate(x, y) and then manipulated_image.translate(1, 0) and then manipulated_image.draw() at a later date, then I feel I am really winning :)

By jlnr (dev) Date 2011-11-20 17:26

Since I cannot stop you Ruby guys from keeping a reference to the "manipulated" image, that's the only way it'd make sense. But it'd also mean a new allocated object for every step in the chain. :( I will benchmark all the possibilities once I get there.

By Spooner Date 2011-11-20 17:29

Not really. The standard way to manage chains like that is only to calculate when required by something like a draw (treat it something like a ruby iterator?).

By jlnr (dev) Date 2011-11-20 21:20

I guess it depends on whether rotate and scale are mutating methods or not. Since they won't mutate the underlying Image at least, I would've expected them to always be non-mutating. I think your middle code bit should be manipulated_image.translate!(1, 0). So for efficiency's sake, one could make it clear as img.rotate(6).scale!(2).draw(...), meh. :/

By RavensKrag Date 2011-11-25 15:37

Just updated to 0.7.40.

Not totally sure what's wrong, but it's broken for me. Sorry to be helpful and unhelpful at the same time, but I got a deadline to meet. Well, more of a personal milestone, but still. I'll try to post more detailed information later.

By jlnr (dev) Date 2011-11-25 19:03

Yeah, that would be awesome. :D Linux, right? I haven't exactly tested it a lot in my VM before releasing.

By RavensKrag Date 2011-12-13 04:37

Ok, finally got around to it. Here's the error.

ruby: ../GosuImpl/Graphics/DrawOpQueue.hpp:128: void Gosu::DrawOpQueue::popTransform(): Assertion individualTransforms.size() > 1' failed.
Aborted `

By jlnr (dev) Date 2011-12-13 10:02

Do you use flush() somewhere? Up to the upcoming .41, flush() can only be used outside of clipping and transformations :(

By RavensKrag Date 2011-12-13 10:50

So it's supposed to work past .41 then? Strange, as it works in .38, just not in .40.

Ah well, I'll shuffle the code around a bit for the time being, although it results in a bit of a performance hit. My code is by no means optimized though, so I'm sure I could stand to eek out some efficiency elsewhere. I look forward to .41, it sounds like that's gonna be good one.

For those interested, here's what I'm doing. It's intended to draw gamestates in different "layers," such that each state has it's own z-index ordering.

@window.translate *@camera.offset do
  @stack[ACTIVE].each do |gamestate|
    if gamestate.visible?
      gamestate.draw @camera.zoom
      @window.flush
    end
  end
end

By jlnr (dev) Date 2011-12-13 18:28

I am also flushing between states - it's nice to have reusable states that don't Z-collide with the game. But I was lucky enough to only scroll in one of the states. :)

Yes, it is already fixed, I just need to package a release again. (Soon, Ludum Dare is impending after all!)