civil-devel Mailing List for Civil

> Gareth: can you check the icon gfx/status.png. I think the CVS version is
> still the corrupt one that is 5 bytes big. I noticed when doing a fresh
> checkout at home. Here I have checked out an older version, so it works
> ok.

Gotta be quick here, I'll reply to the rest of you mail in the New Year...

I've checked and updated the CVS for the GXF folder and there's nothing
wrong (and no changes to) the status.png file. So I'm not sure what's going
on -- I can still load it happily in Photoshop, so I made a small change and
committed it to the CVS tree, although I don't know how sucessfully this
worked as the version number hasn't changed. I'll commit another version
when I get time next week and make sure that it's stuck, for now I can't
find much going on...

G

> Does this get through?

Ping...

One for the windows users that are having problems with CVS access since the
upgrades.

The changes to sourceforge mean you'll have to remove the .CVSPASS and
.knownhosts files from your home directory. I've had no CVS access since the
upgrades, and I tracked it down to this...

Of course I may be a little slow! ;-)

G

--

"Computer games don't affect kids. I mean if Pacman had affected us as
kids, we'd all be running around in a darkened room munching pills and
listening to repetitive music."

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0

iQA/AwUBOV4dgWtL7e1IGHY8EQIZpQCgzcgfbemfYvuXxMGsIrE4GVkLOIYAoPpn
ygxEeOudynAwxqeYKjo7PhlF
=S/8P
-----END PGP SIGNATURE-----

Hi all,

After a busy Christmas I'm again back for some more code. The recent
additions include showing info about a unit's leader/commander in the
panel. Simple stuff, but it had to be done. I did some other cleanups as
well to the panel code, so it now looks better too. A new screenshot is
uploaded.

Gareth: can you check the icon gfx/status.png. I think the CVS version is
still the corrupt one that is 5 bytes big. I noticed when doing a fresh
checkout at home. Here I have checked out an older version, so it works
ok.

Now for something completely different.

I was thinking that maybe we should add a tag to the scenario file that
describes the weapon types a unit has. This tag should refer to a section
with all weapon types in the scenario, such as:

<scenario>
    ...
    <weapons>
        <weapon type="rifle">
            <name>Regular rifle</name>
            <range>250</range>
            <damage>5</damage>
        </weapon>
        <weapon type="gun">
            <name>Artillery gun</name>
            <range>1800</range>
            <damage>25</damage>
        </weapon>		
    </weapons>

    ...

    <units>
        <unit...>
            <weapon primary="rifle">
            ...
        </unit>
        <unit...>
            <weapon primary="gun" secondary="rifle">
            ...
        </unit>
    </unit>

    ...
</scenario>

This should make it easy to add new rilfes, guns etc and easily adjust the
parameters for them. The "primary/secondary" is because some units may
have two types of weapons, such as artillery. Those may use guns
primarily, but rifles for defending against enemies that outflank the guns
(e.g. attack from behind). Maybe some kind of "amount" value needs to be
added too?

You might think that it is silly to constantly alter/add to the scenario
files, but I think it is a mandatory evil, as it is very hard to know what
info will eventually be needed. I hope nobody else will have to suffer for
the changes...
 
Anyway, a happy new year for those reading this next year (as seen today)!
I hope we have a productive new year and soon are able to release
something to the unsuspecting masses... :-)

	
--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Does this get through?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Hmm... I hadn't considered 'walking' though the triangles like that.
Not sure if that's more better or not, have to think about it; that
might well be part of an efficient approximation.  The terrain idea I
like, though, so here's an elaboration:

So, in addition to the ground itself, we have terrain features up to a 
particular height in each area; and terrain features have a degree of
opaquacity (is that a word?) that may be less than 100%.  The ground
itself is just another terrain layer that is 100% opaque.

Er, an example: A forest area might be a bit unlevel (we have a
formula for ground level, z=ax+by).  We have a 'stack' of terrain in
that area: up to/below ground level, 0% visibility.  From ground level
to, say 10m, 50% visibility.  Above that, 100% visibility (it's a
clear day).  Multiply out the visibility for all the areas LoS passes
through, and you can see if it's above some threshold.  You could do
stuff with this, too; eg, if total visibility to target is only 50%
you get less information than if it were 80%.

