New Idea, Re: Code review

[Philipp Gühring <p.guehring@enemy.org>]

A friend of mine (Robert Kist) developed another very interesting way
to check for buttons:
Copy the picture, which shows the screen and all the buttons to
another file.
Use a graphic manipulation program like Gimp, which supports Layers.
Load the picture in the background layer, and paint in a layer above.
Select color #1 (we start counting by zero).
Paint all pixels, which should react as the first button with this
color.
Select the next color, and paint the next button.
In the end, fill the rest with Color 0.

In the game code, you have to load the picture, and when a
pointer-button is clicked, you just have to lookup the
pointer-coordinates in the picture, and the color there tells you,
which button was clicked. Very speedy!

This technique is very helpful, if you have a static
interface (like Würstelstand has), and Button-areas that doesn´t fit
the rectangular definition. (Objects in a 3D space).
It´s main disadvantage is the additional memory consumption of the
button-map.

You could also change the system to dynamically generate those
button-maps, when the interface is dynamically generated.


>Well, if you were *REALLY* pushed for time and had a *HUGE* number
of "Buttons" >then you could try storing the buttons according to
(say) their Y coordinates >and do a binary search instead of a linear
one...or perhaps grouping the >buttons into some kind of hierarchical
structure with bounding boxes around >each group of buttons.  These
technigues could dramatically speed up the >search if there were many
hundreds of buttons. >
>However, if you are talking about a GUI with a couple of dozen buttons, it'll
>be faster to do exactly what you are doing now.

Yes, you are right.

Many greetings,
--
~ Philipp Gühring              p.guehring@poboxes.com
~ http://www.poboxes.com/p.guehring  ICQ UIN: 6588261