This is the mail archive of the xconq7@sourceware.cygnus.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: java-HexGrids.....



Howdy All,

    I had written some code a little while back which worked with tiled hex grids
in Java, so I figured I would share some of my insights.  I had used Java2 with
Swing and the Java2d API.  This allows the most portability of the code, over using
the AWT directly, and allows different "look-and-feel" to be implemented.  In
general, Java is slower than native code, and GUI work is no exception.  From my
experiences, performance is entirely inadequate for anything real-time, but for
turn-based games like Xconq, it should be fast enough.  By using Java2d shapes
and tiling, background terrain can look really nice, and it is easy and quick to code
with Java2D, since the same hex shape can be used for drawing the grid and the background terrain.  You also need a shape for each zoom, and
walla, different-size grids  In Swing, lightweight components could also help out.  I also agree with Bruce that a server/client architecture
would facilitate the building of different interfaces.

>
> hearing Stan speaking about hexgrids and test implementations, and about hte

> time to use up for it, i made a try in my lunch break.....
>
> for those who want it i made a hexgrid implementation in java with an icon
> running on it, the size is parametrable, no zoom at the moment even if it
> should easily be added.
>
> Since i build up each cell as a java-container it should be possible to stack
> those elements....
>
> i suppose that this thing should be greedy concerning memory, nonetheless i was
> surprised how less work it costed....
>
> i have no time at the moment to devote to it, it was even hard to follow the
> discussion for the future dev of xconq, but if someone wants to have a look at
> it, feel free to contact me, but be prepared it is really a tiny thing ;)
>
> IMHO it would be easier to develop serveral interfaces for xconq if  xconq was
> written in a true client-server sceme, making it possible to separate
> completely the GUI from the GDL-and AI-part as far as i may see the whole thing
> is still intermangled.... but maybe i am wrong....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]