Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Gosu Exchange / Trying to implement Gosu::Window#to_blob
- - By banister Date 2010-09-25 21:32 Edited 2010-09-25 21:45
I'm using the code below - but it does not work. It also causes the screen to flicker:

static VALUE
gosu_window_to_blob(VALUE self, VALUE x, VALUE y, VALUE width, VALUE height)
{
    int rb_x = FIX2INT(x);
    int rb_y = FIX2INT(y);
    int rb_width = FIX2INT(width);
    int rb_height = FIX2INT(height);

    VALUE blob = rb_str_new(NULL, 4 * rb_width * rb_height);

    glReadPixels(rb_x, rb_y, rb_width, rb_height, GL_RGBA, GL_UNSIGNED_BYTE,      
                          RSTRING_PTR(blob));

    return blob;
}

Note that the following Ruby code *does* work; what must I do so the C code works like the following Ruby:

data = nil
self.gl do
        data = glReadPixels(0, 0, self.width, self.height, GL_RGBA, GL_UNSIGNED_BYTE)
end
Parent - - By Spooner Date 2010-09-25 23:39
I suggested looking at the code from beginGL() and endGL() in Gosu that presumably usually wrap the call:

http://www.google.com/codesearch/p?hl=en#TkUzYEJjlVA/trunk/GosuImpl/Graphics/Graphics.cpp&q=gl%20package:http://gosu%5C.googlecode%5C.com&d=1
Parent - - By banister Date 2010-09-26 02:31
i kinda got it working (with a few caveats). jlnr said to call Window#flush and glFinish();prior to running the C code above....it kinda works.... (a tiny bug im still figuring out, but pretty much 90% usable at present)
Parent - By Spooner Date 2010-09-26 08:17
Excellent! I just hope I can use it effectively as a cheap "render to texture" system :$ I'm sure it would be useful for a lot of people for that and making regular screenshots, though.

Thanks very much for your efforts!
Parent - - By AmIMeYet Date 2010-09-26 09:56 Edited 2010-09-26 09:58
Are you planning to add this to texplay perhaps? Because I'd prefer this a whole lot over using DevIL to capture the window!

And this is great for blur-effects or even fake bloom :D
Parent - - By erisdiscord Date 2010-09-26 15:32
Hmm, I'd think it would be pretty slow to do that every frame. Your best bet for bloom and blur would probably be to use a shader.
Parent - - By Spooner Date 2010-09-26 21:21 Edited 2010-09-26 22:34
I am quite sure this isn't actually useful for bloom/blur and we (banister & I) didn't suggest it was (you can fake bloom nicely with :additive drawing mode as I did in my LD entry, though I suppose that was more like simple lighting than true bloom :). How exactly would it be done?
Parent - By erisdiscord Date 2010-09-26 21:37
See the comment I was responding to for a mention of bloom and blur; I'm not sure how it would be done with this, just that it was mentioned. :P
Parent - - By AmIMeYet Date 2010-09-27 20:48
Well for the blur I actually meant a static blur. So for example when you pull up the menu, the game would freeze, and then a blurred version would fade in, and with it, the menu. I love effects like that :)

And yeah, that bloom might be a bit silly, I'll admit that. For one, the UI would burn right in the screen.. ..
Parent - By erisdiscord Date 2010-09-27 21:22
Ohh, that makes more sense. Actually, yeah, that would be a really cool effect.
Parent - - By Spooner Date 2010-09-28 00:20
Yes, I suppose you could draw the regular images to build up the screen, import the blob into Devil and use blur, then render the Devil image back into the screen.Faster than splicing the images with texplay, then importing into Devil then doing the same thing. Obviously significantly slower than using opengl effects, but in some situations you could probably get away with it and you wouldn't need to delve into real opengl (especially if the screen was small and/or you didn't care that you needed a strong PC to run it).
Parent - - By AmIMeYet Date 2010-09-28 07:19
Well actually I'm trying to use as little dependencys as possible, so that's why I don't use DevIL or OpenGL. They can be hard to set up, decreasing the chance of anyone bothering to try my game.

And although using texplay for blur won't exactly be fast, I hope I can get away with it. ;)
Parent - - By banister Date 2010-09-28 07:36
ill write a fast blur if there's demand for it
Parent - - By AmIMeYet Date 2010-09-28 08:36
There is now! :)

