I wonder how I'd go about pixel-wise modify an Image object created from draw_quad, for example (as in a non-file object). I kind of miss that method I loved RGSS for (being set_pixel(x, y, color))...
Also, I can't seem to wrap my mind around how I'd store an image created by the non-file methods (aka images that are never loaded, but instance-created)... is there something I'm missing?
You could try to use DevIL to take a screenshot of the current Window state, turn it into a Gosu::Image and then manipulate it with TexPlay (though I don't think this will be fast enough for real-time interaction).
DevIL also does the job of saving manipulated Gosu::Images to a file.
TexPlay indeed does very cool... I have to test it out when I'm at home (I'm wondering wheather or not it sets pixels or overlays pixels - both would be cool, however, as I want to work with transparency, replacing is the only viable way, I guess...)
Also, as your example includes "img = ", I figure the image is stored in a similar way to Gosu's "img = Image.new()"... which would mean it'll work well with my caching methods. I don't need to save the image to a file, though, so I guess I won't need Devil at all...
I meant overlay as in not replace the pixel(s) specified, but drawing the given color over it, meaning you'd get a mix color if you use alpha values between 1 and 254. However, that sort of resolved itself when I read about the alpha blending, as that's obviously what I meant (I read about alpha blending after posting before). I wonder if there's a list of available modes though, as I guess you can do some very interesting stuff with this...
Oh, one more question... Gosu's draw_quad let's you define colors for each corner, enabling you to create gradient rectangles - is there a way to do this with TexPlay, or is it done by drawing individual lines?
This really looks like a promising thing to fiddle with... especially as I like to 'code' graphics instead of loading them. Might I ask what you're trying to do with it in the future?
tp doesn't currently support such gradient rectangles but it's a very cool idea and ill look into it. You should be able to code that up yourself though quite easily using the tp primitives
the direction im taking tp is to first finish implementing the basics (polygon filler, anti-aliased shapes, support for Gosu::Color, etc) and then start with more advanced stuff like fourier transform based image manipulation, better support for vector drawing, and decoupling of tp codebase from Gosu. I've been saying this stuff for months though, i know exactly how to do it/what to do but just lacking the energy to do it, i can feel another surge coming though so i'll get on to it all soon
here is a list of the drawing modes: clear, copy, noop, set, copy_inverted, invert, and_reverse, and, or, nand, nor, xor, equiv, and_inverted, or_inverted, additive, multiply, screen, overlay, darken, lighten, colordodge, colorburn, hardlight, softlight, difference, exclusion
Yeah, doing gradients myself won't be too hard... I was just figuring if there's an easy way, why wouldn't I use it? ^^ I'm really looking forward to mess with this script... the mode list looks like Photoshop with a good dose of conditional operators to me XD so I suppose it'll be cool to work with it. I also like the way you define images within {} brackets... so much easier than anything else I've seen... In that context: Consider yourself urged to work on this, as a few imagecoding-happy guys like me out there will definately enjoy it ^^
I kind of have a question regarding TexPlay.create_image... you have to define the window to draw in, and then aparently a viewport. That viewport doesn't get shifted along with the actual object though when youdraw it at non-[0, 0], essentially forcing you to set the x and y values to window resolution equivalents... this seems impractical to me. Other than that, I really like how you can work with it... I'm yet to figure out what amazing stuff one can do with it (as the examples are, while giving kind of a nice code-wise view on the features, relatively un-beautiful or potential-showing, imo... ^^" ), but I can already tell you that this is gonna be a definate include in any of my upcoming projects... thanks for this awesome gem ^^
Btw: Is it just me, or is the Marie picture never used within the example pictures? XD
Well, I created an image with (window, @width, @height), then displayed it with image.draw(@x, @y, @z), resulting in the image getting chopped off at the lower right corner because the viewport (as i thought; being essentially the same as a clip_to-area, speaking in Gosu terms, or a camera to stay in general). That's why I get the impression that the base frame the image is getting drawn at doesn't get moved along with the image...
Heh, I was preparing them and just got back on to post them XD
As it appears, I was wrong, it's not exactly the size of the window... however, it seems to be the exact aspects. Here's the screen:
Red line marks the area i can actually draw in (only gray background is drawn in that picture), while the blue line indicates the area the background's drawn as supposed to if I enter an image size of (window, 800, 600) instead of (window, @width, @height). The dark bar is drawn on such a 800x600 image and is therefore completely visible.
As for the code, you'll find all necessary lines here.
EDIT: Nevermind, I just noticed I was double-using the @x and @y values...
I suppose I have a bunch of experimentation ahead for getting that gui thing to work you see up there... if I come up with anything interesting, I'll make sure to save it somewhere to hand to you ^^