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
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)
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!
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
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.
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?
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
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.. ..
Ohh, that makes more sense. Actually, yeah, that would be a really cool effect.
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).
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. ;)
ill write a fast blur if there's demand for it
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..
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!
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 :)
Haha Snae/devgomes's old version is 317 seconds (although the result looks better ;) )!
> 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.
Oh, alright then. I'll reconsider use of them.
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. :)
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.
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
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 :)
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.
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.
Loading...