Been busy, just had a realization that you'll need unmouthed shore tiles to properly test.
Along with this realization, I remembered the other thing: shouldn't irrigation be drawn as a river?
That is to say, with its own river mouths in addition to the way it is currently drawn.
It would look rather off for a tile to be irrigated from a lake or ocean, but there be a strip of shore between the source and irrigation.
It's not an issue on isometrically blended tiles(where you can simply draw out-of-bounds), but on unblended sides (up, down, left, right) this is an issue.
[images deleted]
Art required for freeciv proper (2.6)
- GriffonSpade
- Elite
- Posts: 578
- Joined: Mon Apr 29, 2013 4:41 pm
Re: Art required for freeciv proper (2.6)
Last edited by GriffonSpade on Wed Feb 14, 2018 2:44 pm, edited 1 time in total.
Re: Art required for freeciv proper (2.6)
I recommend Windows users to test with the 2.6-alpha1 build: http://forum.freeciv.org/f/viewtopic.ph ... 5&start=20cazfi wrote:As for the offsets stuff, we're slowly approaching point where we can freeze S2_6 datafile formats. BUT we've not done that yet, so now would be the time for making any simple requests, like adding those offsets was, regarding the formats. We are unlikely to add any big changes to our lists that would postpone the freeze, but I'm interested of any low-hanging fruits to improve tileset support while waiting those remaining other issues to get solved. Once the formats have been frozen, any new changes will need to wait freeciv-3.0.
While it's only a alpha of freeciv-2.6, it's probably the last windows installer build before the datafile formats freeze, and thus you last opportunity to test (and comment) the formats before they get frozen.
New goto line drawing
One of the new features in 2.6 is new drawing of the goto line (code patch, open art ticket). This will need new graphics in all tilesets.
I've done some awful programmer-art to illustrate what this is about.
(tileset files for Amplio2 in trunk r30502: terrain1.png, terrain1.spec; I haven't checked but these might be usable with the 2.6 Windows test build mentioned above; as shipped, current code uses some other existing sprites as placeholders, not these ones)
There are four new sprites:
Some other considerations:
I've done some awful programmer-art to illustrate what this is about.
(tileset files for Amplio2 in trunk r30502: terrain1.png, terrain1.spec; I haven't checked but these might be usable with the 2.6 Windows test build mentioned above; as shipped, current code uses some other existing sprites as placeholders, not these ones)
There are four new sprites:
- "path.step" is drawn in the middle of a path where a unit will end its turn (here: solid cyan diamonds)
- "path.exhausted_mp" is drawn at the end of the path (under the cursor) if and only if the unit will have no movement points left when it finishes its journey (here: hollow diamond with red/blue fill)
- "path.normal" is instead drawn at the end of the path if the unit will have movement left (here: hollow diamond)
- "path.waypoint" is drawn whenever the player sets an explicit waypoint that the path must go through (here: little cyan flag)
Some other considerations:
- You can't have different sprites for different directions, so sprites need to be omnidirectional (can't use an arrowhead, for instance)
- Goto line drawing is still a solid coloured line, not sprites; colour is under tileset control but is conventionally cyan
-
- Posts: 1
- Joined: Sun Nov 29, 2015 8:00 am
Re: Art required for freeciv proper (2.6)
thanks a lot for the link and the useful data...
Graduated from Soran University with First Class Degree with Honours in Computer Science.
Re: Art required for freeciv proper (2.6)
Patch to fix this has been made, but cannot be committed because of the fact that supplied isophex tileset doesn't have required sprites and would fail to load with the fix in place: patch #6832.cazfi wrote:Do you happen to have art that could be used for testing this while developing it? I don't promise it to 2.6, but we'll check the feasibility. patch #6351GriffonSpade wrote:On the tileset side, the only thing that comes to mind is river outlets on the flat(unblended) sides of a hex tileset. I doubt it's an inconsequential change if it hasn't been done yet by this point, though.
Re: Art required for freeciv proper (2.6)
Code-side support for hex river outlets fix now committed to TRUNK, S2_6, and even to S2_5 (considering it a bug that these sprites were not properly handled). Those "new" sprites are left optional for now (obviously the code fix does nothing if the sprites are missing) to avoid breaking tilesets that have grown to expect the bug. Plan is to make them mandatory in 3.0.
Re: New goto line drawing
I've gone with more-or-less the concept I posted previously. We now have graphics for all supplied tilesets that should be adequate.JTN wrote:One of the new features in 2.6 is new drawing of the goto line (code patch, open art ticket). This will need new graphics in all tilesets.
Re: Art required for freeciv proper (2.6)
Maybe it's a bit late, but shouldn't the circled number be drawn after (ie over) the goto line itself ?
- Attachments
-
- freeciv.png (36.69 KiB) Viewed 14291 times
Re: Art required for freeciv proper (2.6)
It's not too late to file a bug report: http://gna.org/bugs/?func=additem&group=freecivlouis94 wrote:Maybe it's a bit late, but shouldn't the circled number be drawn after (ie over) the goto line itself ?
Re: Art required for freeciv proper (2.6)
Done : https://gna.org/bugs/index.php?24373cazfi wrote:It's not too late to file a bug report: http://gna.org/bugs/?func=additem&group=freecivlouis94 wrote:Maybe it's a bit late, but shouldn't the circled number be drawn after (ie over) the goto line itself ?