screenWidth
/screenHeight
also returns the size of the primary screen only (thanks again, JayThirtySeven)record
cannot handle now are lines, triangles, clipping and custom GL, and the resulting image cannot generally be drawn with draw_rot
or draw_as_quad
/getData().draw(...)
.
#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.#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.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.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)
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. :/
ruby: ../GosuImpl/Graphics/DrawOpQueue.hpp:128: void Gosu::DrawOpQueue::popTransform(): Assertion
individualTransforms.size() > 1' failed.flush()
somewhere? Up to the upcoming .41, flush()
can only be used outside of clipping and transformations :(
@window.translate *@camera.offset do
@stack[ACTIVE].each do |gamestate|
if gamestate.visible?
gamestate.draw @camera.zoom
@window.flush
end
end
end
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill