Print

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

Dwarven Selection

113 (6.3%)

Wildlife

58 (3.2%)

Ambushes

154 (8.6%)

Sieges

207 (11.5%)

Undeads

118 (6.6%)

Forgotten Beasts

110 (6.1%)

Megabeasts

42 (2.3%)

The Circus

84 (4.7%)

FUN Spiral

286 (15.9%)

Dwarven Engineering

131 (7.3%)

FPS Death

396 (22%)

Other? (please specify)

97 (5.4%)

Total Members Voted: 879

[Aydjile]

*Updated* 0.31.25v15
Sanitized the Tileset Assembler. (Warn me if there's any bugs/problems with it.)
Streamlined the list of Symbol Charts and Rough Walls.
Added an extra tileset for Mac/Linux users: Smooth.

- whoa, man! i can't keep up! 
* threw towel and went back.

[krenshala]

Nice.  I'm going to have to play around with that tileset generator.   [Using Windows since I haven't found the time to get the linux side of the dual-boot set up yet since solving some hardware problems.]

[mux951]

O.M.G.

this is almost better than a new DF release 
you are so full of win Phoebus

[Ironhand]

Dude, that is so cool!!!

[Phoebus]

I had to insert floors in the wall tilesets because of some... complexity problems.

For the most of the tiles things are simple, I can just write the tile symbol/drawing over a floor tile texture and presto, it works.
But walls have engravings, so if I just write walls over a floor tile texture, the floor will be visible in the walls' engravings. Not good.
So I need a way to tell where to draw or not the floor texture under the wall.
The simplest way I can think of would be to add a color code to the wall tilesets to flag where to draw the floor texture.
But even that won't be so simple as some wall tileset (the round one for example) have semi-transparent edges, and I need to both have wall ARGB color information and the 'draw the floor' flag in the same pixel. So it would require either an extra PNGs (or an extra layer if I knew how to read those) to hold the information of where to draw the floor under the each specific wall tilesets.
But even then, there are still complications. Some walls have engravings outside of the boundaries of the wall itself.
Thus, to be able to switch the floor engraving to the wall engraving on the part where the floor is being draw, I need to split both the wall and floor engravings in separate tileset, then have an extra tileset to indentify where the floor engravings should be used.
So I would need to merge the wall and floor engravings using the wall specific engraving filter, and draw that. Then draw the floor where the wall specific floor filter allows. And finally draw the wall.

And that is why floors are currently integrated into the wall tilesets.
If someone has a less insane solution, I'm all ears.

----

For those that wish to add options to the assembler, the file absolutely need to be 256x256 32bit ARGB PNGs with an appropriate prefix (like "Ground_" or "Wall_".)
If the file is not 256x256 32bit ARGB PNGs named like "CAT_NAME.png" the Tileset Assembler will ignore it.

I'm also thinking about adding a way to include tile 'patches'.
The tile patch files would need to be 16x16 32bit ARGB PNGs named "Tile_X_NAME.png", where X is a number from 0 to 255.
The assembler would then list all of the individual tile replacements. Once a tile is toggled, that tile would be drawn at the numbered location in the place (deleting) the tile generated by the selected tilesets.

Edit.: Also, I forgot to write about it anywhere, but clicking on the tileset display will cycle through different background colors. ... DISCO! *cough*

[Jeoshua]

The "patch" idea is an interesting one.  I was thinking, it would be nice to make subset patches... like for the "pipes", for example.  But that's likely beyond what you were trying to do.

[Phoebus]

The "patch" idea is an interesting one.  I was thinking, it would be nice to make subset patches... like for the "pipes", for example.  But that's likely beyond what you were trying to do.

I was originally planning to make the assembler based on custom categories, but that reached a bit too far and I failed when trying to create the dynamic interface to accommodate those custom categories, so I settled on a 'static' layout hence static categories.
Even then, I need to code the selective overwriting/deletion of individual tiles before I can add custom cats, otherwise the default cats will need to be modified to allow new categories of options and that would be way harder than even switching the tiles by hand. And I need to choose a way to store the information about which tile(s) the new partial tilesets will be overwriting.
Hence why I'm going for the single tile patch system; it can simply store the single tile number in it's name. And the work will carry on to the better system.

