As originally posted on the Wiki by jrmair, Aug 26, 2008:

> if anyone is interested in trying out or bugtesting TexPlay (a c extension for gosu for manipulating images) go here: http://banisterfiend.wordpress.com/
>
> it currently supports get_pixel and the ability to manipulate gosu images at runtime (the drawing of circles, lines boxes etc).
>
> Perfect for fast pixel-perfect collision detection in games, and fast image manipulation.

The library is explained in great detail here: http://banisterfiend.wordpress.com/2008/08/23/texplay-an-image-manipulation-tool-for-ruby-and-gosu/

i just updated TexPlay, it's now at version 0.1.0. I've changed the API and the syntax:

* To get the color of a pixel on your image:

    image.get_pixel(60,60)

* To modify your image:

    image.paint {
        circle 20, 20
        pixel 10, 10
    }

image is just any Gosu::Image.

For full information and download go here: http://banisterfiend.wordpress.com/2008/08/23/texplay-an-image-manipulation-tool-for-ruby-and-gosu/

TexPlay supports Windows, Linux and MacOsx systems.

Please get back to me with any feedback, suggestions or bug reports :)

wow cool! now i can write my lemmings clone! get_pixel was just what i was looking for!! thanks for the lib!

I really like TexPlay, but I have a problem... the performance of the refresh_cache call you add to the instantiation of images (i.e. Gosu::Image.new(args)) is very, very bad for me. It adds anywhere from 0.5 seconds to nearly 0.9 seconds per image instantiation, and since I load more than a hundred images in my game, all at once, I've had to comment out the call to refresh_cache.

Interestingly, commenting out that call hasn't had any negative effect, so I've not been able to figure out exactly what it was supposed to do in the first place...

hehe yes. 90% of the time you will be able to use TexPlay just fine without the automatic caching in the Gosu::Image::new method...however in certain rare situations (see below) TexPlay will not do what you want unless auto-caching is enabled.

The rare situation is when two or more Gosu images are stored internally on the same quad yet you invoke the TexPlay#paint method on one of those images BEFORE you've finished loading the other images.. In this situation all TexPlay manipulations will work fine for the images loaded prior to the first TexPlay#paint call (TexPlay lazily caches the quad on #paint if the quad is not already cached) but will produce weird results for all image manipulation on the images loaded AFTER (since they missed out on being cached.)

(sorry that was convoluted, it's 3am here :/)

You've convinced me that since this case is so rare I will remove auto-caching from the next version of TexPlay and come up with another way of resolving the weird edge-case .

thanks

I think you could get the OpenGL id of the texture in Image::new and see if you need to redo/merge(?) your painting? :)

ah yes :)

hey,

I fixed the issue with refresh_cache in the new (0.1.4) release of TexPlay. I also added some useful error messages for when you encounter the quirk with gl_tex_info (fixed in Gosu 0.7.13.4 ?)

