Re: Image handling: update on my status and plans

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

mskala@ansuz.sooke.bc.ca wrote:
> Hi, all.  I've been busy for the last few days with school stuff (and
> writing the world's smallest P2P file sharing application, which you may
> have seen on Slashdot),

Nifty. Looks like they didn't spell your surname correctly though. I see 
that Ed Felten seems to have fueled your competitiveness; I recognize 
that name from elsewhere; I think he had something to do with the DeCSS 
stuff or maybe a DMCA lawsuit....

> and I'm about to go on vacation December
> 21-January 1, 

Enjoy the holidays.

> The "yellow pixels" bug in Tcl/Tk isometric:  I'm still not quite sure
> what's going on here, but it seems to be associated only with certain
> terrain types, (usually, water), and it displays weird patterning
> behaviour that makes it look like it's associated with grid cell
> coordinates rather than images.  Hypothesis: the interface decides how far
> up to shift each cell based on the cell's elevation, and draws a
> "pedastal" of that height underneath the cell image.  The bad cells seem
> to all be at zero elevation, and all be drawn one pixel lower on the
> screen than they should be.  

I brushed past the responsible code a few times earlier today. After I 
get done with my 'draw_unit_*' remodeling/simplifying/API-improving, I 
will try to remember to take a look at this.

> Instead of seeing a one-pixel rim above the
> cell we see scattered pixels because the images are designed with a
> "relief" effect (which I think is suspect because water should be smooth,
> but that's the way they're designed)

The terrain generator ensures that the all terrain with the 'liquid' 
property set has a uniform elevation with all neighboring liquid terrain.

> * Whether a tile instead of an image is acceptable, unacceptable, or
>   preferred.

Good thought.

> * note it *doesn't* specify the image family anymore... that's for the
>   kernel to decide!  Similarly, issues like "which one of the several
>   subimages for this terrain type?" become the kernel's decision rather
>   than the interface's, so that changes to these decisions (as needed
>   to implement satellite map) only have to be implemented in one place.

This will be good, I think. You may also want a way to pass in interface 
hints. For example, if Sdlconq doesn't naturally support tiling, then it 
may need to tell the kernel that so that it can choose an appropriate 
flat color instead.

> The interfaces need to be modified to make these calls, and to respect the
> invalidation callback - so they have to make API calls to the kernel every
> time they want to use images. 

I am presently refactoring the Tkconq unit image code. I think that 
after I am done, it will be easier to implement any API changes from the 
Tkconq perspective.

As far as the interfaces calling the kernel every time for an image, I 
am mostly for it, since this keep things more consistent and take most 
of the image-handling burden away from the interfaces. However, if we 
ever evolve Xconq into a client-server model, I might be concerned about 
traffic in the case of a network game. Of course, the image-handling 
part of the "kernel" might be able to be linked into the client apps. I 
would then want to make sure that we were using unit views rather than 
raw units in the API, since only the server/arbiter should be able to 
touch raw units (clients could request shadow copies, but only for the 
sides they were associated with).
But, that is all a bunch of what-ifs in the future. I think your API 
recommendations are a move in the right direction and should be pursued. 
We can deal with other hurdles later.

> I think that may be the cause of Elijah's recent low-priority bug (with
> the units not having customized images when they first appear) - the
> interface is applying its cached "generic" image for that unit type 

I share this suspicion.

> So, those API changes (and making the data structures 32-bit) are what I
> hope to do in the new CVS branch.  

It's all yours. Probably the most I'll do with it is occasionally merge 
in diffs from the mainline.

> What I would like would be for one
> overhead image at high resolution to become the source for all the other
> views and sizes, with opportunistic use of other designer-supplied images
> if they exist.

I think this is the right approach.

>  Isometric (or, hypothetically, other 3D) images raise some
> issues, because in order to do the "relief" effect seen in the current
> system really properly, we'd need to start with an overhead image and a
> height field and then render it.  That's do-able, but a fair bit of work
> and an imposition on the image designers, too, to make the height fields.

In the case of using height fields, it might be better to use a solid 
color or a elevation-based color gradient (thinking in terms of 
snow-capped mountains).
In times that I have thought about "3D terrain" in the past, it had not 
occurred to me that designer-specified height fields might be specified. 
My thinking has been:
(1) Calculate elevation gradients (slopes) from cell edge to cell edge.
(2) Generate a random elevation "spectrum". Let the designer specify 
error bars for both the amplitude and peak density.
(3) FFT (or otherwise convolve) the spectrum into a "noisy" function.
(4) Add said function to the calculated slope lines.
(5) Sample points on the resultant functions; these points are the 
height field.
It might also be sufficient to just throw down some splines. As long as 
the endpoints are at the correct heights at the cell edges, the designer 
could just specify a "ruggedness" or "elevation variation" parameter, 
and intra-cell elevation variation could be inferred from that.

I do think that anything involving 3D terrain with true intra-cell 
relief is probably worth another separate branch, and is probably too 
much bother for the present, considering what else we have going on. 
Then again, if you can do it in 6 lines....

> Code to manage the cache would also have to be written, but I think that's
> easy - just build a circular double-linked list of images that have
> been synthesized (alongside whatever other structure we're storing them
> in), move a cached image to the front whenever we search for it and find
> it in the cache, and cannibalize the one from the back whenever we want to
> generate a new image and have already got a full cache.  As long as the
> interfaces aren't keeping stale pointers around, we're fine.

Yeah, that would probably work. At minimum, the cache would have to be 
sized as numutypes + numttypes + nummtypes, otherwise there will be too 
many cache misses in the worst case (one of everything shown in the map 
window), and it would start to resemble a hamster running on the inside 
of a wheel.

Eric