This is the mail archive of the xconq7@sources.redhat.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]
Other format: [Raw text]

Isometric images, sattelite images, and rotation


Okay, imagine this scenario:

You have a terrain type.  You define an image for it.  Just one image; you
expect the game to automatically scale it to the right size for whatever
magnification the user selects.  With me so far?

I've been working on code to make that work, and it pretty much does.
The one source image for the terrain should be a rectangle a little bit
taller than it is wide, preferably at as high resolution as possible,
containing a hexagonal area that is the actual terrain image, with corners
at the top and bottom and flat sides along the left and right of the
image.  My code will automatically clip four triangles off the corners to
make a hexagon out of the retangular image.  This (after a fair bit of
debugging) works... as long as the user stays in overhead view.  There is
an issue I'm still working on in that at the lowest magnification levels,
where the hex is reduced to a few pixels, the scaler doesn't seem to be
generating data and so things go black if there's no flat colour
default defined.  Current IMF files do define flat colour defaults, but
I'd prefer to be able to generate them automatically.

When the user switches to isometric view, then the fun begins.  In
isometric view, North is no longer vertical - it seems to be 30 degrees
clockwise of vertical when you first press "@".  That puts the corners of
the hexagon at the left and right of the image and flat sides along the
top and bottom, so merely scaling the original points-to-top-and-bottom
image is not good enough; there has to be a rotation applied as well.

But it gets worse, because the user can choose between six different
angles for the isometric view.  To get it really right we need six
different images.  The existing games and code (prior to my changes) seem
to be faking it by having only one "isometric" image for each resolution,
not scaling them, and just hoping the user doesn't notice that the images
don't rotate when the view rotates.  That works because the existing
terrain images don't really have much direction - they're basically
textures and look the same whether North is the right place or not.  It
does seem to automatically switch among subimages for connection and
border terrain, so those will continue to go in the right directions as
the view rotates.

If we're going to use satellite imagery, first we have the issue of
rotating the clipped-out hexagons by 30 degrees to make them appear
points-to-the-side, and then we're faced with the issue of rotating them
into six different orientations as the view rotates, because the "North =
30 degrees counterclockwise of up" assumption only holds in one of the six
orientations.  If we have to precalculate all this we multiply the loading
time for these terrain images by seven, not to mention the memory
requirements and API/data structure issues, and I'm already concerned that
the sheer number of terrain images is going to be too much just with
loading top-down satellite imagery.

Possibly the easiest thing to do is just disable satellite imagery when in
isometric mode, and demand that the game designer provide some reasonable
default terrain images for use in isometric views.  Thoughts?

There is also a masking issue with isometric terrain images because many
existing isometric terrain images go outside the hex boundaries in order
to create a "relief" effect, e.g. for mountains.  That's going to require
special handling in the scaler - I think I can probably do it, but haven't
yet.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/


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