Re: Thoughts on terrain imaging

[Eric McDonald <mcdonald@phy.cmich.edu>]

Hi Matthew,

  So far, I've had only a brief time to look at your proposal. I 
will give it a more in-depth glance tonight. Some of the areas you 
touched on, I have very little knowledge about, because I was 
content to let Hans deal with them.

  If you want, I will set up a branch in CVS for you sometime in 
the next few days or week. You will need to have a Sourceforge 
user account so that you can be added to the project as a 
developer. I figure this might be easier than you submitting a 
bunch of patches which people would have to apply if they wanted 
to test out your work.

  A couple of quick responses:

On Tue, 23 Nov 2004 mskala@ansuz.sooke.bc.ca wrote:

> * Add data structures to the map to store, for each cell and cell terrain
> type, pointers to image families and subimage numbers for
> "override" images.

For the per-cell case, you may want to implement new layers. I 
believe that the 'aref' and 'aset' macros in 'world.h', IIRC, 
would be worth looking at. (Layer allocation is handled elsewhere.)

> * Change interfaces so that when they go looking for a cell terrain image
> for a given cell, if there is an applicable override image at that cell,
> they use it instead.  I'm hoping to keep the amount of per-interface code
> for this as small as possible; that should be reasonably easy to do,

Yes. The informal UI API exists primarily in 'ui.h', 'kpublic.h', 
and 'ui.c'. The more code that can kept within the common API, the 
better. As I work on the SDL interface, I will probably be moving 
more code into the common API. Just yesterday, I identified 
another chunk that is common, but currently distributed amongst 
the interfaces. The hope is that, eventually, we will have a 
well-defined, formalized UI API, and will thus be able to attract 
more UI developers.

>    http://ansuz.sooke.bc.ca/temporary/maptest.g
>    http://ansuz.sooke.bc.ca/temporary/override.gif

I will look at it tonight.

Regarding the bug reports: if you're offering to fix the bugs, 
then that's great. If you would like some help fixing them, please 
add them to the project's bug tracking system on Sourceforge, and 
I will try to help you clear out some of them.

As far as GDI memory goes, this is something that Hans has been 
complaining about for quite some time. From what little reading 
that I have done, there appears to be an upper limit on the number 
of GDI handles available (and possibly the amount of GDI object 
heap available) in Win32. It varies from version to version. So, 
this is strictly a Win32 consideration, and it may only be 
applicable to the Tcl/Tk interface, because Tk does a lot of 
things behind ones back. I think that we have more control of our 
situation in SDL. And, of course, Curses is irrelevant in this 
regard.

  Thanks,
    Eric