Need suggestions for drawing selection quad.
BlitzPlus Forums/BlitzPlus Programming/Need suggestions for drawing selection quad.
| ||
| In my app, I am displaying a texture on a canvas. I need to allow the user to zoom in, and to do that I'm manually changing the size of the canvas with windows GDI calls. Why am I doing this? Because scaling a canvas in this way is instantaneous, plus you get bilinear filtering when scaling up, and antialising when scaling down, for free. But there's one little problem. Over one of these canvases I need to draw quad which can be any shape. This quad needs to be drawn with a marquee/marching ants style for the lines. Ie, black and white dashes that move along the line. The quad also needs one red vertex at each corner. Now, I was drawing this quad to my canvas and that was working great, until I found out that zooming images by directly manipulating the data on the canvas was extremely slow. So I changed to the manual resize canvas option, but now I have a problem. I can't draw my quad to my canvas anymore, because it will be scaled with the canvas. Now, if I could draw a second canvas over the first, and enable some kind of masked drawing, that might work. But it would have to be fast. Unfortunately I don't even know what a "canvas" in Blitz really is in windows. It's certainly not called a canvas on MSDN... The second option would be to draw lines. I found a command called LineTo, but it wants a "device context" for the window or whatever that I want to draw my lines to. Even if I could get the device context for my main window, I'm not sure that these lines would actually draw over my canvas. Also, in order to draw my marching ants, I would have to draw hundreds of individual lines all around the border of my qaud, and I'm not too sure that's going to be very fast. So does anyone have any suggestions here for how I can accomplish what I'm attempting to do? |
| ||
| You could try a canvas for each edge of the selection quad. |
| ||
| skid: The sides of the quad can be at any angle, so that won't work. |
| ||
| Come on Skid, you can do better than that, surely? What you are stating is a 'bodge' not a solution. When are we going to get some real progress with BlitzPlus instead of people having to bodge things all the time to get what they want? I don't know about anyone else but I feel that the gadgets in BlitzPlus are getting a little messy. |
| ||
| There's always going to be some bodging, unless you want to have to use the windows functions as they are intended to be used. Of course more gadgets and some more functions couldn't hurt. And some things BLitzplus does make no sense. For example, if I change the position of a canvas with a windows function, Blitzplus will remember the position it last set instead when I use GadgetX(). This makes no sense, because it should just be calling the windows function to get the gadget's current position. But it doesn't. It stores the data itself in a structure somewhere. Forcing me to code my own GadgetX function that returns the real gadget location. |
| ||
| OK, here is a solution.... Why can't BlitzPlus be written from scratch that wraps all the WinAPI functions from the three main .dll files into the BlitzPlus app? That way, we have every WinAPI function and nothing will conflict. Sure the .exe will be much bigger but I don't care about the exe size. |
| ||
| Because there are hundreds and hundreds of functions, the majority of which you don't need, and figuring out which ones you need to use to do a particular thing is a nightmare, even if you have Microsoft's own documentation at your disposal? Besides, as far as I know for the most part there is nothing at all preventing you from doing just that as Blitzplus is currenty written. You could probably code an entire app just using decls that reference the windows functions, and someone already put a list of tons of them in the code archives. The real problems arise when you try to use both together. Blitzplus makes creating a window easy. Windows makes creatign a window hard. But the price you pay for creating that window being easy is that you lose 90% of the customizability. Of course finding a good balance is hard. Blitzplus does a pretty decent job, but needs improvement. The problem is it is missing a lot of basic functionality that people want. Like sliders. (Sliders are not scrollbars.) And the ability to place a progress bar in a window's status bar. And the ability to dtermine which gadget the mouse is over. And... And... and... There's a lot of ands here. But the last thing I want is to have every single windows function exposed at the cost of using them exaclty as microsoft intended, because then I'm just back in the situation I'm in now where I don't even know which of hundreds of commands I should be looking at for a solution. Is there a command to draw a selection with marching ants? I don't know. I do know there is a line command that you can erun that executes a custom function, but we don't jhave function pointers so I can't use that, and besides I'm not even sure what that line needs to be drawn on, or if I can draw it over a canvas. Too many unknowns. |
| ||
| In reality, what Mark might have been better off doing was a light wrapper around the Windows common controls (like MFC type level of wrapper), and then included a custom control than allows Blitz2D commands to run inside of it (a canvas control or whatever). That would allow for all the power of Windows, and keep the Blitz functionality nicely seperated... |
| ||
| Couldnt you capture the canvas, draw your selector box and if scalled redraw the captured image, scale it to whatever then redraw your selector box. |
| ||
| No, because the canvas data itself is not scaled, it is only scaled on the screen. And I can't capture the screen because that would probably be subject to problems with windows overlapping the canvas and such. |
| ||
| I think I've figured out one solution, though it may not be the best one. First I need to update my canvas with any new graphics I want on it (ie, my texture) that will be scaled with it, and use flipcanvas if needed. Then, I use GetDC to get the device context of my canvas. Then I need to draw pixels, lines, and text to this device contex using the GDI commands. These will appear over my canvas, but will not be scaled with the canvas. They will also not actually affect any of the image data in the canvas. They will be clipped to the canvas automatically. Then I return the device context back to windows. The only drawback of this approach I can see so far is that any time a window moves oveer the canvas, all the pixels I have drawn dissapear until I redraw them manually. Windows does not keep track of the pixels and redraw them of it's own accord. There is one other possiblity. I could set up a bitmap... Though I don't know how yet, or what kind I need... a device independent bitmap perhaps... And place that over my canvas, and draw it using a masking mode. It appears that if want to do that though I will need to create a bitmask that defines the areas of the bitmap that will be transparent when blitted. That might not be too hard to do for lines and rectangles, but I'm not sure how I would go about drawing text in that way, unless I convert my text into images and fix the masks for them and blit those too. Perhaps the first method will be good enough though. In order to keep my marhcing ants moving, I need to continuously update the view anyway. |
| ||
| Testing photoshop, it seems their selections dissapear completely when the app loses focus. I guess they figure there's no point in updating them when the user isn't able to modify them. I guess I can do that myself then. So the drawing to the device context thing should work for me assuming I can get text working too. |
| ||
| Hm... I'm not really happy with how this is working now... I have my quad drawing, but for some reason the pixels I draw with SetPixel sometimes don't draw or something, because I get flickering on my vertices which are squares I draw over my lines. The flickering is the lines showing through, and there's nothing wrong with my function to draw the square. That means the results are becoming visible before I free the device context... I wonder if I might be able to do what Edzup suggested after all. While I could not capture the canvas reliably with the desktop buffer, it might just be possible that I can make a copy of it through GDI calls that would copy even the data that is not visible in the window... Then it would be a matter of resizing my canvas, capturing it at the new scale, and then returning it to it's normal size, and drawing the quad onto it... But I am afraid that that would result in the user seeing the canvas resize, and allocating the canvas itself at larger sizes might itself take some time. Hm... |
   |