Generating bitmaps from vectors seams appealing and is appealing, but manually tweaked icons from vector conversion yields a better result. I plan to build a custom converter based on java. It will take every vector image, convert it to bitmap and then place it into a folder named [sizeXX]. If there is already an image present, it will not overwrite the image. This allows contributors to finetune the images. As usability is one of the key elements in a fun to play game, I think this part is important to get right. Or at least allow for the possibility to get it right sometime in the future.

The tiles are not optimized at all. They currently are the source of some rendering issues; I took them from Sea3D screenshots (which btw also released the source under GPLv3), and then erronously converted them to something which looked somehat OK. It's on the todolist to have them fixed.

I used the Macromedia software for this (about 3-4 years ago, when I was not so much FLOSS savvy). This should not at all impact the licensing of the images. I will remove them sometime. I have put it onto a todolist, thanks for mentioning!

>Pioneers draws the chits on the fly

I have had some implementations doing so too. Turns out, the best result is achieved by statically defining the bitmaps because rendering engines always lack behind on the current bitmapping techniques. If they at all catch up. So I decided bitmap generation at runtime was not such a good idea. YMMV, but I have yet to stumble upon a rendering engine on par with current imaging technology.

>Pioneers also resizes the bitmaps to fit the screen

Various sized bitmaps are also used on the wiki. This allows us to reuse the same optimized images in html docs, and keep them consistent.

Finally, some images are identical bitwise, but that's because I have defined them differently in the software. They just have a different name and should ultimately be replaced by something that resembles the metaphor more accurately.

The way I hope to see this subproject evolve is to have one common naming set, and one principal default theme. From there, we can extend to multiple themesets. We'd be able to merge in other themesets from Sea3D, Cities3D and Pioneers. The other thing I have planned is some sort of themechecker webapp, which basically displays a list containing the status of a theme. It would list all possible icons/images, the image (if present) itself alongside an (if present) generated from vector/downsized from bitmap image. Themes with high quality then would be merged into the game itself.

The thing therefore I'd really like to have some feedback on, is the naming. I see naming as an important part in achieving compatibility. I can make a naming diff table, and then we might decide from there? If there's at least one naming difference (I believe I already noticed multiple, e.g. "pasture") either Pioneers or OpenSettlers needs to refactor the code to adapt to a common naming scheme. With a naming table, we can do three things: 1) OpenSettlers adapts all naming to Pioneers, 2) Pioneers adapts all naming to OpenSettlers, 3) we split the naming changes evenly over both projects. You sir, by leading a project much older then OpenSettlers, are hereby requested to make the call ;).

Sincerely and with fun,

Ruud

Op woensdag 3 augustus 2011 schreef Roland Clobus (rclobus@users.sourceforge.net) het volgende:
> On Sun, 2011-07-17 at 12:07 +0200, Ruud Poutsma wrote:
> ...
>> Therefore, I will split the graphics part of OpenSettlers into a new
>> project called OpenSettlers graphics. It will just be a folder with
>> SVG and PNG files (no 3D files exist as of yet). Including these files
>> will be a matter of cloning the repo and including in your project. To
>> see for yourself what images and icons are in the repo, go to
>> https://github.com/OpenSettlers/OpenSettlersGraphics/commit/3a99e36eed00bf8049c75f2bb09396971cc670dd#diff-42.
>
> Good idea to bundle our forces to share the graphics.
>
> I see many images that appear to be identical, but which are resized
> versions of eachother. Did you use a (make-)script to resize the images?
> Could you include that in the repository? (Pioneers uses the policy that
> any file that could be generated will not be added to the repo, it's up
> to the maintainer to regenerate the images for the released tarball, or
> in the case of Java, the .jar-file).
>
> Given the nature of many of the drawings, did you use a vector format as
> the original?
> For the tiles, they appear to me to be oriented in all different
> directions. They also look photographic to me. Pioneers uses a very
> strict policy regarding adding images, they must have the right license
> to be redistributed without problems in e.g. Debian.
> I've analysed 'WheatHex.png', and I see the string 'Macromedia Fireworks
> MX 2004', which costs about $300, which is not a tool I'll readily see
> distributed in an OpenSource-distro. To apply the hexagonal shape, I
> assume that the original file was rectangular and a tool was used to
> apply the hexagonal transparency. (For 'The Gimp', the XCF-file would be
> the true source-file)
>
> Pioneers draws the chits on the fly, so doesn't need bitmaps. Pioneers
> also resizes the bitmaps to fit the screen, and therefore needs only one
> image size.
>
> Take a look at
> http://pio.svn.sf.net/viewvc/pio/trunk/pioneers/client/gtk/data/themes/
> for all freely available themes in Pioneers (licensed as GPLv2 or later,
> or CC-BY-SA).
>
> With kind regards,
> Roland Clobus
>
>