Grabpixel?
BlitzMax Forums/BlitzMax Programming/Grabpixel?
| ||
Is there a fast grabpixel or getpixel? Faster than this? http://www.blitzbasic.com/Community/posts.php?topic=82627 |
| ||
Grabbing a 1x1 pixmap between Cls/Flip is trivial - I do that to get rid of the long-standing Blitzmax mouse lag bug in fullscreen mode. [edit] Quick and dirty test, shows time of ~1ms to grab the pixel color under the mouse: Strict Graphics 1024, 768 Local col:color = New color Local time:Int While Not KeyDown(KEY_ESCAPE) Cls 'draw some crap SetColor 255, 0, 0 DrawOval(50, 50, 200, 200) SetColor 0, 255, 0 DrawOval(250, 50, 100, 100) SetColor 0, 0, 255 DrawOval(50, 250, 200, 200) SetColor 255, 255, 255 time = MilliSecs() col.Get(MouseX(), MouseY()) Print "Time taken : " + (MilliSecs() - time) + " ms" DrawText("R: " + col.RED, 50, 50) DrawText("G: " + col.green, 50, 75) DrawText("B: " + col.blue, 50, 100) Flip Wend Type color Field RED:Int Field green:Int Field blue:Int Method Get(x:Int, y:Int) Local px:TPixmap = GrabPixmap(x, y, 1, 1) Local col:Int = ReadPixel(px, 0, 0) Self.RED = (col Shr 16) & 255 Self.green = (col Shr 8) & 255 Self.blue = col & 255 End Method End Type [edit] RED is in capitals because BLIde. No other reason. |
| ||
There's a mouse lag bug in fullscreen mode? |
| ||
There's a mouse lag bug in fullscreen mode? Yep. At least, there was up to v1.48. And given that it's been there for years I doubt 1.50 fixed it.Strict Graphics 1024, 768, 32 Local IMG:TImage = makeImage() While Not KeyDown(KEY_ESCAPE) Cls 'Local px:TPixmap = GrabPixmap(0, 0, 1, 1) '<<uncomment this DrawImage(IMG, MouseX(), MouseY()) Flip Wend Function makeImage:TImage() Local px:TPixmap = CreatePixmap(32, 32, PF_BGRA8888) px.ClearPixels($FFFF00FF) Return LoadImage(px) End Function |
| ||
I must be losing my mind or something (I've mentioned this before, pretty sure the answer is yes) but for some reason I thought this example was the one that grabbed the full screen pixmap. Fair enough. One millisecond is trivial? I would like to use this stuff for various realtime effects and I am always surprised how slow it is, even on blazing fast modern hardware. I thought when I upgraded from my 2007 rig this August that I would see a huge speed increase but not so much. |
| ||
At least, there was up to v1.48. And given that it's been there for years I doubt 1.50 fixed it. It seems to me to be a problem with the framerate and event capturing. This appears to be confirmed if you change your example to use Flip 0. Even with your grabpixel "fix", it still seems to lag a bit here on OS X. Using Flip 0, both versions look the same - pretty much lag-less. |
| ||
GrabPixel is not fast enough for real-time effects. Better to use shaders. |
| ||
GrabPixel is not fast enough for real-time effects. Better to use shaders. Which is achieved, how? |
| ||
Which is achieved, how? By passing the texture(s) into a shader that is rendered via a quad. Fastest method requires framebuffers, though. |
| ||
I mean, can you post an example? |
| ||
It's not a trivial thing, by any means. I'm only saying it's the best way (that I know of) to achieve real-time effects. There are a few examples of shader use in the forums. Brucey's GL2Max2D is a rewrite of GLMax2D that uses shaders instead of fixed function. It's not yet complete, but does demonstrate how shaders are set up and the DrawTexture() code shows how to render a texture straight to a quad. If you wanted to render it with some effect, you'd have to modify the GLSL shader code. Link to Brucey's GL2Max2D |
| ||
I am trying to avoid shaders. Probably I should bite the bullet. Is there a card-agnostic shader solution? I've seen GLSL here, right? Is the bottleneck passing images back and forth to the card? Would it be possible to get fast grabs by maintaining an array version of the image in main memory as an array? FWIW what I am working on has a retro look so it's pixel doubled which makes a lot easier than it would otherwise be but it's still too slow unless I use various sorts of cheats or small regions. |
| ||
I don't know of a fast way to grab pixel data. The only time I ever do that is when I'm taking a screen shot; when it doesn't have to be especially fast. Using shaders means never converting and letting the shaders do the work, but it does take additional setup. It's really useful (and worth the effort) if you're doing image processing, but I'm not sure what you're trying to accomplish. Card-agnostic? For a card to not support shaders, it would have to be pretty old. Drivers can be an issue, but I use GLSL. |
| ||
Most common needed realtimeeffects are things like "desaturating" the background", "iceeffects" (the background is kind of "blurred") or other things to make the popup-menu look a bit better. Also dropshadows could get handled by a shader I assume. Think the ones who need this, also need a good render-to-texture which works across all engines (ogl, dx7, dx9, ...), but this is another topic (meanwhile I use "software imagemanipulation" aka drawImageToImage) :D bye Ron |
| ||
"drawImageToImage" Is that under Java? |
| ||
Nope, just something out of my framework: https://github.com/GWRon/Dig/blob/master/base.gfx.imagehelper.bmx bye Ron |
| ||
There's a mouse lag bug in fullscreen mode? http://www.blitzbasic.com/Community/posts.php?topic=94676 |
| ||
Your frameworks look nice, I will definitely be using drawimagetoimage! Looks handy for printing things like bloodsplats onto the ground image! |