• All: Fixed interaction between recording and transforms
screenHeight also returns the size of the primary screen only (thanks again, JayThirtySeven)
• Linux/Ruby: Fixed linking error
The only things
record cannot handle now are lines, triangles, clipping and custom GL, and the resulting image cannot generally be drawn with
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.
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
#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
#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
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. :)
In 0.8 the arguments would be hashes, so the "missing parameter" argument is a terribly short-lived one :).
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)
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 :)
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.
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?).
I guess it depends on whether
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. :/
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.
Yeah, that would be awesome. :D Linux, right? I haven't exactly tested it a lot in my VM before releasing.
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.
Do you use
flush() somewhere? Up to the upcoming .41,
flush() can only be used outside of clipping and transformations :(
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|
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!)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill