Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[fricy]

The purpose of this thread is to discuss the future of the DFgraphics organization.

The github repository was first created to help the management of the various Starter packs (LNP), and to create an archive if older versions are needed.

Packs maintained:
Afro (Spacefox fork)
CLA
Duerer
Gemset
Grim Fortress
Ironhand
JollyBastion
Mayday
Obsidian
Phoebus
Shizzle
Spacefox/LeoCean
Taffer
Tergel
Wanderlust

Contribution guide:
1, Register a github account, learn a bit about git repository management. If you prefer a GUI, I recommend Sourcetree.
2, Fork an existing, or create a new repository
3, Make your edits and commit them to your (forked) repository. If you make lot's of edits, don't send them in one giant commit, but group the changes in logical chunks, so it's easier to review. The commit message should be easy to understand.
4, Send a pull request with your changes if making edits, or a request for inclusion if it's a new repo
5, If you are the manager of the repo, review and merge pull requests, create version tags.

Format:
The repositories are created to support PyLNP's reduced raw format.
Reduced raw format was designed to maximise ease of installation, compatibility across DF versions and with other mods, and to minimise file size for storage and distribution. It is quite simply a data and raw folder, identically structured to vanilla DF, with all unmodified files removed. It can thus be installed simply by overwriting a vanilla install of DF. Additionally graphic packs must contain a content manifest detailing df version, content version, contributor name and pack name.
Folders to include:
/data/init
/data/art
/raw/objects
/raw/graphics

TODO:
Create organization
Recruite contributors
Add appropriate license to all packs
Better guide

[fricy]

-reserved-

[Button]

PTW

[Abadrausar]

Hi Fricy!

Good work with the repo.

