screenHeightalso returns the size of the primary screen only (thanks again, JayThirtySeven)
recordcannot handle now are lines, triangles, clipping and custom GL, and the resulting image cannot generally be drawn with
#insert(the new interface for things like Texplay).
#gl_tex_infocould be there, but return
nilas large Images already do. Or maybe BigImage could be a third class, but then calling
Image.newto create it would be weird.
#updatefor Macro. (
#to_blobwould require render-to-texture to be there,
#updateis easy.) That would probably take the same amount of time and keep the class count down.
modearguments 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#drawand 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)
scaleare 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(): AssertionindividualTransforms.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|
Powered by mwForum 2.29.1 © 1999-2013 Markus Wichitill