Nice thing about this is that not only does it solve the see from a
height problem, it accounts somewhat for visual cover from trees and
the like.  You can see a great distance from a hilltop, not quite so
far on open ground, and in a cornfield whole brigades might blunder
into bayonet range before seeing each other...

- mikee

On Thu, 21 Dec 2000 mik...@rc... wrote:

>
>Yeah, I am explicitly assuming in that that the earth is flat other
>than hills.  That might be what's missing - I'll have to consider that
>over the holiday, whether it has to do with seeing over the curvature
>of the earth.  Messy to get that exactly right, though; the hexes
>can't all be exactly hexes and fit together on a rounded surface, so
>it might be better to just toss in a fudge factor to compensate.

I don't think the fact that the earth is round will have any significance
for these kinds of distances. We're talking maybe 10km max edge to edge,
and that is a large map. For earth rounding to come into the picture we'd
need maybe 30km or more. I think that fact can be negelcted here

>That first equation was indeed for the distance; the square of the
>distance is the sum of the squares of the coordinate differences.  The
>idea (which I didn't express clearly) is that it saves some
>calculation to drop to 2D when figuring out which terrain the LoS
>passes through before figuring out if it hit any of it.  This trick
>doesn't work if the earth isn't flat...

No, it won't.

What about using some kind of Bresenham to figure out the exact *line* of
sight? Start from one point and go "towards" the other, one hex at a time,
always choosing the triangle in the current hex that best points towards
the target hex. This should roughly give us that the line passes through 2
triangles of each hex it passes through. The number of triangles could be
something like:

	( abs(x1-x2) + abs(y1-y2) ) * 2

So one km of visibility check would give us maybe 40 triangles (50m /
hex). Then when we have those it leaves us with two checks:

	1. altitude
	2. obstructing terrain (woods).

Could maybe be done like:

1. Traverse the triangles again and see wether one single triangle is
higher up the either of the end points => no visibility.

2. Do it again and check the terrain the triangles have. If a single one
of the triangles has terrain that can not be seen through and it is not
sufficiently below both endpoints (such as woods in a valley) => no
visibility.

These were just some ideas thrown out, spawned by your ideas. I'm no math
genius either. I've always hated to figure out where my OpenGL objects
*really* got painted after some transformations. Speaking of that, having
the hexes nicely triangulated means we also have ready scenarios for a 3D
world. Just take the coords we'll be calculating now and paint a triangle
with a texture on. Instant 3D. 

Tonight I'll be leaving civilization (and email) for a week, so I will not
be able to reply to anything for a while.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Yeah, I am explicitly assuming in that that the earth is flat other
than hills.  That might be what's missing - I'll have to consider that
over the holiday, whether it has to do with seeing over the curvature
of the earth.  Messy to get that exactly right, though; the hexes
can't all be exactly hexes and fit together on a rounded surface, so
it might be better to just toss in a fudge factor to compensate.

That first equation was indeed for the distance; the square of the
distance is the sum of the squares of the coordinate differences.  The
idea (which I didn't express clearly) is that it saves some
calculation to drop to 2D when figuring out which terrain the LoS
passes through before figuring out if it hit any of it.  This trick
doesn't work if the earth isn't flat...

- Mikee

> One thing that bothers me is that this scheme doesn't seem to handle
> altitude quite right; it understands vision being blocked by taller
> terrain, but you actualy see *less* far from a hilltop than on a
> perfectly flat plain, which doesn't seem right.  It's not at all clear
> to me what physical effect is being neglected there.  Any thoughts?

Ok, I'm no mathematician, and to be honest, I don't really understand much
of what you've just written (so if I'm stating the bleeding obvious, or have
made some infant mistake please forgive me!), but it seems to me that
there's an assumption that the world is flat.

Isn't there some modifier you need to apply to tail off LOS, or (trying to
think about this...) make the Z increment [minutely] as a function of
distance -- to show a round planet? I say this as I'm not sure if the
(x2-x1)^2+(y2-y1)^2+(z2-z1)^2 < C function is for range or to do just
that...