Although I'll get back to you on that; I first want to try it out myself with a ruby-based blur on a sample game image, and if that works you won't have to go through the trouble of adding it..
Parent - - By banister Date 2010-09-28 11:02
There already is a ruby-based blur developed by devgomes http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=1590;hl=blurring
Parent - - By AmIMeYet Date 2010-09-28 18:54
Okay that went way too slow: a full (640x480) image takes 66 seconds to blur! (50 for vertical and 20 for horizontal)

Count me in for c-based blur!
Parent - - By banister Date 2010-09-28 19:42
hahaha, i think there were a couple of blurs in that post, you could try the other and see if it has better performance  :)

But yeah you're right, blurring is definitely not ruby-friendly :)
Parent - By AmIMeYet Date 2010-09-28 20:38
Haha Snae/devgomes's old version is 317 seconds (although the result looks better ;) )!
Parent - - By Spooner Date 2010-09-29 12:25

> Well actually I'm trying to use as little dependencys as possible, so that's why I don't use
> DevIL or OpenGL. They can be hard to set up, decreasing the chance of anyone bothering
> to try my game.


Actually, if you are distributing via Ocra, you can include the Devil dlls and there is absolutely no barrier to use. Admittedly, slightly more trouble on Linux (just need to do a simple "sudo apt-get install libdevil-dev") though potentially a lot more trouble on OS X (The gosu .app file doesn't include Devil). If you can get an OpenGL gem to install properly on your machine then you have a similar situation, but I've not been able to do that.

I really wouldn't discount these two libraries, as long as you don't need easy Mac distribution.
Parent - By AmIMeYet Date 2010-09-29 19:23
Oh, alright then. I'll reconsider use of them.
Parent - - By banister Date 2010-09-26 17:49
yeah it's already in the 0.2.983 pre-release version. It was Spooner's  idea to put this in...it's pretty cool actually -- using a combination of Window#to_blob(x,y,width,height) and TexPlay.from_blob()  you can generate your own Gosu::Image's directly from the framebuffer. Not sure about performance, but i think for reasonably small screen grabs it may be OK. I'm sure spooner will let us know. :)
Parent - - By jlnr (dev) Date 2010-09-26 19:38
Can you make it so it will update directly to an existing image instead of creating a new one? That should be a tiny bit faster.
Parent - - By banister Date 2010-09-26 20:50
yeah i could i guess....but i think it'd be really rare someone wouldn't want to stick it in a new image? not sure
Parent - - By jlnr (dev) Date 2010-09-26 21:20
Depends on what you're doing I guess. For the aforementioned effects, updating an existing image would be faster. But I'm not sure if it'd be fast enough in the first place :)
Parent - - By Spooner Date 2010-09-26 22:38
glCopyTexImage2D to an existing image, rather than using the blob intermediary (via lots of Ruby objects) would be a lot faster, as jlnr suggested (http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=36).
Parent - By RavensKrag Date 2010-09-27 06:16
Could you perhaps have both...? I don't really know much about this stuff, but it seems like there would be advantages to having it both ways.
Parent - By Spooner Date 2010-09-26 21:25 Edited 2010-09-26 21:31
For my purposes, I want to compose a number of objects from small images for several purposes:

1) So I can cache these composed images and just draw them faster than I could otherwise.
2) So I can save those composed images to disk (which are then cached for the next run of the app).
3) So when I draw the composed images semi-transparently, they don't look terrible where the images they are composed from overlap (the user gets to build the objects themselves, so I can't avoid overlaps).
4) So I can show the user lots of thumbnails of the objects, without having to redraw all the full size objects all the time (this would also require my trailing all over my rather large database too, so would take forever).

I can do it in texplay, but it is relatively slow since it is using raw CPU rather than GPU to do the composition. I do need to do it a fair bit, every so many seconds, though not each frame. As long as doing it doesn't stutter the application too much, it doesn't matter if it takes a bit longer than a normal frame.

It could also be of general use...for taking and saving screenshots when the user presses a key. This is more convenient than using print-screen or using a separate application to take the screenshots.
Up Topic Gosu / Gosu Exchange / Trying to implement Gosu::Window#to_blob

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill