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]

Re: Isometric images, satellite images, and rotation


On Sat, 4 Dec 2004, Eric McDonald wrote:
> > angles for the isometric view.  To get it really right we need six
> > different images.
>
> Unfortunately our CVS repo is already burdened with lots of images. I
> would be loathe to increase checkout or update times any more than
> absolutely necessary. (We can probably win back much space in the repo

I hadn't even thought of the idea of six *designer-specified* images; I
agree that would be unworkable.  The goal I've had in mind throughout here
has been for the system to be able to generate all it needs from *one*
high-resolution overhead image, because that's what it'll have to do with
satellite data.

What I was imagining as "the really right thing" was generating six
isometric views from the one overhead designer-specified image.  That's
plenty bad enough because of the memory and initial loading time issues.
The way the system is currently designed it has to load or generate, and
then store, all the scaled images for all the magnifications, in isometric
and overhead, i.e. 7*2=14 images per cell terrain type.  (Probably some
of those can be eliminated in the case of the lowest magnifications
where isometric doesn't make a difference to the shape.)  In the case of
a patch of satellite data where there is in effect a new terrain type per
cell, that could easily run to thousands of images.  Going from 2 to 7
(overhead and one isometric to overhead and six isometric) seems like it
would be bad.  Memory-wise it's probably still only a few megs, but since
all the scaling is done during loading, and the rotation is going to take
more time, it's going to get annoying really fast.

I think maybe we could do it with only three tricky 3D rotations for three
of the views, and then just turn those 180 degrees in 2D to generate the
other three views, but it's still not something I'd look forward to coding
and debugging.

> If we can avoid making this a requirement, I think we would be better off.

For sure, there's no way the designers can be expected to produce that.
I want to avoid even auto-generating so many images, at least during
game load.

> >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.
>
> The Civ2 terrain images do have some direction-specific detail.

It appears that there aren't isometric versions of the Civ2 images, and
it goes to flat colours with both my code and the previous code.  Come to
think of it, I don't think I remember seeing isometric versions of much
terrain at all.  Looking through the images directory, it seems we only
have road48x33i.gif, stdt13x9i.gif, and stdt48x33i.gif; that's it.  This
makes me think that maybe it's not so very bad for satellite terrain to go
to flat colors in isometric; most other terrain does the same thing at the
moment, and we haven't had many complaints about that.

It's possible to argue that in isometric mode, the units are packed closer
together and you have terrain relief visible and so there's a whole lot of
information to take in already, and terrain images would get in the way of
that... in other words (the claim could be made) defaulting to flat
colours in isometric is actually a feature.

 you want to be able to
clearly see issues like terrain relief, and the units are packed closer
together, so you actually *want* less of the flash and glitter of image
terrain.  From that point of view, defaulting to flat colours in isometric
mode could be claimed to be a feature instead of a bug....

> I share your concern with keeping too many images in memory. As I
> mentioned to you when closing out your latest patch, we may want to
> consider some sort of caching system and on-demand transforms. Only

Very many things in XConq seem to be designed for lazy calculation - don't
calculate until used the first time, then calculate once and keep forever.
However, even though the imf routines are designed for putting off work
until first demand, the Tcl/Tk and SDL interfaces break it by
pre-requesting all the image sizes they'll ever use, during their
initialization routines.  Also, even if we didn't break it, lazy
calculation helps with the initial CPU requirement but not with the
overall memory requirement.

> I think that this may be wise in the shorter term. However, in the
> longer term, I would rather get it "right", so that the end-user can
> have a seamless experience without feeling like an isometric view is
> inferior (in spite of the fact that it shows relief).

How would you feel about declaring it to be at least partly the
interface's problem?  It seems like issues like image rotation by other
than 90 degrees are the sorts of issues that interfaces can deal with
better than the central code can.  Interfaces will usually have access to
interface- or platform-specific graphics libraries.  In the case of a 3D
accelerated interface (which nobody's working on, but I find it easy to
imagine that someone might) the interface would also have access to
*hardware* for doing this kind of thing, that the kernel couldn't
reasonably access, nor compete with as to speed.

The "really right" solution sounds like it would need several major
elements:

* Extensions to data structures and images so that instead of just asking
for "this image at that size" you ask for "this image, that size,
such-and-such view type, so-and-so view angle".  Note that to *really* be
right it shouldn't even be limited to overhead and isometric.  Note that
to really be right, unit images should probably change for view angles and
overhead/isometric as well, which opens the door to worrying about unit
facing.

* Extension to imf code to automatically calculate any needed
size/type/angle combinations, preferably with the designer given as much
freedom as possible to specify just one input image or a very small number
of them.

* Upgrade 32-bit colour (three channels plus alpha) throughout the data
structures and imf code; because the overhead-to-isometric projection
transform is going to be pretty tricky in 8-bit colour, and would have to
be thrown out and rewritten anyway at such time as we did go to full
colour, so it makes more sense to do that first.

* Some kind of image cache to store calculated images, without soaking up
too much memory, but keeping enough of them that we aren't constantly
recalculating.

* Per-interface changes to use all this.

I think I'd be happier with telling the interface "You can request image
data at whatever size, in a plain overhead view; if you want to show the
user something three-dimensional, you're responsible for projecting it".
Now that we have isometric it seems like a bad thing to *remove* it, but I
don't know that it's a high priority to do a lot of work in the kernel to
support extra features in isometric right now.  At this point I think I'd
like to try and fix that yellow-pixels issue and then see if I can get the
satellite image thing to work in overhead, letting it go to default images
(non-satellite, tile, or flat colour depending on what the designer has
specified) when in isometric.
-- 
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]