Obviously this isn't an exercise in explaining GCSE maths to a thick artist,
but as I can't decipher maths more complicated than multiplication and I see
no 'plain english' description that mentions this I figured it might have
something to do with elevated positions not having the same effect...

Maths? It's-all-greek-to-me-G

Well, the outline of it goes like this:

Get or derive from map altitude (z-coordinate) of (center of) each
hex.  For each vertex of a hex, average the altitudes of the three
hexes around it.  So now we break the map into triangles, 6 per hex,
formed by each side and the center.  One of the things we store for
each triangle is the formula for calculating ground height in it (eg,
z=ax+by).   All this is done at initialization time.

So, to determine LoS, we just have to take a vector from point
(x1,y1,z1) [z is maybe 6 feet off the ground?] to some other point
(x2,y2,z2).

If vector is too long, no good.  (x2-x1)^2+(y2-y1)^2+(z2-z1)^2 < C
Maybe implement this only as very first pass. :)  A relatively cheap
calculation that screens out most bad objects.

If vector is below ground level at any point, no good.  Figure out
which triangles it passes over.  We simplify this by dropping the Z
coordinate, gives us a nice regular flat 2D tesselation of isoceles
triangles (still have to think about how to do this, but shouldn't be
too bad).  Where does LoS vector (2D projection, Z dropped) intersect
sides of each it passes over?  If it's below ground at either
intersection point no LoS, otherwise we're good.

There are probably a jillion optimizations possible, we can see what
is necesary.  Precalculate, caching stationary objects, etc.

One thing that bothers me is that this scheme doesn't seem to handle
altitude quite right; it understands vision being blocked by taller
terrain, but you actualy see *less* far from a hilltop than on a
perfectly flat plain, which doesn't seem right.  It's not at all clear
to me what physical effect is being neglected there.  Any thoughts?

- mikee

Quoting Jan Ekholm <ch...@in...>:


> Thanks Gareth for what is shown so far. I had

I merely doodle. Jan does all the hard work!

>grand plans on creating a
> map with some rocks on it, but time has flown
away again. We'll see
> more
> stunning stuff once MikeS gets up to speed.

No doubt. Mike will be impressing us all with his
new toys! ;-)

> I think 2D is easier ti
> actually play, it may not look as "commercial"
as for instance Sid
> Meier's
> Gettysburg & co, but it is more playable. For
the next version we'll of
> course go full 3D. :-)

Well, commercial is one thing, but my main concern
is beating the open source competition. Something
I think we managing in most areas at present.

Gameplay is the key, and that's where we'll have
our work cut out... Anyway, until next year! Have
a good holiday...

G



-------------------------------------------------
This mail sent through UK Online webmail

On Thu, 21 Dec 2000 mik...@rc... wrote:

>
>Alas, the big block of free coding time I had expected this month
>didn't materialize, and I'll be away a week for Christmas anyway.
>Next month looks like I might start to be productive at this; I'm
>rearranging machines at home and work and may end up with a usable
>development system soon...

Sounds familiar. We got new IP:s for our 5 machines at home, got to
install a firewall and reorganize basically everything. 

>I do have a basic algorythm for Line-of-Sight thought out; decompose
>the hexes of the playfield into 6 triangles and the rest is
>straightforward geometry.  I suspect this will be fast enough to work
>it all out on the fly - the collision detection systems in console
>games are similar (harder, really) math on much slower hardware, and
>it's a heavily-studied problem.

That sounds very interesting. The idea of 6 tris sounds good once I think
about it a little bit. Do you have any more details as to how it should be
implemented? One idea that struck me what that once a calculation has been
done it could of course be cached. We could cache visibility from point A
to B, maybe a few thousands of these. Could save some calculations, or
could turn out to be a horrible idea. Anyway, I'm glad you have ideas as
to how this could be done, I've never done anything similar.