I use a lot bisasam tileset (http://dwarffortresswiki.org/index.php/File:Bisasam_20x20.png) or his yobbo variant (http://dwarffortresswiki.org/index.php/File:Bisasam_20x20_mod_T.png), both with tilesize 20x20 are included in the DF wiki tileset repo (http://dwarffortresswiki.org/index.php/Tileset_repository)

I have remarked that in your repo no 20x20 tilesets are included, the reason that makes me think that they are important is that if you play a nanofort (1x1 embark with 48x48 tiles) a 20x20 tileset is your best bet for not having to scroll at all when you have a screen resolution of 1920x1080.

As you know nanoforts are FPS aware, and have been blessed by Toady one as one of the ways of delaying the FPS death of the game. These underappreciated tilesets are sharp and clear, very defined, however if you use a more frequent and known 24x24 tileset you are forced to scroll.

Usually I copy myself those tilesets and modify the inits accordingly, but I think that it could be a good idea to offer those tilesets to all the users of the pack even with a special recommendation for people interested in doing nanoforts.

Cheers.

[Quiet-Sun]

Hi Fricy!

This is probably a better place to write about this things.   Can you create a subfolder in the repository for 24x24 versions and placeholders for the different tilesets so that I can commit the ones I'm creating?

[Quiet-Sun]

Ok the results are out of a Spacefox 16x16 to 24x24 upscale.   Here is the output of two scaling algorithms (after deconstructing each grid, applying them to each individual tile separately, and then reconstructing the file):

HDx (the very same one used by Arclance's Tile Resizer):



Weifu2x (the resizer is taken from https://github.com/tanakamura/waifu2x-converter-cpp):



The 16x16 original, for comparison, is here:


Both are good, but I think Weifu2x is crisper and clearer (much better than my previous attempt because last time I didn't deconstruct the grid first).  What do you guys think (a good tile to compare is the tree at the bottom-right corner, and the rails and engraved walls)?

EDIT:  Note that you must first open all images in separate tabs.  I noticed that the Forum's engine is reducing their quality.

[Clatch]

Not to discount the Lazy Newb packs, but I can see this being a nice addition to the Homebrew games tap for installing graphics packs into vanilla DF.

brew tap homebrew/games
brew install dwarf-fortress
brew install <graphic_set>

[fricy]

@Abadrausar: Good point, there's Taffer 20x and Gemset 24x, but other than that the sets are not high def friendly. It looks like Spacefox will be converted to 24x, and maybe Phoebus too. The question is, if it's necessary at all to package both 16x and 24x versions, or not. Opinions?
As for Bisasam: this repo so far only contains "graphics sets" - by that I mean they all contain some customization besides a tileset image, like a color scheme, init modifications, creature gfx, etc. For some sets these modifications are minor, like grim fortress, so it could be argued that they are "tilesets" and not "graphics sets".  There's a separate tileset collection folder in the starter packs for these. I guess those also deserve a place here, but before I do that some brainstorming is in order on how to make them easier to install/configure with Pylnp. Paging PeridexisErrant.

@Quiet-Sun: Nice. I read your post in Spacefox, please post this and the app too - if there are no copyright problems with posting some proprietary Matlab software. It expensive...
I think both algorithms produce nice results, the texture details are better with weifu, but hqx is better when the tile is uniform and contains straight lines. Best results would be to photoshop a mix-and-match. I am not going to ask you to do that.
Instead of a subfolder a new branch would be better. I can do it if you want me to, but you know, the secret purpose of this thread is to find people who can send me pull request I can review at my leisure.

@Clatch: Excellent idea, though it would be something like:
brew install dwarf-fortress - - with-gfx phoebus
Do you want to work on it? I need to study brew formulas before I can manage that.

[PeridexisErrant]

Yay, PTW and comment!

Re: licenses - my preference for this is Creative Commons Share-Alike, since graphics packs are clearly not code.

@Abadrausar: Good point, there's Taffer 20x and Gemset 24x, but other than that the sets are not high def friendly. It looks like Spacefox will be converted to 24x, and maybe Phoebus too. The question is, if it's necessary at all to package both 16x and 24x versions, or not. Opinions?
As for Bisasam: this repo so far only contains "graphics sets" - by that I mean they all contain some customization besides a tileset image, like a color scheme, init modifications, creature gfx, etc. For some sets these modifications are minor, like grim fortress, so it could be argued that they are "tilesets" and not "graphics sets".  There's a separate tileset collection folder in the starter packs for these. I guess those also deserve a place here, but before I do that some brainstorming is in order on how to make them easier to install/configure with Pylnp. Paging PeridexisErrant.

@Quiet-Sun: Nice. I read your post in Spacefox, please post this and the app too - if there are no copyright problems with posting some proprietary Matlab software. It expensive...

I'd tend to ship all the tilesets, and stick with the original sizes by default (for better small-screen and creature tile compatibility).  However we should probably take any references to tilesize out of the pack names, and maybe think about improving PyLNP support for variable-tilesize packs and a target tilesize.

If it doesn't touch /raw/graphics/, it's a tileset.  Otherwise, I think we might as well maintain it.

re: Matlab - the runtime is expensive/proprietary, but the code can still be Free/open-source.  GNU Octave supplies a mostly-drop in replacement for the runtime too.  Plus with source I can probably translate to Numpy, and then we can bundle it into PyLNP...

[Taffer]

TODO:
...
Add appropriate license to all packs

The short answer is that I consider the license to be CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), and you can use it as you like as long as you give me credit for the tileset.

Source.

Note that seems very legally "grey". Bitmap fonts simply aren't eligible for copyright in many countries. DF's code pages are in the public domain for a reason and it wasn't corporate generosity.

Further complications:

• reusing tiles without explicit authorization is common in the DF community (search for "based on"),
• those originating tilesets themselves borrowed tiles from earlier works, and it's not clear what was drawn and what was borrowed from public domain sources,
• at these small sizes, different artists can independently arrive at an identical tile. It's happened to me several times already.

I would rather abandon the pretense that we can sort this out, at least in regards to the tileset portions of the packs. I have attempted to resolve this in my own pack by crediting every tile that I copied from existing non-public domain sources (and I asked permission in advance for them), but I wouldn't fancy legally testing my theory. Inviting all contributers to specify a license implies that the copyright is theirs, which might upset people who perceive (fairly or unfairly) that the credit for their tiles has been stolen.

With that aside, thank you kindly for maintaining graphics packs that have lost their original maintainers.

In regards to resizing, I'm really not a fan of any resizing algorithm that I've seen, and I've tried many of them. Still, HDx, Weifu, SuperSai, etc at least look better than DF's hideous zoom feature, and many people seem to enjoy using larger sets. Perhaps they should be included.

@PeridexisErrant: Out of curiosity, is there any reason why you don't seem to ship my tileset? I keep noticing screenshots of people using my tileset with messed up raws, and my suspicion is that people install my tileset over top of the default Starter Pack installation, which doesn't use vanilla raws by default. This is derailing the point, however.

[Quiet-Sun]

@Quiet-Sun: Nice. I read your post in Spacefox, please post this and the app too - if there are no copyright problems with posting some proprietary Matlab software. It expensive...
I think both algorithms produce nice results, the texture details are better with weifu, but hqx is better when the tile is uniform and contains straight lines. Best results would be to photoshop a mix-and-match. I am not going to ask you to do that.
Instead of a subfolder a new branch would be better. I can do it if you want me to, but you know, the secret purpose of this thread is to find people who can send me pull request I can review at my leisure.

Of course! My intention was to truly take advantage of github, but I was thinking there should be separate 24x24 and 16x16 repositories.  My request to you is to create separate 24x24 repositories so that I can clone them, change them, and commit them while leaving the 16x16 in peace.    My intention is to create 24x24 versions of all of them following your system:  First I will create and commit 24x24 versions of the 40.24 sets, and then after you massage/approve them, submit the 42.05 versions,

re: Matlab - the runtime is expensive/proprietary, but the code can still be Free/open-source.  GNU Octave supplies a mostly-drop in replacement for the runtime too.  Plus with source I can probably translate to Numpy, and then we can bundle it into PyLNP...

My code is actually quite simple (and can be freely distributed without any complaint's from Mathworks), because is mainly a wrapper of pre-existing upscaling HQx and Waifu2x binaries.  Translating it to Python should be no problem!  I just don't know any Python yet and I preferred to have a finished product to iterate upon (instead of a project I don't know when I will be able to get around to do).   Matlab is super expensive, but the runtime component is free.   I will upload a windows binary of my matlab program (along with the source) that can be run without any cost.

A word of caution, upscaling a graphics set takes quite a bit of time (we are talking about several hours), because the best results are obtained when you upscale each tile separately.   I wonder if perhaps is better to pre-generate and pack the 16x16 and 24x24 sets with PyLNP.  Since DF doesn't change that often, perhaps it's also better to keep the upscaling application separate from PyLNP (of course translating it to Python is still totally worth it!).   This way people are very much aware of what they are getting into when they launch it 

[Quiet-Sun]

QUICK UPDATE

I started processing the 40.24 files in the repository and only this ones warrant the creation of a 24x24 version:

- Afro-Graphics
- CLA
- Ironhand
- Mayday
- Obsidian
- Phoebus
- Spacefox

[Pidgeot]

A word of caution, upscaling a graphics set takes quite a bit of time (we are talking about several hours), because the best results are obtained when you upscale each tile separately.   I wonder if perhaps is better to pre-generate and pack the 16x16 and 24x24 sets with PyLNP.  Since DF doesn't change that often, perhaps it's also better to keep the upscaling application separate from PyLNP (of course translating it to Python is still totally worth it!).   This way people are very much aware of what they are getting into when they launch it 

Yeah, this is something that's going to be a bit of a problem for integrating upscaling directly into PyLNP. You absolutely have to scale each tile seperately, because the results are generally going to look terrible if you don't, with tiles bleeding into each other and creating odd artifacts.

In the case of waifu, it is an *absolutely awesome* scaling algorithm, but it is also crazy expensive. You wouldn't want to introduce any overhead you can avoid whatsoever... so it would probably be best to call out to C code (possibly using a wrapper so it builds as a C-based Python module?), although even then I suspect it might be too expensive without resorting to GPU acceleration...

[Clatch]

@Clatch: Excellent idea, though it would be something like:
brew install dwarf-fortress - - with-gfx phoebus
Do you want to work on it? I need to study brew formulas before I can manage that.

Sounds good.  I'll give that some attention.

[Button]

What's the objection to including pre-cooked versions of the up-sized graphics sets in the packs? Is it just a matter of file size/avoiding duplicates?