Re: Bug #24362,Protruding graphics at edge of map

Contribute, display and discuss art and tilesets for use in Freeciv here.
Post Reply
User avatar
GriffonSpade
Elite
Posts: 578
Joined: Mon Apr 29, 2013 4:41 pm

Re: Bug #24362,Protruding graphics at edge of map

Post by GriffonSpade »

https://gna.org/bugs/?24362
The part of the city beyond the line of the edge of the map is darker (fog?). It would be nice if it weren't.

I suspect the Hills that protrude have a similar problem.
Hmmm, I can't seem to replicate this issue with A6B. At least not in 2.5. It's something to do with the fog/darkness style in amplio2.

In AmplioHexBig, protrusions from fogged tiles stay fogged, protrusions from visible tiles stay visible until they hit unexplored darkness, which isn't drawn over out-of-bounds tiles at all.

Amplio2 is the opposite. Protrusions from fogged tiles unfog, protrusions are fogged over fogged/out-of-bounds tiles, and blackened over unknown tiles.

In both cases, protruding flags and occupied sprites are treated the same as city protrusions.
In both cases, population counters are notably drawn over top the darkness.

So how does iso-hex's fog/darkness style maintain fidelity of tiles' protrusions' fog? The oddest thing is that Amplio2's darkness is only supposed to be drawn over layer 0, so why is it being drawn over things from layer 1/2 (from other tiles of course, darkness doesn't show anything about the tile it's on, after all)? Is it because it's also drawing fog? Anyhow, spent 4 hours trying to think of a way to fix this via tileset, but there really isn't without sacrificing some aesthetics.

So basically it needs these things done:
Fog not drawn over out-of-bounds tiles.
Fog and Darkness drawn separately.
Fog drawn same way as darkness, but on its own.
Darkness drawn down over appropriate layer, instead of over everything.
Fog drawn underneath sprites from downward tiles, but over all sprites on its own tile. (Negates need for first item)

Protrusions from fogged tiles would still be unfogged over unfogged tiles, but I don't see how to fix that without issues. (Even if you added fog over it, it would accumulate in a band where there is already fog blending spilling over into that tile) It'd certainly take some voodoo to make it work perfectly.

----

I kinda think we might need some kind of special rule to tell tiles how to interact with unknown/out-of-bounds areas too. Hills and Mountains probably shouldn't be connecting to them, while at the same time oceans should see them as other oceans, not land. Maybe allow each terrain to set what match_type they see unknown/out-of-bounds tiles as(edge_match_type?). (So mountains might see them as flat terrain and not connect, but oceans would see them as other oceans and stay deep, and tundra would see them as tundra and not draw grass around the edge)
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: Bug #24362,Protruding graphics at edge of map

Post by cazfi »

GriffonSpade wrote:I kinda think we might need some kind of special rule to tell tiles how to interact with unknown/out-of-bounds areas too. Hills and Mountains probably shouldn't be connecting to them, while at the same time oceans should see them as other oceans, not land. Maybe allow each terrain to set what match_type they see unknown/out-of-bounds tiles as(edge_match_type?). (So mountains might see them as flat terrain and not connect, but oceans would see them as other oceans and stay deep, and tundra would see them as tundra and not draw grass around the edge)
That's more of a multiplayer information leakage question than tileset one. Old versions of freeciv server used to send client information about terrains just outside the seen ones so that it could draw seen tiles accordingly (knowing what it connects to). However, this allowed cheating clients to show users more map than they are supposed to know.
User avatar
GriffonSpade
Elite
Posts: 578
Joined: Mon Apr 29, 2013 4:41 pm

Re: Bug #24362,Protruding graphics at edge of map

Post by GriffonSpade »

cazfi wrote:
GriffonSpade wrote:I kinda think we might need some kind of special rule to tell tiles how to interact with unknown/out-of-bounds areas too. Hills and Mountains probably shouldn't be connecting to them, while at the same time oceans should see them as other oceans, not land. Maybe allow each terrain to set what match_type they see unknown/out-of-bounds tiles as(edge_match_type?). (So mountains might see them as flat terrain and not connect, but oceans would see them as other oceans and stay deep, and tundra would see them as tundra and not draw grass around the edge)
That's more of a multiplayer information leakage question than tileset one. Old versions of freeciv server used to send client information about terrains just outside the seen ones so that it could draw seen tiles accordingly (knowing what it connects to). However, this allowed cheating clients to show users more map than they are supposed to know.
Erm...? I'm uncertain how that's related? The client has to handle how to match known tiles with unknown/out-of-bounds tiles. Currently it ALWAYS matches(it seems like it always considers the unknown tiles to be of the tile's own match_type), resulting in hills & mountains that always match with the unknown/out-of-bounds tiles. Reversing that would probably mess up oceans or something. I don't mean that the client should be fetching what the unknown/out-of-bounds tiles are, but each tile simply treating these unknown/out-of-bounds tiles as being one of the match types. (Or no match type if left blank).

Examples:
Mountains are treating unknown tiles as mountains match type
Oceans are treating them as ocean match type
Forests are treating them as forest match type
etc...(for each layer too, of course)

It would allow mountains to not try to match with unknown tiles; instead of ALWAYS matching with unknown tiles it could be changed so that it NEVER matches with unknown tiles. (of course there is the ability for a tile to match with multiple different match types, so being able to declare which one it sees the unknown tiles as would be required)
Post Reply