>The new screenshoots are lovely, btw.  My initial bias was that a 
>fully 2D depiction would look crude, but I was wrong - I'm surprised
>every time I go back to the screenshots how sharp it looks.

Thanks Gareth for what is shown so far. I had grand plans on creating a
map with some rocks on it, but time has flown away again. We'll see more
stunning stuff once MikeS gets up to speed. I think 2D is easier ti
actually play, it may not look as "commercial" as for instance Sid Meier's
Gettysburg & co, but it is more playable. For the next version we'll of
course go full 3D. :-) 

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Alas, the big block of free coding time I had expected this month
didn't materialize, and I'll be away a week for Christmas anyway.
Next month looks like I might start to be productive at this; I'm
rearranging machines at home and work and may end up with a usable
development system soon...

I do have a basic algorythm for Line-of-Sight thought out; decompose
the hexes of the playfield into 6 triangles and the rest is
straightforward geometry.  I suspect this will be fast enough to work
it all out on the fly - the collision detection systems in console
games are similar (harder, really) math on much slower hardware, and
it's a heavily-studied problem.

The new screenshoots are lovely, btw.  My initial bias was that a
fully 2D depiction would look crude, but I was wrong - I'm surprised
every time I go back to the screenshots how sharp it looks.

Hoping you all enjoy the holidays...


- mikee

Quoting Mike Szczerban <mik...@de...>:

> and thanks again, Gareth, for sending the CD.  Haven't received it yet,
> but
> I know it's going to be one of my favorite gifts!

I'm not sure why that's taken so long, it got posted about 7 days ago,
although I've been told that there was a postal strike for a couple of
days. That may have delayed it some what... Saying that though, I
think I may have posted it at the wrong time of year! ;-) You should
(at least) get it before New Year... (Here's hoping!)


> Gareth - is there anything you'd like me to take care of graphics-wise?

Well, I'm busy with water and trees. Personally I'd quite like to see
some buildings making an appearance, but basically you can take
anything from the current 'list of required GFX' (as featured on the
Civil website) and claim it as your own... I'm going to be up to my
ears trying to make what I've got work, so you're free to take what
you want!

> Let's
> hope to have a productive millennium!

Oh yes, except I'd quite like a fancy GFX tablet as well... Oh well,
you can't have everything!


G


-------------------------------------------------
This mail sent through UK Online webmail

Civilians,

Thanks for the holiday greetings.  I hope we all end up with more booty
than we can handle.  Myself, I hope to get some painting supplies, a
printer (and I hope, I hope ;) ) a Wacom Graphire digital tablet.  Oh yeah,
and thanks again, Gareth, for sending the CD.  Haven't received it yet, but
I know it's going to be one of my favorite gifts!


Regarding civil work, it looks like I may be the only one doing anything
for a while.. with no school and perhaps a fancy drawing tablet, I hope I
can pump out some graphics and stuff.  

Gareth - is there anything you'd like me to take care of graphics-wise? 
I'd do the muds, I think, for terrains and maybe some icons?  Not sure
which ones you'd like to take for yourself and what ideas you have on
them.  If you've got some time to spell that out a little clearer for me,
it would be much appreciated!

Oh yes, Civil actually looks like a game.  I'm so proud, really, to be a
part of it.  Thanks for all your help in getting me indoctrinated.  Let's
hope to have a productive millennium!

Anyway, I hope we all have a great time this Christmas and New Year's. 
Happy Holidays!


Mike


-- 
  -------------------------
Mike Szczerban | m...@sz...
  -------------------------
--

On Thu, 21 Dec 2000, Gareth Noyce wrote:

>Just a quick note to wish you all a very happy Xmas and an even better
>New Year. I've had a lot of fun working with you all this year, so
>here's hoping 2001 is even more productive!

I'll be lazy and just second Gareth's greetings! 

I'm also off to a place with no computers, no mail, nothing. Just too much
food and other Christmas stuff. Oh, well, maybe it's good practice or
something... :-)

