[CF-Devel] Fog Of War code in Gtk
crossfire-devel at archives.real-time.com
crossfire-devel at archives.real-time.com
Thu May 27 14:23:30 CDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well if i were a general of an army, let's say invading some petrol rich
country (just supposition that's not real life) i would to appreciate to have
a fog of war instead of black boxes :)
(just a useless note because games are not so far from reality. The only
difference is well... it's not reality)
Le jeudi 27 Mai 2004 13:52, Palfy Tamas a écrit :
>
I am surprised no one mentioned just blacking out the tiles covered by fog
>
= of war. The more I think of this the more I like the idea. It would be
>
ea= sier. Fog of war in a stragety game is a convienient tool but in a
>
adventu= re/RPG maybe it is too much assistance. If you can't remember
>
what's aroun=
Now _this_ I really can't understand. Why on Earth would it be "too much
assistance"? Have you _played_ this game? Well, as for my experiences,
peepo of the human race overall is a visal type entity (_man_, what words
am I using), and we should not only accept it, but appreciate it as well.
Playing via games is _not_ like acting in reality. No. If I were there in
the dungeon I may consider move slowly and put significant energy to make
sure I can remember things. But a game is different. As for me, I play it
for fun, not for being in some reality-simulation. We move that way - we
won't be able to have an answer for such aspersions like "computer games
are good for nothin' shit for children who want to escape reality". To
prevent that, games should be more exciting, and yes, less realistic. And
there are tools to accomplish that, tools, that makes the players life
better and easier, while not breaking the game.
Fog of war is such a tool, it logically represents the _characters_
possible memory - which is _definietly_ shouldn't be the same as the
_players_ memory.
(Not to mention, in reality, the worlds features are unique wherever you
go, while in the game, the walls and the floor etc. are just the same as
anywhere else (almost), so it's not a bad idea helping peepo in their
orientation.)
>
d the corner then you better take another look...
>
>
> =
>
>
>
> --Boundary-02=3D_+nNtAIl4ANWMXXT
>
> Content-Type: text/plain;
>
> charset=3D"iso-8859-1"
>
> Content-Transfer-Encoding: quoted-printable
>
> Content-Disposition: inline
>
> =
>
>
>
> Just put an example with grey pictures detection. Work quite well.
>
> Please note the base dungeon floor is NOT grey but made of light yellow
>
> a=
>
>
nd =
>
>
> dark green :). I walked a bit in the game seems the detection algorithm
>
> d=
>
>
id =
>
>
> not fail anywhere!!
>
> =
>
>
>
> I choose to move grey picture to the light blue. Give better results
>
> than=
>
>
=
>
>
> yellow, and i thing nobody wants magenta or cyan :)
>
>
http://users.skynet.be/tchize/brol/fow11.png
>
> =
>
>
>
> Le mardi 25 Mai 2004 08:38, Mark Wedel a =E9crit :
>
>
>
> Rick Tanner wrote:
>
> > The blur effect, while a clever approach, I don't think my eyes could
>
> > withstand that effect for too long! ;-)
>
>
>
> =
>
>
>
> I agree, and the minor blurs are not that different.
>
> =
>
>
>
> Now the quick hack I did to make it grey was mostly because before
>
> then=
>
>
,
>
>
> they were shown as if it was 50% dark. So for maps with darkness, it
>
> wa=
>
>
s
>
>
> very hard to tell if in fact the space was just dark, or out of view.
>
> =
>
>
>
> I do like the faded look. The problem which is very apparant is that
>
> i=
>
>
t
>
>
> doesn't work very well for objects that are only grey (looking at sample
>
> =
>
>
2,
>
>
> there is only a very minor difference noticable between the visible
>
> cobblestones under the grate, and the blocked ones behind it/in the
>
> corners).
>
> =
>
>
>
> Minor enough that without having that visible one as a reference, for
>
> m=
>
>
e at
>
>
> least, I wouldn't be able to tell you those others were blocked.
>
> =
>
>
>
> Which probably brings up the issue that no method will work perfectly
>
> f=
>
>
or
>
>
> everything. The current method works OK for some images, and not good
>
> fo=
>
>
r
>
>
> others. I wonder if some logic to try and figure out how 'colorful' the
>
> image is could be done, and for images that are mostly grey/black, do an
>
> intensity reduction.
>
> =
>
>
>
> In terms of votes, I personally like #1 or #2 - hard to tell exactly
>
> ho=
>
>
w
>
>
> they are different, since #1 was done on a different map.
>
> =
>
>
>
> In terms of removing objects, this is harder. It wouldn't be hard to
>
> j=
>
>
ust
>
>
> draw the bottom most image, but that probably isn't write - things like
>
> statues, grates, walls on top of other terrain, etc, would all
>
> disappear=
>
>
. =
>
>
> And you can't really get much more intelligent logic, because the client
>
> doesn't necessarily know that image X is a wall and Y is a dagger, and
>
> i=
>
>
t
>
>
> should draw X and not Y.
>
> =
>
>
>
> =
>
>
>
> =
>
>
>
> _______________________________________________
>
> crossfire-devel mailing list
>
>
crossfire-devel at lists.real-time.com
>
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
> =
>
>
>
> -- =
>
>
>
> --
>
> Tchize (David Delbecq)
>
>
tchize at myrealbox.com
>
> Public PGP KEY FINGERPRINT:
>
> F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C
>
> Public PGP KEY location:
>
>
http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
>
> =
>
>
>
> --Boundary-02=3D_+nNtAIl4ANWMXXT
>
> Content-Type: application/pgp-signature
>
> Content-Description: signature
>
> =
>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> =
>
>
>
> iD8DBQBAtNn+HHGOa1Q2wXwRAjhIAKDWfeFAXNdcB/1SLhDZKSAW8lDsHQCgxMXw
>
> iE35FxBo0h2fBWijgAZsRWE=0C0b
>
> -----END PGP SIGNATURE-----
>
> =
>
>
>
> --Boundary-02=3D_+nNtAIl4ANWMXXT--
>
> =
>
>
>
> =
>
>
>
> =
>
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
_______________________________________________
crossfire-devel mailing list
crossfire-devel at lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
- --
- --
David Delbecq
d.delbecq at laposte.net
Public PGP KEY FINGERPRINT:
F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAtkA3HHGOa1Q2wXwRAhANAJ0YGTvxyn1q7xLOUXfMiMfguH6PPACg3kOb
/cmcH2/TwUHOxHj14CUlsc0=
=SMXI
-----END PGP SIGNATURE-----
_______________________________________________
crossfire-devel mailing list
crossfire-devel at lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
More information about the crossfire
mailing list