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: Reduced Image Quality for 32x32 Pixel Units
Date: Sun, 12 Dec 2004 04:21:00 -0000 [thread overview]
Message-ID: <41BBC642.7070605@phy.cmich.edu> (raw)
In-Reply-To: <Pine.LNX.4.53.0412112219290.12327@opal.ansuz.sooke.bc.ca>
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
next prev parent reply other threads:[~2004-12-12 4:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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=41BBC642.7070605@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).