* Improved IMFApp @ 2004-08-04 1:31 Hans Ronne 2004-08-04 1:59 ` Eric McDonald 2004-08-04 9:50 ` Improved IMFApp Eric McDonald 0 siblings, 2 replies; 26+ messages in thread From: Hans Ronne @ 2004-08-04 1:31 UTC (permalink / raw) To: xconq7 I have checked in the improved IMFApp that I have been working on recently. It no longer needs 1 GB of memory and 45 minutes to load imf.dir (well, things were not quite that bad, but almost). A large number of other problems have been fixed as well, which are listed in the ChangeLog. If you wonder what IMFApp is, it's the small image editor that comes with Xconq. In retrospect, I ask myself why I put a lot of work into improving an application that I guess only a handful of people ever use. But here it is, nonetheless ... Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Improved IMFApp 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 9:50 ` Improved IMFApp Eric McDonald 1 sibling, 1 reply; 26+ messages in thread From: Eric McDonald @ 2004-08-04 1:59 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: > I have checked in the improved IMFApp that I have been working on recently. > It no longer needs 1 GB of memory and 45 minutes to load imf.dir (well, > things were not quite that bad, but almost). It loaded fairly quickly on my Linux box. Inside a virtual machine on my hardware takes a little over a minute, which is probably quite fast, given how long a Xconq compile takes in the VM. The image-loading progress report is a nice touch. I think the top-level window size is too big. In the ChangeLog, I think you said you changed it to 900x600 (which is much bigger than 640x480, and would be unwieldy at 800x600). Even at the 1024x768 resolution I prefer (my best monitor is 8 years old, and does not have a particularly good dot pitch, so higher resolutions are too hard to read text in), the window seems too big. > In retrospect, I ask myself why I put a lot of work into improving > an application that I guess only a handful of people ever use. Well, that handful (game developers) is a very important handful. And, I think your work is appreciated by that handful. Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Improved IMFApp 2004-08-04 1:59 ` Eric McDonald @ 2004-08-04 17:57 ` Hans Ronne 2004-08-04 18:46 ` Eric McDonald 0 siblings, 1 reply; 26+ messages in thread From: Hans Ronne @ 2004-08-04 17:57 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >The image-loading progress report is a nice touch. Thanks. It is interesting to see what images are causing problems, and on what platforms. The terrain images (which usually contain a number of subimages of different sizes) obviously take a long time to load. More surprisingly, the pg images take a humongous time to load, but only under Windows. I wonder why. They are just gifs, like the other images. And it's not just that there are a lot of them to load - every single pg image takes a very long time. >I think the top-level window size is too big. In the ChangeLog, I think >you said you changed it to 900x600 (which is much bigger than 640x480, >and would be unwieldy at 800x600). Even at the 1024x768 resolution I >prefer (my best monitor is 8 years old, and does not have a particularly >good dot pitch, so higher resolutions are too hard to read text in), the >window seems too big. Both window size and position should ideally be scaled to the screen, but this part of tcl is buggy. Caused a lot of problems in Xconq, too. I'll see if I can get it to work properly. >If the background color is changed to to black, the black text used for >image names no longer shows up (not surprising), and setting the >foreground color does not appear to remedy the situation >(semi-surprising). Perhaps text color needs to be tied to foreground >color, or else a separate text color submenu created. Yes. There is definitely room for improvements also in the menu layout. What is called "foreground color" is actually the background color of the closeups and in the grid mode. And some menu options (" as unit" etc) do nothing. I'm not even sure what Stan intended to do with these. The corresponding tcl procedures were just empty shells. >Slightly more ambitious idea: always set the image name text color to >the diametrically opposite color of the background color. This is how the selection box works in the MacOS native IMFApp. However, it doesn't look too good, so I kept it black in the tcltk version. It is therefore also invisible against black. We probably should set both text and box to white in that case. Hans P.S. The "Selected as Terrain" option does nothing under Windows, but this is because tiled drawing doesn't work at all on that platform. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Improved IMFApp 2004-08-04 17:57 ` Hans Ronne @ 2004-08-04 18:46 ` Eric McDonald 2004-08-05 2:27 ` Hans Ronne 2004-08-05 16:17 ` Jim Kingdon 0 siblings, 2 replies; 26+ messages in thread From: Eric McDonald @ 2004-08-04 18:46 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 On Wed, 4 Aug 2004, Hans Ronne wrote: > subimages of different sizes) obviously take a long time to load. More > surprisingly, the pg images take a humongous time to load, but only under > Windows. >I wonder why. Yes, I noticed this and also wondered about it. I don't have any thoughts on why it might this way, unless the GIF-to-pixel-array routine is platform-dependent for some odd reason. > Yes. There is definitely room for improvements also in the menu layout. > What is called "foreground color" is actually the background color of the > closeups and in the grid mode. I noticed that. >And some menu options (" as unit" etc) do > nothing. I'm not even sure what Stan intended to do with these. The > corresponding tcl procedures were just empty shells. Maybe we can cast a "Summon Stan" and find out. The thread length is probably not quite long enough to attract his interest yet, but after a few more replies it might be. :-) > P.S. The "Selected as Terrain" option does nothing under Windows, but this > is because tiled drawing doesn't work at all on that platform. Right. I haven't forgotten that I was looking into that. I just got distracted with other things more recently. Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Improved IMFApp 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 1 sibling, 1 reply; 26+ messages in thread From: Hans Ronne @ 2004-08-05 2:27 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 I have now checked in the improvements we just discussed. I also made the "Save Selected Only" menu option work. This makes it possible to save individual imfs, which is useful for moving imfs between files. Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Improved IMFApp 2004-08-05 2:27 ` Hans Ronne @ 2004-08-05 3:18 ` Eric McDonald 0 siblings, 0 replies; 26+ messages in thread From: Eric McDonald @ 2004-08-05 3:18 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: > I have now checked in the improvements we just discussed. Looks good. >I also made the > "Save Selected Only" menu option work. This makes it possible to save > individual imfs, which is useful for moving imfs between files. Handy indeed. The lack of this capability was one of the things that I thought previously limited the usefulness of the program. Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Improved IMFApp 2004-08-04 18:46 ` Eric McDonald 2004-08-05 2:27 ` Hans Ronne @ 2004-08-05 16:17 ` Jim Kingdon 2004-08-05 17:12 ` IMFApp Office (was Re: Improved IMFApp) Eric McDonald 1 sibling, 1 reply; 26+ messages in thread From: Jim Kingdon @ 2004-08-05 16:17 UTC (permalink / raw) To: mcdonald; +Cc: hronne, xconq7 > Maybe we can cast a "Summon Stan" and find out. The thread length > is probably not quite long enough to attract his interest yet, but > after a few more replies it might be. :-) Don't we need to suggest rewriting IMFApp in GTK for that? Maybe with a little animated paper clip to help people who are having trouble using it. ^ permalink raw reply [flat|nested] 26+ messages in thread
* IMFApp Office (was Re: Improved IMFApp) 2004-08-05 16:17 ` Jim Kingdon @ 2004-08-05 17:12 ` Eric McDonald 2004-08-06 17:52 ` IMFApp Office Hans Ronne 0 siblings, 1 reply; 26+ messages in thread From: Eric McDonald @ 2004-08-05 17:12 UTC (permalink / raw) To: Jim Kingdon; +Cc: hronne, xconq7 On Thu, 5 Aug 2004, Jim Kingdon wrote: > > Maybe we can cast a "Summon Stan" and find out. The thread length > > is probably not quite long enough to attract his interest yet, but > > after a few more replies it might be. :-) > > Don't we need to suggest rewriting IMFApp in GTK for that? Yes, and make sure that it has lots of modeless windows all being used at the same time. A built-in spreadsheet window would also be nice. > Maybe with a little animated paper clip to help people who are having > trouble using it. ;-) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-05 17:12 ` IMFApp Office (was Re: Improved IMFApp) Eric McDonald @ 2004-08-06 17:52 ` Hans Ronne 2004-08-08 0:34 ` Eric McDonald 0 siblings, 1 reply; 26+ messages in thread From: Hans Ronne @ 2004-08-06 17:52 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 I have checked in more IMFApp fixes. I also fixed a bunch of menu problems in xconq itself. The AI type and desinger menu items were not updating correctly, and the on/off checkmarks were not working at all under Windows. It's amazing how new bugs still keep popping up that we didn't notice before. I have also checked in Henry Cobb's improvements to the Time game. Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-06 17:52 ` IMFApp Office Hans Ronne @ 2004-08-08 0:34 ` Eric McDonald 2004-08-08 1:02 ` Hans Ronne 0 siblings, 1 reply; 26+ messages in thread From: Eric McDonald @ 2004-08-08 0:34 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: > It's amazing how new bugs still keep popping up that we didn't notice > before. 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? > I have also checked in Henry Cobb's improvements to the Time game. Good. Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-08 0:34 ` Eric McDonald @ 2004-08-08 1:02 ` Hans Ronne 2004-08-08 1:34 ` Eric McDonald 0 siblings, 1 reply; 26+ messages in thread From: Hans Ronne @ 2004-08-08 1:02 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >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. 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. 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. To handle these bigger 44x48 images, I hacked the interface code, and added a global flag big_unit_images, which is set to true if any image in the game has a width of more than 32 pixels. Now, what you have in wreckreation.gif are two images with completely non-standard sizes: 38x64 and 30x64. There is no support for this in the current interface code. The first image is wider than 32 pixels, and would therefore be interpreted as a 44x48 images and set the big_unit_images flag. the second image would be interpreted as a 32x32 image. 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. In practice, this happens only to the wider of the two images in the tcltk interface, but to both of them in the Mac interface. In IMFApp, the initial drawing just uses the real size of the images without any scaling. After an image has been selected, however, all image sizes have been inited, and the code then uses the "best" of them. You may have noticed that some B/W emblems are initially drawn at their correct (small) size but at twice that size after being cliked on. 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. My advice would be to try to keep images within the bounds Xconq expect, i.e. either 32x32 or 44x48. I always scale images to that size when I make gifs. In addititon, it is a good idea to keep the 44x48 images within a hexagon. I use this magenta/green background grid that you may have noticed in my gifs to ensure that this is the case. Hans 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. The same thing also happens with Elijah's "cil" game. This is because of a hidden but fully functional feature that I added last year (ported from the mac interface), which makes it possible to have preview images for each game. Right now, all of them load the same image, which is the old popup screen. However if you give a gif the same name as a game, that gif is loaded instead. I have prepared gifs for a number of the games but have not had time to finish the job yet. 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). P.P.S. Preview gifs should be exactly 240 x 160 pixels. That is why your iamge is distorted. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-08 1:02 ` Hans Ronne @ 2004-08-08 1:34 ` Eric McDonald 2004-08-08 22:52 ` Hans Ronne 0 siblings, 1 reply; 26+ messages in thread From: Eric McDonald @ 2004-08-08 1:34 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-08 1:34 ` Eric McDonald @ 2004-08-08 22:52 ` Hans Ronne 2004-08-10 10:22 ` Eric McDonald 0 siblings, 1 reply; 26+ messages in thread From: Hans Ronne @ 2004-08-08 22:52 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >> 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). Strange. I don't see any black patches under either Mac OS or Linux/X11. The only thing I see is the failure to scale the images correctly on the first attempt. >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. That's a nice idea. Images at 64x64 are generally so ugly that I never use that magnification. And it seems that scaling of your images works, after some initial confusion, both at 32x32 and 64x64. >> 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? That's also what it does, at least under Mac TCL. >> 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. Well, let me modify that. On the Mac, the image gets distorted (i.e. expanded to 240 x 160 pixels). In the tcltk interface, however, a smaller image is drawn instead. Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-08 22:52 ` Hans Ronne @ 2004-08-10 10:22 ` Eric McDonald 2004-08-10 13:25 ` Hans Ronne 0 siblings, 1 reply; 26+ messages in thread From: Eric McDonald @ 2004-08-10 10:22 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: > Strange. I don't see any black patches under either Mac OS or Linux/X11. > The only thing I see is the failure to scale the images correctly on the > first attempt. I am defnitely significant patchy black regions surrounding the images when they are initially drawn with incorrect scaling in the 32x32 bounding boxes on the display grid. >>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. > > That's a nice idea. Thanks. >Images at 64x64 are generally so ugly that I never use > that magnification. Well, my idea is to have Wreckreation actually look decent at that magnification. Last time, I was at that view power (probably about half a year ago), I thought I saw connector drawing problems (maybe with the Standard game). I will have to recheck that. >And it seems that scaling of your images works, after > some initial confusion, both at 32x32 and 64x64. I wish there was a 44x44 view in IMFApp for the special big images. I tried doing view "Selected as Terrain", but all that did was make a hex pattern with the image inside each hex on the display grid. It did nothing to the closeup views. Also, the other images in the IMF file were still superimposed on top of the display grid, even though it was now a hex pattern instead of invisible rectangles. Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-10 10:22 ` Eric McDonald @ 2004-08-10 13:25 ` Hans Ronne 2004-08-10 15:21 ` Eric McDonald 0 siblings, 1 reply; 26+ messages in thread From: Hans Ronne @ 2004-08-10 13:25 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >Hans Ronne wrote: > >> Strange. I don't see any black patches under either Mac OS or Linux/X11. >> The only thing I see is the failure to scale the images correctly on the >> first attempt. > >I am defnitely significant patchy black regions surrounding the images >when they are initially drawn with incorrect scaling in the 32x32 >bounding boxes on the display grid. This must be a hardware-related issue since I don't see it. Does it also happen under Windows on the same machine? And do you see it with other images as well, or just with the non-standard size wreckreation images? >I wish there was a 44x44 view in IMFApp for the special big images. In fact, the 32x32 view is really 44x48, to accomodate the special big images. And the 16x16 view is really 24x26. And so on. >I tried doing view "Selected as Terrain", but all that did was make a hex >pattern with the image inside each hex on the display grid. It did >nothing to the closeup views. Also, the other images in the IMF file >were still superimposed on top of the display grid, even though it was >now a hex pattern instead of invisible rectangles. Well, that is how the Selected as Terrain is supposed to work, i.e. to draw all units agains the selected image as background. The closeups are not supposed to be affected. Naturally, it will look strange if you select a unit image as terrain, but the program does it anyway. Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-10 13:25 ` Hans Ronne @ 2004-08-10 15:21 ` Eric McDonald 2004-08-10 19:02 ` Hans Ronne 0 siblings, 1 reply; 26+ messages in thread From: Eric McDonald @ 2004-08-10 15:21 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: >>Hans Ronne wrote: > This must be a hardware-related issue since I don't see it. Does it also > happen under Windows on the same machine? And do you see it with other > images as well, or just with the non-standard size wreckreation images? I have not seen this with any other images. Testing under Windows would not be of much help on my machine, since that OS runs on virtual hardware. Windows XP video is done on a VMware virtual SVGA adapter (and is then presumably sent as a pixmap or something to be put up in a X display), whereas my Linux video is on a GeForce card which is only about 2.5 years old. If this was a hardware issue, I think I would be noticing problems elsewhere.... > In fact, the 32x32 view is really 44x48, to accomodate the special big > images. And the 16x16 view is really 24x26. And so on. I see. It did seem that the display boxes were rather larger than the 32x32 images being displayed in them. Since this is the case, shouldn't the "View" menu display sizes be listed as "44x48", "24x26", etc...? > Well, that is how the Selected as Terrain is supposed to work, i.e. to draw > all units agains the selected image as background. The closeups are not > supposed to be affected. Naturally, it will look strange if you select a > unit image as terrain, but the program does it anyway. OK. Fair enough. However, the image that I did this with was one of the 44x44 heroes from 'fantasy.imf'. Shouldn't the other images have been aligned precisely over it, since it is terrain-sized? Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-10 15:21 ` Eric McDonald @ 2004-08-10 19:02 ` Hans Ronne 2004-08-10 19:50 ` Eric McDonald 0 siblings, 1 reply; 26+ messages in thread From: Hans Ronne @ 2004-08-10 19:02 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >> In fact, the 32x32 view is really 44x48, to accomodate the special big >> images. And the 16x16 view is really 24x26. And so on. > >I see. It did seem that the display boxes were rather larger than the >32x32 images being displayed in them. Since this is the case, shouldn't >the "View" menu display sizes be listed as "44x48", "24x26", etc...? Perhaps. The big images started out as a oversized variants for some games that I wrote, so I kept the old labels. But since the oversized images are becoming more and more popular, maybe one should regard them as the standard at some point. >> Well, that is how the Selected as Terrain is supposed to work, i.e. to draw >> all units agains the selected image as background. The closeups are not >> supposed to be affected. Naturally, it will look strange if you select a >> unit image as terrain, but the program does it anyway. > >OK. Fair enough. However, the image that I did this with was one of the >44x44 heroes from 'fantasy.imf'. Shouldn't the other images have been >aligned precisely over it, since it is terrain-sized? Not necessarily. The background (terrain) is drawn using 32x32 tiles that fit snugly together, just as if the background was a map. You will notice that if a 44x48 image is used as a tile, it is trimmed to 32x32 size first. Now, individual unit images in IMFApp are positioned in a way that bears no relationship to the background tiles. The program just checks how wide the window is, and then computes how many columns it can squeeze in. Therefore, if you resize the window by a small amount (not enough to change the number of columns) you will find that the unit images move, while the background tiles stay the same. Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-10 19:02 ` Hans Ronne @ 2004-08-10 19:50 ` Eric McDonald 2004-08-10 20:44 ` Hans Ronne 0 siblings, 1 reply; 26+ messages in thread From: Eric McDonald @ 2004-08-10 19:50 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 On Tue, 10 Aug 2004, Hans Ronne wrote: > >I see. It did seem that the display boxes were rather larger than the > >32x32 images being displayed in them. Since this is the case, shouldn't > >the "View" menu display sizes be listed as "44x48", "24x26", etc...? > > Perhaps. The big images started out as a oversized variants for some games > that I wrote, so I kept the old labels. But since the oversized images are > becoming more and more popular, maybe one should regard them as the > standard at some point. From my point of view, the choice is simple and straightforward: (1) If a box is 44x48, and 32x32 images fit into it (I don't care if they are scaled up or not), then the view should be labeled "44x48". (2) If a box is 32x32, and 44x44 images are displayed in it by scaling them down, then the view should be labeled "32x32". Anything else is misleading. > >OK. Fair enough. However, the image that I did this with was one of the > >44x44 heroes from 'fantasy.imf'. Shouldn't the other images have been > >aligned precisely over it, since it is terrain-sized? > > Not necessarily. The background (terrain) is drawn using 32x32 tiles that > fit snugly together, just as if the background was a map. Well, not quite. I thought you said earlier that Xconq hexes were 44x48. (I may be mistaken, though, and it might have been in our private thread.) If they were 32x32, then the entire hex would be covered by a 32x32 image; if the unit had occupants, then the hex would be entirely obscured (as well as part of the surrounding hexes). >You will notice > that if a 44x48 image is used as a tile, it is trimmed to 32x32 size first. But why? If that's not the same size as the cell actually used with 32x32 views in Xconq, then what is the point? And I think you must mean "scaled" instead of "trimmed", because the bright "transparent" border colors outlining the hex were still showing. If cropping had taken place, then most, if not all, of that would have gone away. I will double-check to make sure that this is what I saw, but I am fairly certain. > Now, individual unit images in IMFApp are positioned in a way that bears no > relationship to the background tiles. >The program just checks how wide the > window is, and then computes how many columns it can squeeze in. Therefore, > if you resize the window by a small amount (not enough to change the number > of columns) you will find that the unit images move, while the background > tiles stay the same. OK. This is really non-intuitive to me. I don't see any useful purpose to tiling a background with hexes, if units don't sit in the middle of the hexes, so that one can actually see how they look in a given terrain. Instead of tiling the background with off-scale images of the given terrain image, why doesn't IMFApp just place regular Xconq-sized hexes under each unit on the display grid (forget about tiling ad nauseum), so that each unit can appear as a "cameo" in a distinct hex cell? Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 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 0 siblings, 2 replies; 26+ messages in thread From: Hans Ronne @ 2004-08-10 20:44 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >>You will notice >> that if a 44x48 image is used as a tile, it is trimmed to 32x32 size first. > >But why? If that's not the same size as the cell actually used >with 32x32 views in Xconq, then what is the point? > >And I think you must mean "scaled" instead of "trimmed", because >the bright "transparent" border colors outlining the hex were >still showing. If cropping had taken place, then most, if not all, of >that would have gone away. I will double-check to make sure that >this is what I saw, but I am fairly certain. No, the images are indeed cropped, not scaled. For example, you will notice that the top and the bottom corners of the background hexes have been trimmed off. There are actually two completely different ways to draw terrain in Xconq: as tiles or as individual images. Tiled drawing always uses square images that are not necessarily lined up with the hex grid. These square images are found either in special gif files (sea.gif and advt32x32.gif) or in terrain.imf itself (everything named "tile", e.g. (imf "plains" ((64 64 tile) ... Non-tiled terrain drawing uses the 44x48 sized hexagons that you find in files like advt44x48.gif. In this case, each individual cell is drawn separately. The files usually contain a row of subimages that are used in a semi-random way to provide some variety. If a non-tiled image is encoded directly in an .imf file, it is called a "terrain" image instead of a "tile" image. Now, if IMFApp does not find a special "tile" image (which it will never do in the case of a unit) it will make one from the available image and use it as a tile. That is why the background unit images are trimmed to 32x32 size. They were converted to "tiles" before being used to draw the background. I would add that the whole tile drawing machinery is semi-obsolete, a remnant from the time when Xconq did not have true images. The best way to draw terrain is certainly the latter, on any platform that supports it (meaning everything but cconq and xtconq). Tiled drawing is now mainly used a small magnifications, usually in the world map, where there are no hexagon images available (and where cells are square-shaped anyway). One could of course make IMFApp draw backgrounds by using individual images instead of tiles, but this would require a lot of work, so I did not assign it a high priority. Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-10 20:44 ` Hans Ronne @ 2004-08-11 2:28 ` Eric McDonald 2004-08-11 2:30 ` Eric McDonald 1 sibling, 0 replies; 26+ messages in thread From: Eric McDonald @ 2004-08-11 2:28 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: > There are actually two completely different ways to draw terrain in Xconq: > as tiles or as individual images. I had gathered that from browsing the IMF's a few days ago, and also previously from noticing that some terrains were drawn as squares (as with colors) in IMFapp, but others, like the Civ2 terrains, were drawn in hexagons. > Now, if IMFApp does not find a special "tile" image (which it will never do > in the case of a unit) it will make one from the available image and use it > as a tile. That is why the background unit images are trimmed to 32x32 > size. They were converted to "tiles" before being used to draw the > background. OK. That is fine for a technical explanation of what is happening, but it still not very intuitive from an user's persepctive, I think. > I would add that the whole tile drawing machinery is semi-obsolete, a > remnant from the time when Xconq did not have true images. The best way to > draw terrain is certainly the latter, I would agree; it seems that that would be less computationally expensive. > One could of course make IMFApp draw backgrounds by using individual images > instead of tiles, This is more like what I had expected. Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 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 1 sibling, 2 replies; 26+ messages in thread From: Eric McDonald @ 2004-08-11 2:30 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 There appears to be a bug with IMFApp when it is attempting to draw a closeup of an IMF which has multiple definitions. When viewing the Cast Iron Life images, the 8x8 closeup (which is defined separately, but has the same name as the larger image definition in the IMF file) appears oddly, and the correct image is not displayed. Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-11 2:30 ` Eric McDonald @ 2004-08-11 8:52 ` Eric McDonald 2004-08-11 15:55 ` Hans Ronne 1 sibling, 0 replies; 26+ messages in thread From: Eric McDonald @ 2004-08-11 8:52 UTC (permalink / raw) Cc: Hans Ronne, xconq7 Eric McDonald wrote: > When viewing the Cast Iron Life images, the 8x8 closeup (which is I meant the so-called "16x16" closeup, not the 8x8 one. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 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 1 sibling, 1 reply; 26+ messages in thread From: Hans Ronne @ 2004-08-11 15:55 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >There appears to be a bug with IMFApp when it is attempting to draw a >closeup of an IMF which has multiple definitions. > >When viewing the Cast Iron Life images, the 8x8 closeup (which is >defined separately, but has the same name as the larger image definition >in the IMF file) appears oddly, and the correct image is not displayed. I noticed this. I would say that what really happens is that those units (not all of them) that have an 8x8 image for some reason is using it at 16x16 magnification, too, instead of scaling down the 32x32 image. I don't think IMFApp is to blame for this, but rather the general image scaling code (best_image) which is used by both Xconq and IMFApp. It is unusal to provide 32x32 and 8x8 images, but not 16x16, so the code may get confused. Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-11 15:55 ` Hans Ronne @ 2004-08-11 17:00 ` Eric McDonald 2004-08-12 1:56 ` Hans Ronne 0 siblings, 1 reply; 26+ messages in thread From: Eric McDonald @ 2004-08-11 17:00 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 On Wed, 11 Aug 2004, Hans Ronne wrote: > I noticed this. I would say that what really happens is that those units > (not all of them) that have an 8x8 image for some reason is using it at > 16x16 magnification, too, instead of scaling down the 32x32 image. Really? At least in my closeups, it appeared that the top left corner of the 44x44 was appearing unscaled, and with the transparency colors unsuppressed) in the "16x16" (22x24?) view box. >I don't > think IMFApp is to blame for this, but rather the general image scaling > code (best_image) which is used by both Xconq and IMFApp. It is unusal to > provide 32x32 and 8x8 images, but not 16x16, so the code may get confused. Then this is even more bothersome to me, because I would like to provide an actual family of images which have distinct images (but same name) for each view size, and if the code that handles this is used in Xconq, then things could get ugly. Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IMFApp Office 2004-08-11 17:00 ` Eric McDonald @ 2004-08-12 1:56 ` Hans Ronne 0 siblings, 0 replies; 26+ messages in thread From: Hans Ronne @ 2004-08-12 1:56 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >On Wed, 11 Aug 2004, Hans Ronne wrote: > >> I noticed this. I would say that what really happens is that those units >> (not all of them) that have an 8x8 image for some reason is using it at >> 16x16 magnification, too, instead of scaling down the 32x32 image. > >Really? At least in my closeups, it appeared that the top left >corner of the 44x44 was appearing unscaled, and with the >transparency colors unsuppressed) in the "16x16" (22x24?) view >box. This is an aspect of another problem (failure to scale some images correctly on the first attempt) that we already discussed for the emblems. After you click on the image, however, it will be scaled correctly from 32x32 to 16x16. But the 8x8 images override the scaled image at this point, which they should not do (at least not at 16x16 resolution). >>I don't >> think IMFApp is to blame for this, but rather the general image scaling >> code (best_image) which is used by both Xconq and IMFApp. It is unusal to >> provide 32x32 and 8x8 images, but not 16x16, so the code may get confused. > >Then this is even more bothersome to me, because I would like to >provide an actual family of images which have distinct images (but >same name) for each view size, and if the code that handles this >is used in Xconq, then things could get ugly. If you provide an entire family you should be safe. It is only if you leave a hole in the middle that the code apparently gets confused. The fix is probably trivial, like changing a < to a <=, but I haven't had time to look into this since I assigned the path-finding bug a higher priority. Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Improved IMFApp 2004-08-04 1:31 Improved IMFApp Hans Ronne 2004-08-04 1:59 ` Eric McDonald @ 2004-08-04 9:50 ` Eric McDonald 1 sibling, 0 replies; 26+ messages in thread From: Eric McDonald @ 2004-08-04 9:50 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: > I have checked in the improved IMFApp that I have been working on recently. If the background color is changed to to black, the black text used for image names no longer shows up (not surprising), and setting the foreground color does not appear to remedy the situation (semi-surprising). Perahps text color needs to be tied to foreground color, or else a separate text color submenu created. Slightly more ambitious idea: always set the image name text color to the diametrically opposite color of the background color. Eric ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2004-08-11 17:09 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).