We have a serious disk crash on our company server yesterday, so I've been
a little bit busy rebuilding it and restoring from backups. It's our own
fault, as we got a RAID controller a month or so ago, but never had the
time to install it! Had it been installed the whole incident would just
have been an entry in the system log. Now the RAID system has a few spare
disks and we've learned a lesson. Luckily only the system disk failed, all
our work (CVS) was on another disk, and also backed up.

Oh, btw, the local telco guy installed the needed DSL wiring today. Later
today another guy should come and install the DSL router. I hope the cable
distances are not too big for DSL to work at all, so I may still face even
more grief. But if it works I'll have DSL. Guess who's already anxious to
get back home from celebrating Christmas... :-) If it all works I should
be able to be more productive next year, as working over a modem is really
not that fun.

Anyway, have a nice Christmas! Let's hope Santa brings lots of stuff with
big manuals and buttons that either generate sound, video or both. :-)

	Chakie

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Hi all,

Just a quick note to wish you all a very happy Xmas and an even better
New Year. I've had a lot of fun working with you all this year, so
here's hoping 2001 is even more productive!

I'm off to flooded Devon for a holiday this year, so I'll be offline
from Friday night until the New Year. I hope you all have a great time
with family and friends, and I'll see you all in the next millenium!

Ho Ho Ho

G

-------------------------------------------------
This mail sent through UK Online webmail

Hi all,


Sorry for the silence the past few days, I've been busy doing some promised
evening work hacking out a website template for some friends...

Jan: I've got Civil running fullscreen on my laptop and it looks fscking
ACE! I'm sooo happy; I'd hug you if I was on the same continent! Thank you
/very/ much for that particular update, it makes /all/ the difference. :)
(WooHoo! We've got ourselves a game!)

I've done a highlight for the units, although I've kept it rough and ready
since we'll probably lose it in favour of one of the 'animated' ideas --
unfortunately sourceforge is down so I can't commit it... Again, thanks for
the code update Jan! We'll have to discuss our chosen animation route for
highlighting (I'm voting for the units colour cycling...)

Just so everyone is aware: I'm back to playing with my water effects (for
the terrains) and trees in general. I seriously doubt I'll have a commit
ready for these until mid->late January, but I am working, never fear.
Tessellating water is a touch tricky tho! :-\

Hope you are all well and not too stressed out by the Xmas panic!

G

--

"Computer games don't affect kids. I mean if Pacman had affected us as
kids, we'd all be running around in a darkened room munching pills and
listening to repetitive music."

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0

iQA/AwUBOV4dgWtL7e1IGHY8EQIZpQCgzcgfbemfYvuXxMGsIrE4GVkLOIYAoPpn
ygxEeOudynAwxqeYKjo7PhlF
=S/8P
-----END PGP SIGNATURE-----

There's a new screenshot on the homepage. Shows some simple info for a
unit in the panel, as well as uses the new smooth unit icons. The info in
the panel is just "proof of concept", and will be changed to some other
format if needed when we agree on it.

I've done some quite big changes internally, so I haven't been entirely
lazy, and it is very much cleaner at some places. The next task is to
start handling the orders for units. I have that part figured out quite
far, so it's more a question of putting ideas to code that coming up with
the ideas in the first place. :-)

Anyway, I'm not dead, but Christmas has been quite heavy on my free time.
Ok, I like all the fun stuff I hope I'll get, but the preparations
sometimes are just a little bit too much. And Opera 4.0b4 doesn't seem to
work with Advogato (I can log in, but it "forgets" it immediately), so I
haven't updated that page for a while. I think I will purchase Opera, btw.
I think it's really good!

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Jan Ekholm wrote:
> 
> Well,
> 
> I put in a feature for really simple animation into Civil. It is now
> possible to easily do simple animations, such as flash colors etc. The
> drawback is that I do no "background restoring", so the images that are
> animated need to be exactly the same size, as otherwise garbage from other
> frames will be left behind. This approach should work for cursors, markers
> and so on. Not a lot of code, and not too much features either.
> 
> As for the highlighting, I vote for the same as everyone else!