also added a few more methods and constants:
* TexPlay#quad_cached?    -  returns true if the quad the texture is located on has already been cached
* TexPlay::TP_MAX_QUAD_SIZE    - returns the sidelength of the largest quad that can be allocated. (taken directly from max_texture_size() method in Gosu's Texture.cpp)

You can get the new TexPlay 0.1.4 binaries and source from here:
http://code.google.com/p/texplay/downloads/list?saved=1&ts=1244477834

Note: It is better to use TexPlay with versions of Gosu that do not have the quirk in gl_tex_info or you may be limited to a texture size of 254 x 254

banister

There were a couple of bugs in the last release, one major and the other a quite unusual edge-case (thanks valgrind!).

Download the bugfixed versions here:
http://code.google.com/p/texplay/downloads/list

(a macosx binary for 0.1.4.5 is on its way soon)

The attached screenshot demonstrates TexPlay in action:
* top-left - the original image
* top-right - basic drawing functions (line, pixel, circle, etc)
* 2nd-from-top-left - demonstrating splicing
* 2nd-from-top-right - demonstrating left-shift
* etc

TexPlay now uses gen_eval !

(and gen_eval comes bundled with TexPlay 0.1.6+, so you can have a play with it... )

gen_eval is a homebrew version of instance_eval that eliminates its most annoying aspect.

For example:
@x = 20
@y = 30
my_image.instance_eval do
    circle @x, @y, 20
end

=> error @x not initialized

Of course you meant the local @x yet instance_eval looks up @x in the receiver (my_image).

gen_eval, OTOH, works as you'd expect, it looks up @x in the caller-context yet still invokes methods in the receiver-context.

This means we can now do things like this in TexPlay:

@x = 20
@y = 30
image.paint {
    pixel @x, @y
    splice @img2, @x, @y, :mask => _alpha
}

How does it work ?

I haven't written it up fully yet, but here is an explanation of an earlier iteration: dup_eval.
And a very useful helper library (also now signficantly updated): object2module.

You can check out the BETA release of TexPlay 0.1.6 that utilizes gen_eval and let me know what you think. I personally haven't noticed any real reduction in speed; my benchmarks seem to indicate gen_eval runs more or less the same speed as instance_eval but YMMV.

here's the link for downloads:
http://code.google.com/p/texplay/downloads/list
 

Wow, sounds quite advanced :)

Did you see the issue I filed on GoogleCode? Are there plans for a gem'd release, maybe if we contribute a rakefile? :)

ah i see it now (im not really up with the play on googlecode) i'll add the #ifdef

thanks

hey there,

what is the compiler macro that indicates a mac system? is it __APPLE__ ?

Yep, it's __APPLE__.

A new version of TexPlay is scheduled for release within the next week or so.

It features:
* bezier curves
* floodfill and texturefill (non recursive for speed and efficiency)
* bresenham line and circle
* polylines and polygons
* turtle graphics
* enhanced composite (splice)
* an each iterator for the Gosu::Image class
* more control over syncing to opengl
* almost a complete rewrite of the C source with an emphasis on efficiency and simplicity (no more pseudo OOP in C)
* ...many other features designed to enhance extensibility

Im currently not so interested in affine transformations as most of these are covered very well by Gosu itself but if people are interested it may be fun to implement these (esp. since SSE instructions can be used to do it very efficiently)

Omg looking forward to this one :)

Wow, that sounds amazing! Let me know if you have an all-in-one example I can bundle with Gosu, it's not fair that I only have an RMagick one ;)

A beta of the new TexPlay can be downloaded here: Download

It's pretty much complete but has a few areas that need to be sorted out before I bump it up to 0.2.0.

In particular it has the following problems/omissions:
* thick lines are a hack and very slow (just drawing a filled circle at every pixel). This will be corrected very soon as im working on a polygon filling routine
* polylines and beziers and floodfill just sync the whole image whereas they should keep track of their exact rectangle of activity for more efficient syncing
* didn't get around to writing the Gosu::Image#each iterator
* turtle graphics is written in Ruby so is very slow, i'll rewrite in C soon
* removed bitmasking and leftshift/rightshift, haven't added them back in yet
* bezier curves are currently limited to 13 points (this will be easy to bump up)
* floodfill sometimes acts temperamentally when the image doesn't have a border, this should be easy to fix. (this is why all the example progs have borders)

if you find any other problems let me know.

NB: the example that shows texture filling under a bezier curve is called example_fill.rb

EDIT: the reason im releasing this now and not when the problems are corrected is because i have exams now and i wont be able to work on it again for a couple of weeks. :( and i just wanted to get something out there

EDIT: this release breaks backwards compatibility in a number of ways, so relying on the old manual may be confusing. I'll write up the new functionality soon as i get a chance

banister

Thanks pal, great you gave us something to play with meanwhile :)

TexPlay 0.2.0 is finally finished and a cross platform gem(s) is on the way.

You can download TexPlay here: http://code.google.com/p/texplay/downloads/list
(includes pre-compiled binaries for ruby 1.8.6 for linux and windows, macosx binary coming soon)

