Currently Online

Latest Posts

Topic: Make Frisian buildings smaller

PkK
Joined: 2012-01-06, 12:19
Posts: 187
Ranking
Widelands-Forum-Junkie
Posted at: 2019-05-19, 17:16

IMO, the Frisian building look far too big relative to buildings from other tribes. Looking e.g. at https://wl.widelands.org/wlmedia/wlscreens/screens/Build%2020/Complete_World.jpg even mid-sized Frisian buildings are taller than the Colosseum and the Barbarian tower, two buildings that were among the tallest before the addition of the Frisians. It just looks wrong next to each other.


Top Quote
kaputtnik
Avatar
Joined: 2013-02-18, 20:48
Posts: 1765
Ranking
One Elder of Players
Location: Germany
Posted at: 2019-05-19, 19:02

+1


Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 739
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-05-19, 19:27

yep scaling them down a bit would be nice. maybe 90 % of current size?


Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 221
Ranking
Widelands-Forum-Junkie
Location: Earth
Posted at: 2019-05-19, 21:19

hessenfarmer wrote:

yep scaling them down a bit would be nice. maybe 90 % of current size?

It's rather 50% maybe even more. Just look at the frisian's port or HQ, they are almost 4 times bigger than their counterparts.


Top Quote
WorldSavior
Avatar
Joined: 2016-10-15, 04:10
Posts: 1260
Ranking
One Elder of Players
Location: GER
Posted at: 2019-05-19, 21:30

Or try 80% or something like this? In general I don't like it that buildings can cover so much things which are behind them, so one cannot see some stuff.


“It's a threat to our planet to believe that someone else will save it.” - Robert Swan

Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 739
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-05-19, 21:45

WorldSavior wrote:

Or try 80% or something like this? In general I don't like it that buildings can cover so much things which are behind them, so one cannot see some stuff.

80% might be ok as well. However as you said I think it is a matter of trial and error. Unfortunately I don't know if we can scale them just by entering a scaling value or if we have to edit all the blender files. If the latter we should first try with one or two representative buildings. Cause I assume this would be hell of work.


Top Quote
king_of_nowhere
Avatar
Joined: 2014-09-15, 18:35
Posts: 1430
Ranking
One Elder of Players
Posted at: 2019-05-20, 02:34

I agree, not much for model appearence but because it's difficult to see adjacent spaces. And I agree to try 80% first, and get there by trial and error.

Allthough I feel sorry for whoever designed them, he put so much effort into details that won't be appreciable anymore.

EDIT: also, the broadsword icon in the training camps should be made darker, because as it is, it is hard to tell if there are broadswords inside or not. Not sure if I should open a new thread for it or not.

Edited: 2019-05-20, 02:39

Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3057
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-05-20, 09:32

Let's get https://code.launchpad.net/~widelands-dev/widelands/list-directories-in-cpp/+merge/366614 reviewed so that I can finish implementing spritesheets. This way, Nordfriese will not have to export the renders twice, because that is time consuming work.


Busy indexing nil values

Top Quote
Nordfriese
Avatar
Joined: 2017-01-17, 18:07
Posts: 481
Ranking
Tribe Member
Location: 0x55555d3a34c0
Posted at: 2019-09-17, 21:59

I´m too busy ATM to review the spritesheets pull request, but I´m already preparing to reexport the frisian models with spritesheets. I have merged my GraphicsMoveAndResize, GraphicsAutoClipAnimations, MipmapMaker etc into one applet that generates spritesheets from the raw renders. So a few questions:

  • Did I understand the concept correct: A spritesheet is an image of size CW x RH where C,R are defined in the init.lua and W,H are the dimensions of the individual frames.

  • Are W and H also given in the init.lua or calculated automatically from R,C and the spritesheet size?

  • Are there restrictions for sensible numbers for C and R (in particular blank cells)?

  • Are the frames put right next to each other in the spritesheets or are there gaps?

  • Are consecutive frames arrange left-to-right or top-to-bottom?

  • If I have all mipmaps and pc masks, there will be the following 8 files for each animation, correct?: idle_1.png, idle_1_pc.png, idle_2.png, idle_2_pc.png, idle_4.png, idle_4_pc.png, idle_0.5.png, idle_0.5_pc.png
    And if I have e.g. 3 animations, there should be 25 PNG files (including menu.png) in total, right?


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3057
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-09-18, 10:09

The simple answer to all of your questions is to run the new executable once and look at the result. Why do you need to know all this in detail?

All you need to do is export your images at the 4 resolutions that the engine supports and add them as you have always done. So, there will be no changes whatsoever to the Blender export procedure - it would probably be good to adapt the Blender Python scripts to produce 4 resolutions for maximum quality, rather than doing the post-processing with the Java tool.

Then you run the new executable to turn them into spritesheets. The tool will print the Lua code on the command line, which you can then paste into a "spritesheets" Lua table. Then delete the only animation files and copy over the spritesheet files, and remove the old entry from the "animations" table.

If you generate the Sphinx documentation in the branch, it's all explained there.

  • If I have all mipmaps and pc masks, there will be the following 8 files for each animation, correct?: idle_1.png, idle_1_pc.png, idle_2.png, idle_2_pc.png, idle_4.png, idle_4_pc.png, idle_0.5.png, idle_0.5_pc.png
    And if I have e.g. 3 animations, there should be 25 PNG files (including menu.png) in total, right?

Correct.

So, the procedure would be:

  1. Export the files from Blender at the 4 resolutions. Don't commit them yet to prevent the repository size from blowing up
  2. Test the result in Widelands
  3. Generate the spritesheets and update the Lua code
  4. Test the result
  5. Commit

You could also tun utils/optimize_pngs.py on the spritesheets before committing to make the repository size even smaller.

Of course, this is all moot if we can't get the branch in.

Edited: 2019-09-18, 10:10

Busy indexing nil values

Top Quote