Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] Re: the directional system
Home

[Freeciv-Dev] Re: the directional system

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: jdorje@xxxxxxxxxxxxxxxxxxxxx, "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx, Thue Janus Kristensen <thue@xxxxxxx>
Subject: [Freeciv-Dev] Re: the directional system
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Mon, 10 Sep 2001 01:13:47 -0400

At 10:08 AM 01/09/09 +0200, Raimar Falke wrote:
>On Sun, Sep 09, 2001 at 03:39:51AM -0400, Jason Dorje Short wrote:
>> Raimar Falke wrote:
>> 
>> > I still don't understand it. DIR_DX2 is only used in one method. Why
>> > not just convert this and be fine (at least as an immediate step) with
>> > one system. Why to switch all over to the DIR_DX2 system? Why is the
>> > DIR_DX2 inferior to the DIR_DX system (not the naming but the
>> > ordering)?
>> 
>> The problem is the DIR_DX2 "rotational" system is superior to the DIR_DX
>> "vertical" system: 
>
>> easier to code with
>
>This should be a non issue if you use "enum direction8" and iterate
>macros.

Only if you are taking the complete set, or known absolute directions
which is what those two constructs are there for.

> About
>which algorithms do we speak here?

I'm happy to see you recognize that there might be other things. It is
a good first step, at least.

Try to write an algorithm to move a unit in direction "dir" 50% of the 
time and in the next compass direction forwards or backwards 25% each. 

BTW, in the "rotation" system these directions are dir+1 and dir-1,
so this is stepping (dir + (myrand(4)*2-3)/2).

Try to write dir_ok and straightest_direction using the maximal amount
of common code. Note that dir_ok is a one-line function in corecleanup
that should be obvious if you worked through the preceding example.

The asteroid hits in mapgen "splash" 50% in the forward direction and
25% to either side as a way of introducing asymmetries in the buildup
of landmass.

Take a look at new mapgen river code, where you need to block various
neighbouring directions to make sure your river doesn't loop around
and join up with itself.

If you were reviewing these patches, you should be familiar with the
examples of what is being talked about here.

Note, the common element in these examples is that directions are
relative, not absolute. When you get into MAPSTEP and topologies
where you need to deal with local coordinate walks, functions that
move you right or left, rather than east or west will be much more
useful. And Direction8 enums won't be of much use.

>And I still don't understand why you two find the "rotational" better.

You aren't looking very hard.

If you never look beyond the current code, it will never improve, and
admittedly it will never need to if you don't make any changes except
for reformatting spacing, renaming things, or trivial code replacements.

To actually go anywhere with the freeciv codebase, you need to first
cleanup and standardize its existing code, then start reimplementing
interfaces to more general or workable forms. Once you have things
standard and modular, changing implementations radically to do new
things like handle extended topologies is really minor work.

Rotational as opposed to array ordering is just one of those enabling
interfaces that actually allows you to do things that the current
direction system makes incomprehensibly complex. If there was some key
advantage to the array ordering I could see a reason to want to discuss 
it, but there isn't - it is basically a dead-end like so many parts of
the codebase and just drags the development down.

So please work through the examples above. If you do this, you should 
hopefully gain the necessary understanding.

>Exactly. And even at this one place it provides no advantage. Thue?

I'm surprised he managed to get it in. But I suspect when he asked
me to put more of this stuff into the mapgen updates before 12.0 he
knew this would effectively block any map improvements until more
of his fixes were adopted :-). 

>       Raimar
>-- 

Cheers,
RossW
=====




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