public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
* Isometric images, sattelite images, and rotation
@ 2004-12-05  0:04 mskala
  2004-12-05  2:24 ` Eric McDonald
  0 siblings, 1 reply; 14+ messages in thread
From: mskala @ 2004-12-05  0:04 UTC (permalink / raw)
  To: xconq7, xconq-general

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/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Isometric images, sattelite images, and rotation
  2004-12-05  0:04 Isometric images, sattelite images, and rotation mskala
@ 2004-12-05  2:24 ` Eric McDonald
  2004-12-05  4:59   ` Elijah Meeks
  2004-12-05 10:27   ` Isometric images, satellite " mskala
  0 siblings, 2 replies; 14+ messages in thread
From: Eric McDonald @ 2004-12-05  2:24 UTC (permalink / raw)
  To: mskala; +Cc: xconq7, xconq-hackers

mskala@ansuz.sooke.bc.ca wrote:

> 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.  

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 
and in the file releases, if we go from GIF to PNG, since PNG generally 
achieves better compression.)

While I agree that having a stock of 6 different isometric images, plus 
an overhead one, might be ideal, I think it places a large space burden 
on the Xconq project, and another burden on designers of terrain tiles.
If we can avoid making this a requirement, I think we would be better off.

>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.

> 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.

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 
transform an image when its corresponding orientation/projection info 
does not match the current display orientation/projection. I really have 
no idea about what sort of CPU impact this would have. This, if 
feasible, would hopefully address both the storage space and memory 
usage concerns.

> 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?

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).

Eric

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Isometric images, sattelite images, and rotation
  2004-12-05  2:24 ` Eric McDonald
@ 2004-12-05  4:59   ` Elijah Meeks
  2004-12-05 10:27   ` Isometric images, satellite " mskala
  1 sibling, 0 replies; 14+ messages in thread
From: Elijah Meeks @ 2004-12-05  4:59 UTC (permalink / raw)
  To: Eric McDonald, mskala; +Cc: xconq7, xconq-hackers


> 
> 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 
> and in the file releases, if we go from GIF to PNG,
> since PNG generally 
> achieves better compression.)
> 
> While I agree that having a stock of 6 different
> isometric images, plus 
> an overhead one, might be ideal, I think it places a
> large space burden 
> on the Xconq project, and another burden on
> designers of terrain tiles.
> If we can avoid making this a requirement, I think
> we would be better off.
> 

Can't we default to the current system (setting it up
so that if there are terrain images called that don't
exist, that it defaults to the single view) and then
have a seperate Isometric Patch in the patch section?




		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Isometric images, satellite images, and rotation
  2004-12-05  2:24 ` Eric McDonald
  2004-12-05  4:59   ` Elijah Meeks
@ 2004-12-05 10:27   ` mskala
  2004-12-11  3:58     ` Eric McDonald
  1 sibling, 1 reply; 14+ messages in thread
From: mskala @ 2004-12-05 10:27 UTC (permalink / raw)
  To: Eric McDonald; +Cc: xconq7, xconq-hackers

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/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Isometric images, satellite images, and rotation
  2004-12-05 10:27   ` Isometric images, satellite " mskala
@ 2004-12-11  3:58     ` Eric McDonald
  2004-12-11  4:20       ` Attribute System Elijah Meeks
  0 siblings, 1 reply; 14+ messages in thread
