Can I "cut-out" a polygon shape from an image?
BlitzMax Forums/BlitzMax Programming/Can I "cut-out" a polygon shape from an image?
| ||
| I'm creating a Worms / Scorched Earth clone and I'm creating my landscape outline by generating a bunch of points and then creating a spline (eg. curve). Now I have the outline of my landscape on my screen (it's basically a polygon shape). Let's say I have a huge texture image (2000x1500 pixels), and I'd like to paste this image INSIDE of my polygon landscape. The effect would be I would have a nice 2D landscape filled with an image (as opposed to just the polygon outline). Thanks, John |
| ||
| Couldn't you adjust the UV coords of the polygon at the same time as you alter the spline? |
| ||
| To be honest I'm not sure what you mean... (I'm using pre-written code that generates the splines from a bunch of points). However, the spline drawing function uses DrawLine so I don't have any coordinates. I was hoping that I could somehow just use the polygon shape (eg. the spline) to cut-out a part from another image. Also, on a related question, can I draw holes onto an image? (eg. if a tank shoots my terrain I want to darken a part of it or perhaps remove that section) Thanks for your help! |
| ||
| Draw holes into the image: Yes, if you use MaskBlend, just draw them black. Otherwise: No you can not cut out anything. You would need to do as perturbatio mentioned and combine the images quad and the spline to form a new geometrical object with the needed UVs. |
| ||
| Ok, what objects or functions do I need to use to perform what you're saying? I think I understand the general idea: 1) Create a geometrical object with UVs When I generate my spline I can create UVs, but I do not know what they are. Do I need to create a "TPolygon" object or some such thing? How do I then use that object to extract the specified region from my texture? Thanks! - John |
| ||
| Do I need to use some kind of Render-To-Texture mod? (so I can render my terrain to a texture?) As I mentioned, I'm planning to modify my terrain (and thus, the texture) with holes and other stuff.... Thanks, John |
| ||
| Wouldn't it be easier to work purely with images and masks? Sorry i didn't spend much time tinkering but i'd imagine altering the mask when the terrain changes would work. Dito Dreamora ^^ |
| ||
| There are a few solutions, most of which will require some lower level coding such as in OpenGL. You could render the polygon outline to the destination alpha channel, then render the RGB texture only to the RGB channels. Then grab the RGBA texture back. Then draw the texture with alpha blending. You could use the stencil buffer and set it up so that when you draw the polygon it creates a stencil in that shape in the stencil buffer, and then use the stencil test to draw the texture so it only draws pixels that are in the stencil. You could draw the entire texture over all of the screen and then `cut out` the sky by drawing a polygon that is the inverse of the land polygon where the sky is. One question - how are you dealing with the possibility that the graphics hardware has a limit to the maximum texture size, which may not support such a large texture? What if the max texture size is 64x64? As to cutting holes in the land you'd have to either render them directly into the texture which might require using OpenGL extensions or other technical stuff, or render the texture to the screen and then draw the cutout and then re-grab the texture or portion theoreof. Or you could keep track of a list of all the holes, draw the unexploded landscape and then draw all the holes, per frame. |
| ||
| Thanks for the reply... It sounds like rendering to a texture may or may not work because of the size of my terrain (eg. 2000x1000 pixels or whatever it is). Drawing the landscape and then each hole wouldn't really work because then I wouldn't be able to use the built-in image collision detection (which is what I think I want to use). So what option(s) do I have that will work on generally every machine? Something with the stencil buffer? (I don't even know what that is...) It seems like it wouldn't be too hard to simply draw an image and then deform it by drawing circles and other shapes onto it.... =( *sigh* I thought BlitzMax handled this kind of stuff with ease and is mostly why I purchased it =( |
| ||
| It sounds like rendering to a texture may or may not work because of the size of my terrain (eg. 2000x1000 pixels or whatever it is). If you use this technique, you could split the texture up into smaller sections. |
| ||
| Just use a bunch of smaller textures. The graphics interface in BlitzMax is not very well suited to doing things where you want to READ the contents of the buffer. It's good at drawing stuff, mostly. When you want to keep permanent changes to landscape images and stuff like that, or handle huge bitmaps, then you have to get more clever about how you use what's available. |
| ||
| I may not understand exactly what SofaKing is asking but if you have the coordinates that make up the polygon you could make a polygon fill algorithm like MS paint can do. This site has a tutorial which deals with the theory side of it: http://www.cs.rit.edu/~icss571/filling/index.html Sorry though if I've misunderstood, it's late :) |
| ||
| It seems like it wouldn't be too hard to simply draw an image and then deform it by drawing circles and other shapes onto it.... =( *sigh* I thought BlitzMax handled this kind of stuff with ease and is mostly why I purchased it =( Me too, man. I used to do this sort of thing with mindless ease in Qbasic, but for some reason, we have a much harder time making this work in the (much more advanced!) Blitzmax. I really, really want to be able to edit images on the fly. It seems Max's OpenGL access might be a solution. I've got to look into it though. |
| ||
| See my response to your thread, drew. Indeed you need to get into writing your own OpenGL if you want to get this working at a good speed. Blitzmax is more advanced and OpenGL is much more advanced that the bitmap-oriented pixel manipulation that you used to do in the old days. But at the same time, these new benefits come with the side effect that a great emphasis has been placed on drawing stuff and much less on reading stuff. It would've been really nice if basic OpenGL had a non-trashed backbuffer, direct access to reading the backbuffer yourself, etc, but it's taken until later versions to get that kind of functionality. You just have to rethink how you go about achieving the results you want. |
   |