Also, I don't think it's wise to store the personal custom tiles/tilesets in your DF directory as they'll likely get destroyed and it'll be a pain to move them around when upgrading your DF version/raws.
So I think I'm going to store them in "/AppData/Roaming/", but still, I must find an easy way for the user to move their custom files there.

[manboricua]

Wow man, the Tileset Assembler is amazing! Your updates are one impressive after another. Thumbs up bro!

Edit: I have to say that this is AWESOME, changing the tileset like that is so much better. I just wonder what else can be added to make it even more awesome. Thanks!

[Jeoshua]

Well, now that it isn't necessary to do the whole thing over again to introduce a new font, or wall type, or floor type... I'd say this is the golden age of this tileset.

[devek]

I'd say this is the golden age of this tileset.

+1

[krenshala]

Phoebus, it is slightly more work, but I think your best bet would be to use a 1 bit mask layer to identify which parts the floor texture should appear in, and which parts should be completely blank (transparent) for the background.  Use it as a layer mask, where on shows the floor tile, and off shows transparent (or the reverse, not sure without checking which would be easier).  You could use a name such as Floor_Mask_blah.png for that layer (or Mask_Floor_blah.png in case you want to create other Mask_Type_Tileset.png combinations).

[Shandra]

Wow... that's just... just... just a bloody mindblowing damned brilliant and awesome piece of geeky surprise - I'm speachless!

[Shandra]

Also, I don't think it's wise to store the personal custom tiles/tilesets in your DF directory as they'll likely get destroyed and it'll be a pain to move them around when upgrading your DF version/raws.
So I think I'm going to store them in "/AppData/Roaming/", but still, I must find an easy way for the user to move their custom files there.

My idea would be either
a) as you are using a compiler language anyways, you shouldn't have any problems querying the registry for the path to my_documents and then grand us a Phoebus Folder in that ....
or b) let us define a global variable (PHOEBUS_TILESET or whatever) with the path of our choice
[edit] or c) use the registry yourself and add a config menu or such where we define the path (but then please also add a registry script that removes the entry again)

I would prefer those option over the use of /AppData/Roaming (for us  Pre-Vista users that would be Documents and Settings/Username/Application Data, or?) as I have moved the my_documents folder away from my OS-Partition but left the other personal folders there (That folder has just grown huge over time and I don't want it to be included in my monthly partition images, or better said to be reseted to a previously state by such images if i write them back to the partition).

[Jeoshua]

Issue with AppData\Roaming

What about us who play DF from a USB on various computers they can get access to?  That would break compatibility for us, would it not?  The library computers that I use regularly do not allow changes to anything on the main hard drive.  And when they do, it is reset every time.

Writing the files to a subdirectory of DF will work nicely, I think.  New versions will be installed and overwrite EXISTING files... but if they're in a special folder, this won't be a problem.

[Shandra]

Writing the files to a subdirectory of DF will work nicely, I think.  New versions will be installed and overwrite EXISTING files... but if they're in a special folder, this won't be a problem.

with overwriting and changing versions I have a problem, as I prefer a clean install/unzip to avoid conflicts with changed/renamed files - leftovers - and such (like keeping previous folder as a backup (for *dif purposes or whatever))... maybe some kind of a one-liner .ini file could be used where there is either a absolute or relative path set [example: "PATCH_PATH="e:\documents\DF\Phoebus\Tiles" or "<PAR>=".\My_Tiles" || "<PAR>="..\My_Tiles"].
So we would just need to copy/replace that ini with each successor and both kinds of users (stationary/solitary PC vs. portable) would be satisfied ?!

Or make it a command-line parameter and use a default path if that one is ommited - the possibilities are endless... but IMHO making it customizable is better then using a fixed path - and as most of us just use that tool once for each version change it shouldn't get too complicated - even selecting/browsing for it each time the app is used could be a possibility, but for those that will try out to gfx on their own, a way of defining the path is of course the better solution