From: Eric McDonald @ 2004-12-11  3:58 UTC (permalink / raw)
  To: mskala; +Cc: xconq7, xconq-hackers

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Attribute System
  2004-12-11  3:58     ` Eric McDonald
@ 2004-12-11  4:20       ` Elijah Meeks
  2004-12-12  1:13         ` Eric McDonald
  0 siblings, 1 reply; 14+ messages in thread
From: Elijah Meeks @ 2004-12-11  4:20 UTC (permalink / raw)
  To: xconq7, xconq-hackers

I just wanted to pull this out of the Overlay feature
request and point out that I love this idea that's
Eric has mentioned:

--
And, there is another area of Xconq, where I have
thought attributes should replace existing features,
and that is morale and opinions. I am not sure that we
need to handle these concepts through specialized GDL,
as is the present case. I don't think I have mentioned
this publicly before, but it is my intent (provided
there is not too much angst over it) to replace morale
and opinions with a more generalized attributes system
at some point. I would then see this system being
hooked into things like HP and ACP
interpolation, combat resolution, etc..., __over a
wider range than morale and opinions are currently
limited to.
--

I think morale and opinion would be better served like
this, as would designer-defined variables like
"Health" (A more general condition, with which you
could simulate the effects of malaria on armies or
radiation or whatever), "Stamina", et cetera.



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Attribute System
  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
  0 siblings, 1 reply; 14+ messages in thread
From: Eric McDonald @ 2004-12-12  1:13 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: xconq7, xconq-hackers, xconq-developers

Elijah Meeks wrote:

> to replace morale
> and opinions with a more generalized attributes system
> at some point. I would then see this system being
> hooked into things like HP and ACP
> interpolation, combat resolution, etc..., __over a
> wider range than morale and opinions are currently
> limited to.
> --
> 
> I think morale and opinion would be better served like
> this, as would designer-defined variables like
> "Health" (A more general condition, with which you
> could simulate the effects of malaria on armies or
> radiation or whatever), "Stamina", et cetera.

These are the sorts of things I had in mind.

For those who are wondering what this all about, see:
http://sourceforge.net/tracker/index.php?func=detail&aid=1076170&group_id=124062&atid=698375
and:
http://sourceforge.net/tracker/index.php?func=detail&aid=1081831&group_id=124062&atid=698375
for details.

Eric

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Reduced Image Quality for 32x32 Pixel Units
  2004-12-12  1:13         ` Eric McDonald
@ 2004-12-12  2:11           ` Elijah Meeks
  2004-12-12  2:43             ` mskala
  0 siblings, 1 reply; 14+ messages in thread
From: Elijah Meeks @ 2004-12-12  2:11 UTC (permalink / raw)
  To: xconq7, xconq-hackers

I've noticed in the new release of XConq that any unit
images based on a 32x32 size now appear chunky and
enlarged.  I submitted a bug report at
sf.net/projects/xconq and you can see it most readily
in Opal.  There you'll notice that images based on a
44x44 pixel size appear fine (The cities, for the most
part) while the 32x32 pixel units (The swordsmen,
heroes, et cetera) all appear worse.



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Reduced Image Quality for 32x32 Pixel Units
  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
  0 siblings, 1 reply; 14+ messages in thread
From: mskala @ 2004-12-12  2:43 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: xconq7, xconq-hackers

On Sat, 11 Dec 2004, Elijah Meeks wrote:
> I've noticed in the new release of XConq that any unit
> images based on a 32x32 size now appear chunky and
> enlarged.  I submitted a bug report at

The issue, basically, is that the interface asks for images to be 44x44
(depending on the zoom level).  If there is no 44x44 image, the kernel
creates one by scaling.  The older behaviour was to just return the 32x32
image as the closest match.

One possible way of dealing with it might be to say, okay, 32x32 looks
better than 44x44, so we'll make the interface request 32x32 instead of
44x44.  That raises issues if the designer actually wanted 44x44.  We've
become accustomed to 32x32 unit images (even though the interfaces have
actually been programmed to request 44x44); during my work on the scaler
we already addressed one issue of this type by changing the Tcl/Tk
interface to request 32x32 unit images in the unit type list pane.

Another possible way of dealing with it might be to change the APIs so
that the interface can request from the kernel "Give me an image somewhere
in this range of sizes, and try to avoid scaling if possible."  It's
already looking like the API for getting images has to be made a lot more
general anyway, to deal with issues like isometric/non-isometric terrain.
At present, the kernel just has to kind of guess which kind of image the
interface wants based on the dimensions, and there's Trouble if it guesses
wrong.

I'm starting to get a rough idea of what API changes need to be made.
Maybe it'd be appropriate to do the CVS-branch thing, and/or wait until
after the next non-pre release, because it's going to require
across-the-board changes to both kernel and interfaces.

FWIW, I actually like the blocky look of the scaled images, but I'm
guessing I'm in the minority there.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Reduced Image Quality for 32x32 Pixel Units
  2004-12-12  2:43             ` mskala
@ 2004-12-12  3:27               ` Eric McDonald
  2004-12-12  3:33                 ` mskala
  2004-12-12  4:17                 ` Elijah Meeks
  0 siblings, 2 replies; 14+ messages in thread
