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?

Thanks in advance.

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.

Using TexPlay you can generate images on the fly:

# create a new (empty) image
img = TexPlay.create_image(window, 500, 500)

# stick a blue rectangle on it
img.rect 100, 100, 300 , 300, color: :blue, fill: true

# stick a yellow pixel on it
img.pixel 250, 250, color: :yellow

You can also save the image using Devil:
img.save("blue_rect.jpg", quality: 70)

more info here: http://banisterfiend.wordpress.com/2008/08/23/texplay-an-image-manipulation-tool-for-ruby-and-gosu/
http://banisterfiend.wordpress.com/2009/10/14/the-devil-image-library-for-ruby/

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...

Thanks for the information!

Not sure exactly what you mean by 'overlay' but TexPlay supports something like 20 different drawing modes, one of them called 'overlay'

img.pixel 10, 10, color: :yellow, mode: :overlay

wonder if that's what you mean?

If you're working with transparency the alpha_blend option also may be useful to you:

img.pixel 10, 10, color: [1, 0, 0, 0.5], alpha_blend: true

The image is stored in exactly the same way as Gosu's Images (Image.new).

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 ^^

Again, thanks for your assistance.

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

hey, (0y 2eyb6ard 5s we5rd, s6 bear w5th 0e)

i dont know quite what you mean by 'viewport'. the last two parameters of create_image are actually the x and y dimensions of the new image.

so, TexPlay.create_image(window, 500, 500) creates an image of dimensions 500 x 500

sorry about my keyboard

to get an idea what you can do with tp, heres some projects i made that use it-

http://www.youtube.com/watch?v=FngoadE1nEc
http://www.youtube.com/watch?v=a93-L8yrd_g
http://www.youtube.com/watch?v=PpFNnMr763w
http://www.youtube.com/watch?v=iS7NvYaCdRY

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...

never heard of anything like this before. do you have code and screenshots?

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...

>_<

so are you saying there's no issue at all now? everything works as expected and i dont need to worry about anything? :D

Yeah, that's exactly what I'm saying XD Sorry for ringing the alarm bell, everything works fine now ^^

if you can come up with some inventive uses of tp that are simple and small enough to be used as examples, ill add them in

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 ^^