Brain Bender

[Zero]

Now here's one for you. Two, actually.

One: Is there anything more accurate than Point? This has a bit to do with my second question. When I use point on a picturebox it doesn't differentiate between RGB (10,0,0) and (11,0,0). In fact, it doesn't differentiate between quite a bit more than that, but you get the idea. I don't really want to use DirectDraw surfaces and the GetPixel command, but perhaps something in the API will do?

Two: I have 91 hexagons arranged in a honeycomb pattern. How in the name of Hades can I determine which one the user clicks on? If they were rectangles it would be easy, but they're interlocked hexagons. This has been driving me up the wall for about a month. My original plan was to use a 256 color imagemap and let the colors tell me which hex the user clicked (Point MouseX, MouseY) but... Well, read question number one.

~Zero the Inestimable

[Sastraxi]

Use the GetPixel API... If this doesn't work I'm assuming you are running windows under 16/24 bit colour, no?

And also you could create window regions for all of the little picture boxes and go about it that way... and that may slow down the proggie a little though...

[Zero]

No dice. I have the same inaccuracy problem. Do VB pictureboxes distort the colors in bitmaps?

~Zero the Inestimable

[Sastraxi]

Not to my knowledge.

Did you get the window region thing?

[Stef]

For the full range of colors (from 0,0,0 to 255,255,255) your display needs to be set to true color (16 million). High color (32000/64000) can't display all those colors and therefore changes colors it can't display to colors it can.

[Arbiter]

You don't have the picturebox set to twips do you?

That'll cause problems if you do...

[Jotaf98]

Yes, you should use the GetPixel API. To see its declaration, use the API Viewer that comes with VB (I'm assuming you know how to use it).
And I think there might be an algorythm for hexagon's positions somewhere, but the way you're doing it seems the best (and easiest) to me. If the index of the color in the image is 0, it's hexagon 0, if it's 1, it's hexagon 1...

[/\/\isanThr0p]

I did that a long time ago and my code for it was a terrible mess. I just remember that I had two Ideas of which one worked much better but is very very unclean. first I made something with divinding the fields into two and than compare points with a simple funktion in the format of f(x)=2x or something like that.
The other goodworking thing, that I can't really recommmend, even though it was easy was that I made a black and white picture of such a grid. Now I could check where the user clicked and determine if it was on the top or bottom field of the overlapping fields, because I got the color.
(that was a little confusing now, but I think you can figure out what I meant )

[TMTOMH]

I did a little game with a haxagonal grid not too long ago. What I did was use Lines to draw the grid on the form (which was fairly easy with the "Snap to grid" turned on). Then I simply put an array of square picture boxes inside the hexagons. Of course a square does not nicely fill up a hexagon, though. Maybe that was kind of a cheesey (I hate that word) way of doing it but it was the only way I could think of to do it at the time and it works.

Just my $.02 - and overpriced at that.

[Jotaf98]

Well, my idea was a big picture with each hexagon drawn with a different palette index (the palette should be made of gray shades: from RGB(0,0,0) to RGB(255,255,255) )...

Then you just use GetPixel in the place where the user clicked, extract the Red value since it's the easiest one and all 3 are the same ( RedVal = LongColor And 255 ). The selected hexagon is now RedVal. Of course, it has some limitations: the color depth of the screen must be 24 bits, and it only allows for 256 hexagons...

[Zero]

I'm going to treat each hex as a sprite. Then I can just use a monochrome bitmap as a mask (I only need one; they're all the same) to figure out the edges and whatnot.

Thanks for the ideas, though.

~Zero the Inestimable