This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Isometric images, satellite images, and rotation
mskala@ansuz.sooke.bc.ca wrote:
What I was imagining as "the really right thing" was generating six
isometric views from the one overhead designer-specified image.
Good.
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.
Yes, but this may be the way to go in the longer run.
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.
Well, given the present size of Xconq's user base, and the possibility
that switching to isometric views is not obvious, there may be good
reasons why we haven't heard anything (yet).
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.
Sounds like a bit of a stretched rationalization.... :-)
But, I'm not criticizing the desire to avoid a bunch of extra work at
this point. You're right in saying that the isometric stuff is not
heavily used currently, and very little specific work has been done for
it. It would be nice to get to a point, though, where the abovementioned
isometric terrain sets (road48x33i.gif and friends) are not needed. This
would remove an onus from the game developer/image designer.
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.
My suggestion did not imply keeping forever. I think I used the word
"cache" (or maybe "caching") at some point. One of the features of such
a cache would be to purge/invalidate its entries when the environment it
is associated with changes. If the view changes from overhead to
isometric, or vice versa, or the angle of an isometric view changes,
then the cache would be purged. Then, as images are needed in the new
view, they are generated on-demand (presumably from the overhead "master
image", which we may want to keep in memory at all times for performance
reasons).
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.
Again, if one operates a true cache, then purging/invalidation takes
place, and so we regulate the overall memory burden.
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.
3D acceleration is the only reason I can think of for pawning this sort
of thing off to the interface. But, even then, I would look at how much
code is duplicated in prepping the image for a 3D transform. The
strongest reason, I think, to keep things centralized is to avoid code
duplication.
My counter to the 3D acceleration argument is that the kernel should
provide (not necessarily in the near future) a generic, albeit slower,
transformation engine. This engine should be registered as the default
transformation engine for the kernel image handling code to call,
__probably just a matter of hooking in a function pointer. But___, the
interface should be allowed to override the default by registering a
transformation engine of its own. This engine could be a callthrough to
hardware acceleration. (For example, the SDL library provides access to
OpenGL, and OpenGL can be used for hardware rendering on video cards
that support it.)
* 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.
Ditto. I should note that I have had discussions about unit facing with
people before. I definitely see it as a missing element from the gaming
perspective. Until we had this discussion about rotation, I was
wondering whether we were going to need to specify an array of 6 images
to handle the presentation aspect of facing. But, if the images can be
autogenerated, then that is better.
* 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.
Completely agreed.
* 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.
Yes.
* 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.
Ditto.
* Per-interface changes to use all this.
There will be some, of course. I think that is unavoidable. However, we
should be on the lookout for anything and everything that can be tucked
into a common GUI API, so as to avoid code duplication.
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".
But, is this really less work than writing a generalized routine?
Especially when you have interfaces like Tkconq out there, which do not
have access to a hardware accelerator (to the best of my knowledge).
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.
I agree. I wouldn't recommend that you spend much time on it right now,
unless you really want to. As long as the isometric views are usable and
not broken, I don't think we need to improve them for the time being.
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.
Understood. I think you should work on what you want to work on. As long
as it doesn't break existing functionality for too long, I don't have a
problem with it.
I consider much of this discussion to be on the level of strategic
thought. I don't think much of what we have exchanged will have an
impact on your shorter term goals.
Eric