And read the updated manual detailing some of the new functionality. http://banisterfiend.wordpress.com/2008/08/23/texplay-an-image-manipulation-tool-for-ruby-and-gosu/

The manual is a work in progress, i'll keep adding to it and refactoring it. I think it could be a bit wordy at the moment (blame that on lawschool)

If you find any bugs or have problems installing it, let me know.

banister

semi-cross platform gem for TexPlay 0.2 available, should work fine for linux and macosx systems:

go:
gem install texplay

For Windows:
The Windows build is still not quite working, I'll follow the method that Gosu uses to deal with multiple .so versions. Should be available soon, but i'll need someone to compile a 1.9.1 compatible windows .so for me at some point :)

Windows users should use the googlecode link given above (in the previous post) in the meantime until a gem is available :)

banister

EDIT:

full cross-platform gem is now ready to go (supports windows, linux, macosx)

    sudo gem install texplay

the TexPlay manual is here: http://banisterfiend.wordpress.com/2008/08/23/texplay-an-image-manipulation-tool-for-ruby-and-gosu/

thanks!

Great to hear it's out! :D

Though, in the rakefile, it says it will copy texplay.so to /home/john/projects/selene.. .. .. I'm guessing you just forgot to delete that part?
(Haven't tried compiling yet)

hehe,  that's only if you run the 'selene' task :) a bit unprofessional for me to leave it in though, you're right :)

Hey banister, I get a "`get_pixel': no implicit conversion from nil to integer (TypeError)" when trying get_pixel(x,y) on a Gosu::Image ..

hey, can you send me the image and the the get_pixel command that causes the prob? (note that get_pixel will return nil if you request a pixel outside of the image bounds, i.e < 0 or > image.width - 1)

but tbh it sounds like you're sending nil as a parameter to get_pixel??

My bad, sorry.

I've got a nice little bug for you:
Texplay fails to splice images with (a) side(s) greater than 1023px

> -:31:in splice': Error: gl_tex_info returns nil for #<Gosu::Image:0x9574780> (1023 x 1023). Could be caused by very large image or Gosu bug. Try
> updating Gosu or use a smaller image. Note: TexPlay should be able to work with 1024 x 1024 images. (Exception)
>  from -:31:in initialize'
>  from -:38:in new'
>  from -:38:in <main>'

(ofcourse the "(1023 x 1023)" part changes with every image)

These are the results I got:



And this is the code I used:

require 'gosu'
require 'texplay'

class Window < Gosu::Window
  def initialize
    super(1026, 1026, false)
    self.caption = "Gosu Ruby Project"
    @img = Gosu::Image.new(self,"1023.png",false)
    @img2 = Gosu::Image.new(self,"40.png", false)
    @img.splice(@img2,0,0)
  end
  def draw
    @img.draw(0,0,0)
  end
end

Window.new.show

hmm, it's the error msg that is wrong. TexPlay can only work with images that are 1022x1022 (not 1024x1024, as in the error msg)

this is because gosu treats 'large images' differently and it's impossible for texplay to get opengl texture info on them (at least as far as i know)

sorry about this, but you're probably going to have to stick to images <= 1022x1022 :(

EDIT: by above, i mean that the largest possible dimension for x or y or both must be <= 1022

btw, if you're simply using 1023.png as a blank image for splicing you might want to consider using TexPlay::create_blank_image() instead

use it like this (as a drop in replacement for your current code):

@img = TexPlay::create_blank_image(self, 1022, 1022)

Not only is it more convenient than lugging around a large empty image, it's actually faster too :)

Yeah, I know.. I only used #{dimensions}.png for testing this former 'bug'.
I've simply gone around using such high dimensions (I originally wanted panels of 1024x1024), and opted for 512x512, using #create_blank_image()
On this I then #splice my tiles, etc.

new TexPlay 0.2.2 gem released