From: Eric McDonald @ 2004-12-12  3:27 UTC (permalink / raw)
  To: mskala; +Cc: Elijah Meeks, xconq7, xconq-hackers

mskala@ansuz.sooke.bc.ca wrote:

> Another possible way of dealing with it might be to change the APIs so
> that the interface can request from the kernel "Give me an image somewhere
> in this range of sizes, and try to avoid scaling if possible."  

This is what I was looking into earlier today in response to Elijah's 
bug report. It seems that 'best_image' could be modified to take "int 
w1, int h1, int w2, int h2" instead of "int w, int h". Probably we would 
want to change its name to 'best_image_in_range' or something like that. 
For backwards compatibility, we then make a 'best_image' function which 
calls 'best_image_in_range' with w1 == w2 and h1 == h2. I started to 
look at the logic involved, but got distracted by other things. I could 
probably make the changes, but I would be much more comfortable if you 
did, Matthew.

> I'm starting to get a rough idea of what API changes need to be made.
> Maybe it'd be appropriate to do the CVS-branch thing, 

I'll try to get around to setting up a branch in CVS tomorrow. As long 
as the yellow pixels problem and low res pixel color problems are fixed 
before 7.5.0, I don't really care how long development goes on in a 
special branch.

> FWIW, I actually like the blocky look of the scaled images, but I'm
> guessing I'm in the minority there.

I have mixed feelings about it. But, I have an old monitor with a 
not-so-good dot pitch, so the way I see things on screen is generally 
not as clearly as people using sharper monitors.

Eric

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Reduced Image Quality for 32x32 Pixel Units
  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
  1 sibling, 1 reply; 14+ messages in thread
From: mskala @ 2004-12-12  3:33 UTC (permalink / raw)
  To: Eric McDonald; +Cc: xconq7, xconq-hackers

On Sat, 11 Dec 2004, Eric McDonald wrote:
> calls 'best_image_in_range' with w1 == w2 and h1 == h2. I started to
> look at the logic involved, but got distracted by other things. I could
> probably make the changes, but I would be much more comfortable if you
> did, Matthew.

I'll try building a best_image_in_range function in the kernel - that
should be easy - but I'm not sure about the interface side of the
equation.  I think that there's a TCL command implemented for the purpose
of requesting unit images (possibly even the same one you were looking at
with those crashing bugs I filed recently) and that command will need its
syntax changed or something to deal with the additional arguments, and
then the TCL code that actually uses that command will need to be updated
too.  Presumably similar changes on the SDL side, although I'm even less
sure of the details there.

Now, if there isn't an image in the range and it has to scale, to what
size should it scale?  I'm thinking maybe it should go to the largest end
of the range - it's going to look blocky for being scaled anyway, so it
might as well at least be big - but would it be better to have a third
width/height pair as well, to be the size to scale to if scaling is
necessary?

> as the yellow pixels problem and low res pixel color problems are fixed
> before 7.5.0, I don't really care how long development goes on in a
> special branch.

Low-res pixel color problem = the issue of some terrain types disappearing
at the lowest magnification, right?
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Reduced Image Quality for 32x32 Pixel Units
  2004-12-12  3:27               ` Eric McDonald
  2004-12-12  3:33                 ` mskala
@ 2004-12-12  4:17                 ` Elijah Meeks
  2004-12-12 19:05                   ` Eric McDonald
  1 sibling, 1 reply; 14+ messages in thread
From: Elijah Meeks @ 2004-12-12  4:17 UTC (permalink / raw)
  To: Eric McDonald, mskala; +Cc: Elijah Meeks, xconq7, xconq-hackers


> > Another possible way of dealing with it might be
> to change the APIs so
> > that the interface can request from the kernel
> "Give me an image somewhere
> > in this range of sizes, and try to avoid scaling
> if possible."  

