public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: mskala@ansuz.sooke.bc.ca
Cc: xconq7@sources.redhat.com,  xconq-hackers@lists.sourceforge.net
Subject: Re: Isometric images, satellite images, and rotation
Date: Sat, 11 Dec 2004 03:58:00 -0000	[thread overview]
Message-ID: <41B2E279.7050201@phy.cmich.edu> (raw)
In-Reply-To: <Pine.LNX.4.53.0412042255240.11605@opal.ansuz.sooke.bc.ca>

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

  reply	other threads:[~2004-12-05 10:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-05  0:04 Isometric images, sattelite " mskala
2004-12-05  2:24 ` Eric McDonald
2004-12-05  4:59   ` Elijah Meeks
2004-12-05 10:27   ` Isometric images, satellite " mskala
2004-12-11  3:58     ` Eric McDonald [this message]
2004-12-11  4:20       ` Attribute System Elijah Meeks
2004-12-12  1:13         ` Eric McDonald
2004-12-12  2:11           ` Reduced Image Quality for 32x32 Pixel Units Elijah Meeks
2004-12-12  2:43             ` mskala
2004-12-12  3:27               ` Eric McDonald
2004-12-12  3:33                 ` mskala
2004-12-12  4:21                   ` Eric McDonald
2004-12-12  4:17                 ` Elijah Meeks
2004-12-12 19:05                   ` Eric McDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41B2E279.7050201@phy.cmich.edu \
    --to=mcdonald@phy.cmich.edu \
    --cc=mskala@ansuz.sooke.bc.ca \
    --cc=xconq-hackers@lists.sourceforge.net \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).