This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Thoughts on terrain imaging
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: mskala at ansuz dot sooke dot bc dot ca
- Cc: xconq7 at sources dot redhat dot com, <xconq-hackers at lists dot sourceforge dot net>
- Date: Tue, 23 Nov 2004 14:40:46 -0500 (EST)
- Subject: Re: Thoughts on terrain imaging
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