Well, as I'm loathe to cut into developer's time, I
can offer a rather work-intensive solution that can be
handled on my end.  Scaling the images using a true
graphics package (Gimp, in my case) has proven to be,
in my experience, a time-consuming task that tends to
produce poor results.  However, even for the several
hundred images in question, I can put them in 44x44
pixel squares with more blank space.  This would be
time-consuming, also, but it would be my time taken up
and not the time of Eric or Matthew, whose time I
consider more valuably spent pursuing other goals.

If a solution within the code is relatively
straightforward, then by all means do so, otherwise
let me know and I'll plug in all those images (And in
doing so far as to create a universal GIF template for
the future, which may not speed up anything
processor-wise but will go toward making any artists
job a little easier in the future).



		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Reduced Image Quality for 32x32 Pixel Units
  2004-12-12  3:33                 ` mskala
@ 2004-12-12  4:21                   ` Eric McDonald
  0 siblings, 0 replies; 14+ messages in thread
From: Eric McDonald @ 2004-12-12  4:21 UTC (permalink / raw)
  To: mskala; +Cc: xconq7, xconq-hackers

mskala@ansuz.sooke.bc.ca wrote:

> I'll try building a best_image_in_range function in the kernel - that
> should be easy -  but I'm not sure about the interface side of the
> equation.  

Excellent. I'll handle the interface side of things once you have the 
revised function ready.

>I think that there's a TCL command implemented for the purpose
> of requesting unit images (possibly even the same one you were looking at
> with those crashing bugs I filed recently) 

Well, 'imfsample' might be the Tcl/Tk widget you are referring to. The 
function that I recently changed to deal with the crash was 'tk_u_image' 
or something like that. It simply looked up an IMF to use based on a 
name; it didn't have to do with scaling. Matter of fact, there is an 
array of IMF's ('uimages', IIRC) that is precalculated at some point, 
and the function returned an IMF out of that array. I need to find where 
that array is filled out, and I can probably nip some of the interface 
issues there.

Speaking of 'imfsample': I believe it is a Tk widget. Under Windows, it 
likely has a device context associated with it. If 'imfapp' initializes 
3000 or so of these things, that is probably eating up GDI handles (not 
to mention heap) like there is no tomorrow. I wonder if there is a good 
alternative way to implement its functionality. It might solve some of 
the GDI memory problems Hans used to gripe about.

>and that command will need its
> syntax changed or something to deal with the additional arguments, and
> then the TCL code that actually uses that command will need to be updated
> too.  

Sure. Of course.

> Now, if there isn't an image in the range and it has to scale, to what
> size should it scale?  I'm thinking maybe it should go to the largest end
> of the range - it's going to look blocky for being scaled anyway, so it
> might as well at least be big - but would it be better to have a third
> width/height pair as well, to be the size to scale to if scaling is
> necessary?

That is a good thought. The third pair would also be handy if an image 
existed at both ends of the range; it could help decide which one to 
use. Since we are compiling as C++ code now, the third pair can probably 
be made optional arguments defaulting to -1, which would mean to pick 
the largest end of the range, when images exist at both ends or no image 
exists in the range: ", int ws = -1, int hs = -1".

> Low-res pixel color problem = the issue of some terrain types disappearing
> at the lowest magnification, right?

Yes. Sorry if I caused you any alarm about a potential new bug.

Eric

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Reduced Image Quality for 32x32 Pixel Units
  2004-12-12  4:17                 ` Elijah Meeks
@ 2004-12-12 19:05                   ` Eric McDonald
  0 siblings, 0 replies; 14+ messages in thread
From: Eric McDonald @ 2004-12-12 19:05 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: mskala, xconq7, xconq-hackers

Elijah Meeks wrote:

> If a solution within the code is relatively
> straightforward, then by all means do so, otherwise
> let me know and I'll plug in all those images 

We need to do this regardless of whether it is simple or not. I would 
advise you not to bother rescaling the images with an editor.

>(And in
> doing so far as to create a universal GIF template for
> the future, which may not speed up anything
> processor-wise but will go toward making any artists
> job a little easier in the future).

The template sounds like a good idea. I would keep it fairly small 
though (maybe 4 rows by 4 cols) so that it doesn't eat up too much space.

Eric

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2004-12-12  4:21 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-05  0:04 Isometric images, sattelite images, and rotation 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
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

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).