Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2003:
[Freeciv-Dev] Re: (PR#1870) FreecivAC: borders patch
Home

[Freeciv-Dev] Re: (PR#1870) FreecivAC: borders patch

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: ben@xxxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#1870) FreecivAC: borders patch
From: "Jason Short" <jshort@xxxxxxxxxxxxxx>
Date: Wed, 25 Jun 2003 07:01:55 -0700
Reply-to: rt@xxxxxxxxxxxxxx


--On Tuesday, June 24, 2003 11:54:03 -0700 Ben Webb <ben@xxxxxxxxxxx> wrote:

> On Mon, Jun 23, 2003 at 08:05:44PM -0700, Jason Short wrote:
>> The behavior of the new patch is better.  But:
>>
>> - The borders are still sometimes drawn in weird places.
>
> The borders in 'seen' regions are always drawn in the correct places
> (or, at least, they should be). You will see odd behaviour between fog
> and non-fog though, simply because your information is limited.
>
>> I think an omniscient POV would be better.
>
> The previous patch did this. The difference between the two is only 10
> lines of code or so, but I'm reluctant to code both and make it a server
> option or similar, partly because we have plenty of rarely-used
> options already, and additionally because it seems a bit pointless for
> me to be fiddling with this prior to it going into CVS. If some kind of
> consensus can be agreed upon, I can code it.

I think Per also agreed with omniscient POV.  It is the simplest workable 
solution, and I don't see a need for anything more complicated just yet.

But...which "previous patch" did omniscient POV?  Your previous patch 
showed  border changes only in tiles that are known and seen.  My 
suggestion for "omniscient" POV shows changes in all known tiles (even 
fogged ones).

>> - The borders should be drawn underneath units IMO.
>
> Yes, I've noticed this too. This is a natural consequence of moving the
> iso border drawing logic to common client code; the borders get drawn
> either before everything else, or after everything else. This is fairly
> trivial to fix (just call the iso border drawing routine from each
> client's iso tile code) but is less elegant, partly because you need
> some kind of hack to pass struct canvas_store back to common code from
> each client. Is there some fundamental reason why the iso map code isn't
> client-independent in the same way that the non-iso code is? (I also
> notice that borders are not drawn in the iso city dialog map view,
> presumably for similar reasons.)

Ahh, I hadn't realized this function was *called* from common code.

The iso-view drawing code is not common yet because the methods used by the 
clients for drawing are too different.  There is a patch available that 
unifies it but it does not work well for the SDL client (which implements 
fog very differently).

So, I guess I have no strong opinion on whether the call should be moved 
into the GUI's mapview code.

jason




[Prev in Thread] Current Thread [Next in Thread]