You know, as we are having a rather hard time, it seems, in figuring out
which one is best, maybe it should be an option for the user to choose? 
Not necessarily right now, but sometime later.  Just a suggestion.

-- 
  -------------------------
Mike Szczerban | m...@sz...
  -------------------------
--

Well,

I put in a feature for really simple animation into Civil. It is now
possible to easily do simple animations, such as flash colors etc. The
drawback is that I do no "background restoring", so the images that are
animated need to be exactly the same size, as otherwise garbage from other
frames will be left behind. This approach should work for cursors, markers
and so on. Not a lot of code, and not too much features either.

As for the highlighting, I vote for the same as everyone else!

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

4 is fine for me!

Gareth Noyce wrote:
> 
> Quoting Jan Ekholm <ch...@in...>:
> 
> > It seems that nobody can say exactly what is the best way to go. MikeS
> > likes three of the ideas, and I can't say that any of them would be the
> > best one either. If I had to choose three I'd leave out 1, as the black
> > somehow is a bit malplaced there. 2,3 and 4 all have merits. 2 is
> > probably
> > the easiest one to spot, while 3 and 4 look artistically better to me.
> 
> Yes, I don't really like 1, the black is a tad too much. 2 is ok, but
> I have my reservations as to how well it will work when placed on the
> range of terrains.
> 
> In my mind we have the following colours in the terrains:
> 
> Blues, Greens, Greys/Whites, Yellow->Browns and this is not including
> any of the various buildings that will be springing up. Choosing a
> colour that will provide high contrast over these is a nightmare. I'm
> almost tempted to suggest XOR ing a mask over the terrains to try and
> effect a known highlight...
> 
> However, I digress...
> 
> We only really need to know which type of highlight to use right now,
> and I'm in agreement with you Jan; we don't need animation at this
> stage. Ignore it for now, as you have better things to do. I'd rather
> see the engine going than a flashy unit. This is something to be
> tidied at the end...
> 
> My gut feeling is to go with number 4. Obviously producing a tidy
> version and spending some time working on the correct colour to use.
> However, this is simple to change as more terrains are added. In fact
> I expect it to change as I can only predict the palettes that I will
> be using. MikeS may well use some I wasn't expecting...
> 
> > Yep, there will be some water too (i.e. blue), but mostly green and
> > brown,
> > I think?
> 
> Pretty much.
> 
> > I think this should work. Maybe it really isn't too much work. I could
> > stick the animation stuff into the class Playfield, and have the main
> > event_loop() call it when needed... Argh, ok, I'll think about it.
> 
> At this stage I'm really not to worried. Certainly it's something you
> could add, but perhaps it should be left for later. The artists' job
> is to get these things working regardless! ;-)
> 
> I'm placing my vote firmly behind number 4. If anyone else would like
> to throw their dice in I can make a more tidy version of the winner.
> 
> G
> 
> -------------------------------------------------
> This mail sent through UK Online webmail
> _______________________________________________
> Civil-devel mailing list
> Civ...@li...
> http://lists.sourceforge.net/mailman/listinfo/civil-devel

-- 
  -------------------------
Mike Szczerban | m...@sz...
  -------------------------
--

Quoting Jan Ekholm <ch...@in...>:

> It seems that nobody can say exactly what is the best way to go. MikeS
> likes three of the ideas, and I can't say that any of them would be the
> best one either. If I had to choose three I'd leave out 1, as the black
> somehow is a bit malplaced there. 2,3 and 4 all have merits. 2 is
> probably
> the easiest one to spot, while 3 and 4 look artistically better to me.


Yes, I don't really like 1, the black is a tad too much. 2 is ok, but
I have my reservations as to how well it will work when placed on the
range of terrains.

In my mind we have the following colours in the terrains:

Blues, Greens, Greys/Whites, Yellow->Browns and this is not including
any of the various buildings that will be springing up. Choosing a
colour that will provide high contrast over these is a nightmare. I'm
almost tempted to suggest XOR ing a mask over the terrains to try and
effect a known highlight...

However, I digress...

