public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: Hans Ronne <hronne@comhem.se>
Cc: xconq7@sources.redhat.com
Subject: Re: IMFApp Office
Date: Sun, 08 Aug 2004 01:34:00 -0000	[thread overview]
Message-ID: <41157BB9.50508@phy.cmich.edu> (raw)
In-Reply-To: <l03130300bd3b11378653@[212.181.162.155]>

Hans Ronne wrote:

>>With the Linux/X11 Imfapp, the images from 'wreckreation.imf' appear
>>strangely in the 32x32 menu tiles, but the closeup views seem to be
>>fine. Any idea why that might be?
> 
> This is because your images have non-standard sizes.

I realize they have non-standard sizes, but that should not cause black 
patches to appear at various places around the images in 32x32 grid 
boxes (whereas there are no display problems with the scaled images in 
the 32x32 closeup view).

> Xconq assumes by default that images fit within a 32x32 box (the "unit"
> box). I found that rather restrictive a few years ago, when I added the
> images for the advances and lord-rings games. These images were from
> various Civ2 scenarios, and all fit within a 44x48 box (or to be more
> precise, I made sure that they would fit within a hexagon of that size,
> which is what the basic Xconq cell is.

I saw the 44x48 images, and assumed that Xconq would scale the images 
based on that. The reason I chose a height of 64 is so that it would fit 
the largest view size without having to be scaled back up from 32x32.

> The point of staying within one cell is that it makes the graphics much
> more complicated (and time-consuming) if an image covers adjacent cells,
> since these adjacent cells also must be redrawn when the unit moves.

I'm not interested in drawing outside the cell. I had just hoped for 
scaling, and assumed it was there based on the 44x48 circumstantial 
evidence.

> There is no support for this in the
> current interface code. 

I hadn't tested out the images in a game yet, so I hadn't discovered that.

> However, a further complication is during actual drawing, when best_image
> checks that no image is greater than 32x32 (or 44x48) and scales the image
> in that is the case. Your images, if used in Xconq, would therefore be cut
> to half-size before they are drawn. 

This is what I want. But, at the largest magnification factor, shouldn't 
Xconq be attempting to draw actual 64x64's if they exist?

> What you now
> see is essentially the reverse of this, and indeed, if you click on one of
> the images, click on the other, and then click on the first one, it is
> redrawn at a smaller size which will fit within the 32x32 box.

Right. But that doesn't explain where all the black crap surrounding 
them is coming from.

> My advice would be to try to keep images within the bounds Xconq expect,
> i.e. either 32x32 or 44x48. 

Well, I'll make them 32x32 now that I know how limited the graphics code is.

> P.S. Another strange thing that you may have noticed is that your new gif
> appears (distorted) when you select wreckreation in the new game list. 

Hadn't tested it. My copy of Wreckreation is still in mid-hack and not 
in a usable state.

> So it is also a good idea not to name gifs exactly as an existing game
> (unless you do want that gif to appear in the preview window, of course).

I probably would have reached this conclusion had I seen the symptom you 
describe.

Eric

  reply	other threads:[~2004-08-08  1:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-04  1:31 Improved IMFApp Hans Ronne
2004-08-04  1:59 ` Eric McDonald
2004-08-04 17:57   ` Hans Ronne
2004-08-04 18:46     ` Eric McDonald
2004-08-05  2:27       ` Hans Ronne
2004-08-05  3:18         ` Eric McDonald
2004-08-05 16:17       ` Jim Kingdon
2004-08-05 17:12         ` IMFApp Office (was Re: Improved IMFApp) Eric McDonald
2004-08-06 17:52           ` IMFApp Office Hans Ronne
2004-08-08  0:34             ` Eric McDonald
2004-08-08  1:02               ` Hans Ronne
2004-08-08  1:34                 ` Eric McDonald [this message]
2004-08-08 22:52                   ` Hans Ronne
2004-08-10 10:22                     ` Eric McDonald
2004-08-10 13:25                       ` Hans Ronne
2004-08-10 15:21                         ` Eric McDonald
2004-08-10 19:02                           ` Hans Ronne
2004-08-10 19:50                             ` Eric McDonald
2004-08-10 20:44                               ` Hans Ronne
2004-08-11  2:28                                 ` Eric McDonald
2004-08-11  2:30                                 ` Eric McDonald
2004-08-11  8:52                                   ` Eric McDonald
2004-08-11 15:55                                   ` Hans Ronne
2004-08-11 17:00                                     ` Eric McDonald
2004-08-12  1:56                                       ` Hans Ronne
2004-08-04  9:50 ` Improved IMFApp 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=41157BB9.50508@phy.cmich.edu \
    --to=mcdonald@phy.cmich.edu \
    --cc=hronne@comhem.se \
    --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).