* fixed a bug in color_control
* added :start_angle parameter to ngon
* allow 0 and -1 arity procs to color_control
* cleaned up examples

TexPlay 0.2.666 released

* interoperability with Devil library
* adds a screenshot method to Gosu::Window, enabling you to take screenshots of gameplay and save to a file.
* adds a Gosu::Image#save method   (and so enabling you to save images you manipulate with TexPlay, needs Devil gem installed: http://banisterfiend.wordpress.com/2009/10/14/the-devil-image-library-for-ruby/)

Hey banister,
I have a problem with TexPlay.
If you use :alpha with the chroma_key parameter of Image#splice, you get for example this:
http://img61.imageshack.us/img61/2865/screenb.png

But I would like to have this:
http://img697.imageshack.us/img697/6500/074bird04.png

You know? :)

Hi,

chroma_key only works with exact color values with :alpha corresponding to [0,0,0,0]. I'm assuming that some of the 'alpha' values that you're splicing in are not full alpha ([0,0,0,0]) and so they are included in the splice (rather than skipped).

You can use a color_control proc in combination with splice to do a more flexible splice and choose exactly what colors you want included or skipped during the splice.

If you give me a copy of both images i can design a color_control proc that will get you the result you want.

:)

I think I know what you mean ^^
(anyway, the two pictures:
http://img641.imageshack.us/img641/6500/074bird04.png
http://img30.imageshack.us/img30/352/070goblin04.png)

But I guess a C++ solution would be faster wouldn't it? I have to call the splice method about 300 times each frame :)

300 times a frame?! Goodluck with that. :)

Well, i recommend ensuring the parts of the image you want excluded from the splice to be FULL ALPHA ([0,0,0,0]). Using splice with :chroma_key is MUCH faster than using a color control proc

But there will be pixels with alpha 1-254 and I cannot just leave them out ;)

wait

are you just wanting to do an alpha blend of the images? That is very different to using chroma_key.

To alpha blend an image use the :alpha_blend => true option

i haven't tested it, but something like this:

image1.splice image2, x, y, :alpha_blend => true

:alpha_blend isn't mentioned in the blog post ;(
Anyway, it isn't what I want, actually it's quite the opposite :)
This is what I get:
http://img53.imageshack.us/img53/4779/screenx.png

Hmm I'll have a play and get back to you soon :)

ok,

i found a bug in the :alpha_blend option, ive fixed it now and will push a new version soon :)

(it was because i neglected to blend the alpha channel, i just focussed on the rgb channels)

attached is the result of using the fixed :alpha_blend option on your images

(image saved using Devil)

Thanks =)
Hope the update will be out soon.

example_weird.rb result:

ok, try the new gem :) This is my first binary gem built entirely on windows (both the windows and linux/macosx versions) using RubyInstaller and the devkit. Let me know of any problems...

fixed in this version is alpha blending, i also tried to fix the segfault issue on some linux distros but that will have to wait until Gosu gets a MAX_TEXTURE_SIZE constant for ruby 1.8

Thanks, it works.
And with no_sync I could made it to 54 FPS with 490 splices a frame :)

out of interest what are you doing that you need to splice 490 times a frame?

TexPlay 0.2.800 released

provides:

* lerp (linear interpolation) option
* 28 new drawing modes (bitwise and photoshop-style blending modes; e.g additive, multiply, colorburn, softlight, exclusion, colordodge, etc)
* experimental :trace option (for very fast pixel perfect collision detection)

see updated documentation here: http://banisterfiend.wordpress.com/2008/08/23/texplay-an-image-manipulation-tool-for-ruby-and-gosu/

As far as I can tell the :trace works very well. I'm already using it in 2 core places in the game I'm working on.

I've traced in both vertical directions (up and down, not left/right though).. and used both :until_color and :while_color. It works perfectly so far, thanks for great release!

I am trying to create a Tilemap class.
The layers with trees, flowers and such stuff are drawn as seperate Images but the ground layer with (for example) grass or stone should be one single image.