We only really need to know which type of highlight to use right now,
and I'm in agreement with you Jan; we don't need animation at this
stage. Ignore it for now, as you have better things to do. I'd rather
see the engine going than a flashy unit. This is something to be
tidied at the end...

My gut feeling is to go with number 4. Obviously producing a tidy
version and spending some time working on the correct colour to use.
However, this is simple to change as more terrains are added. In fact
I expect it to change as I can only predict the palettes that I will
be using. MikeS may well use some I wasn't expecting...


> Yep, there will be some water too (i.e. blue), but mostly green and
> brown,
> I think?

Pretty much.


> I think this should work. Maybe it really isn't too much work. I could
> stick the animation stuff into the class Playfield, and have the main
> event_loop() call it when needed... Argh, ok, I'll think about it.

At this stage I'm really not to worried. Certainly it's something you
could add, but perhaps it should be left for later. The artists' job
is to get these things working regardless! ;-)

I'm placing my vote firmly behind number 4. If anyone else would like
to throw their dice in I can make a more tidy version of the winner.

G


-------------------------------------------------
This mail sent through UK Online webmail

Quoting Mike Szczerban <mik...@de...>:

> I like 1, 3 and 4 best.  I'd prefer more of a green neon as a highlight
> as

Ok, the colour is an issue. I've purposefully used a rude colour as
it's the only real way to assure it contrasts. Initially I was using
green, but it's hard to see over the grass and blends into the sand...

Bearing in mind we've yet to add trees (etc.) and I think it's best to
use a colour which we know is not going to be used in any of the
terrains. This leaves the pastel range and the rude psyhedelic range...

> opposed to the bright cyan - also a little larger than the unit (the
> circle).  Out of 1, 3, and 4, I like 1 the best, as I think it best
> delineates that "hey! this unit's selected!" because of the fill, the
> outline i think is necessary as well.

I'm not sure about the circle being larger than the unit. It looks a
bit pants...




-------------------------------------------------
This mail sent through UK Online webmail

On Wed, 13 Dec 2000, The Corruptor wrote:

>see: http://civil.sourceforge.net/incoming/hi_uni.png for the mock I've been
>wittering on about. Please note it's not a tidy mock, the circles and
>strokes are not exact, just a quick hack to approximate.

It seems that nobody can say exactly what is the best way to go. MikeS
likes three of the ideas, and I can't say that any of them would be the
best one either. If I had to choose three I'd leave out 1, as the black
somehow is a bit malplaced there. 2,3 and 4 all have merits. 2 is probably
the easiest one to spot, while 3 and 4 look artistically better to me.

>Personally -- bearing in mind that we have more terrains not shown, all with
>greatly differing contrasts and hues -- I believe that number 4 (shown) is
>possibly the best /non-animated/ way to go. Purely as we have strong
>contrast/highlighting by using a masked stroke. Of course, no.1 also
>qualifies for these reasons...

Yep, there will be some water too (i.e. blue), but mostly green and brown,
I think?

>As a thought for the future: were the engine to have animation (version 2 or
>sooner...) a simple colour cycle of the unit *itself* would look excellent.
>(This wouldn't require more effort from a GFX perspective than a quick
>boot-up of my trusted old Amiga and some exports of the palettes...)

Animation is not hard to do, I think. I'm polling for time all the time
anyway, so it's just to sneak in code like:

	# has more than "interval" milliseconds passed?
	if currentMilliseconds() - lastAnimation >= interval:
		# yep, store new time for "last" animation
		lastAnimation = currentMilliseconds()

		# animate and repaint
		updateAnimations()

Updatable things should just register themselves in some central place
and provide a method animate() so that the following could be written:

	def updateAnimations():
		# get a list of all updatable shapes
		shapes = getUpdatable()

		# loop over all updatable shapes
		for shape in shapes:
			# animate
			shape.animate()

		# did we do anything at all?
		if len ( shapes ) > 0:
			# at least one shape was animated	
			repaint()

I think this should work. Maybe it really isn't too much work. I could
stick the animation stuff into the class Playfield, and have the main
event_loop() call it when needed... Argh, ok, I'll think about it. :-)

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams