I’d like to know, how are making your png files, are you really drawing in that one ugly png or are you using some sort of application (of function in drawing application) to glue tiles together in one png? Or if said application simplifies drawing in tiles, like showing boundaries or something?
Thanks!
[quote=“Robik, post:181, topic:3676”]I’d like to know, how are making your png files, are you really drawing in that one ugly png or are you using some sort of application (of function in drawing application) to glue tiles together in one png? Or if said application simplifies drawing in tiles, like showing boundaries or something?
Thanks![/quote]Back when I tried making a tileset for Dwarf Fortress, I used Photoshop and its grid overlay. Splitting a giant image into lots of small ones doesn’t really simplify anything, especially if you can reuse some elements for variants.
[quote=“Sean Mirrsen, post:182, topic:3676”][quote=“Robik, post:181, topic:3676”]I’d like to know, how are making your png files, are you really drawing in that one ugly png or are you using some sort of application (of function in drawing application) to glue tiles together in one png? Or if said application simplifies drawing in tiles, like showing boundaries or something?
Thanks![/quote]Back when I tried making a tileset for Dwarf Fortress, I used Photoshop and its grid overlay. Splitting a giant image into lots of small ones doesn’t really simplify anything, especially if you can reuse some elements for variants.[/quote]
I should maybe explain why I want to know 
I am planning doing tileset studio. Main difference from the Chase’s editor would be that tiles will be separate files (one png per tile) in directory structure. It should simplify searching for and mapping tiles on objects. Function for easy cloning would be of course there, for reusing in variants. Mapping on object would be on tile side (I didn’t settle on this one yet) and tile.png and tile.json would make a pair of defining files, in similar fashion like in programming editors, where are pairs of files, one defining looks and second defining the function.
Now, all this work make sense only if people, who are making tilesets are not using something like that already, being it standalone software or built-in function of graphics editor.
Things that will be in before I even start to think about releasing it to the world
It should include user defined font tiles for auto generation where tile is not directly defined for object, but HRose is working on adding such support into the game itself, so my editor would just make another png from font tiles, instead of autogenerating missing tiles, while exporting.
Why I think it is good idea?
Aside from mentioned browsing thru the tiles, collaboration of more people on one tileset will be much easier.
It should be far better to make a program that loads compiled packages of tiles (i.e. single large files) but breaks them down to single tiles for operation, and resaves them as a whole package again. This way people can collaborate on packages, and you don’t end up with eight hundred individual little PNGs fragmenting your harddrive.
Scenario:
Tileset project has 2 directories
Adam
Ben
They decide that Adam will work on zombies and Ben on Furniture.
If Adam want to share his work with Ben, he just send zipped directory to him, it includes all tiles he made along with mapping to objects. Ben just unzip it in Adam directory. Done!
How would you put work of two people together in your case?
Have two separate image files, each with its own definition file (which doesn’t have to be JSON for this purpose, plain text will do for indexed IDs and comments).
One person sends his pair of files to the other. The other person uses the program to load his set, and the other set - each set is broken up into individual images upon loading, so they can all be worked on individually. The end result is a single big set that can be saved together, and any overlap and conflicts can be resolved as needed before export. This setup allows to easily filter by author and save sub-selections of the entire loaded tileset, while still not resulting in hundreds of files for the OS to choke on.
[quote=“Sean Mirrsen, post:186, topic:3676”]Have two separate image files, each with its own definition file (which doesn’t have to be JSON for this purpose, plain text will do for indexed IDs and comments).
One person sends his pair of files to the other. The other person uses the program to load his set, and the other set - each set is broken up into individual images upon loading, so they can all be worked on individually. The end result is a single big set that can be saved together, and any overlap and conflicts can be resolved as needed before export. This setup allows to easily filter by author and save sub-selections of the entire loaded tileset, while still not resulting in hundreds of files for the OS to choke on.[/quote]
I am not saying it cannot be done your way, but why would I want to do something so complicated?
Beauty of my solution is that it is more simple for me to make, why program some sort of in-editor merging support, when there are directory and file merging utilities already, like WinMerge.
And if the only argument for such solution is hundreds of files to fragment your HDD and have your OS to choke on? Well, you should check how many files the CDDA has itself… or Windows folder for that matter.
As I already said, you’re making great progress, HRose.
[quote=“Robik, post:187, topic:3676”][quote=“Sean Mirrsen, post:186, topic:3676”]Have two separate image files, each with its own definition file (which doesn’t have to be JSON for this purpose, plain text will do for indexed IDs and comments).
One person sends his pair of files to the other. The other person uses the program to load his set, and the other set - each set is broken up into individual images upon loading, so they can all be worked on individually. The end result is a single big set that can be saved together, and any overlap and conflicts can be resolved as needed before export. This setup allows to easily filter by author and save sub-selections of the entire loaded tileset, while still not resulting in hundreds of files for the OS to choke on.[/quote]
I am not saying it cannot be done your way, but why would I want to do something so complicated?
Beauty of my solution is that it is more simple for me to make, why program some sort of in-editor merging support, when there are directory and file merging utilities already, like WinMerge.
And if the only argument for such solution is hundreds of files to fragment your HDD and have your OS to choke on? Well, you should check how many files the CDDA has itself… or Windows folder for that matter.[/quote]When the beauty of your solution lies in how easy it is for you to make, rather than how easy it is for others to use, you may be better off making things for yourself only.
Cataclysm on the whole has 18-something hundred files.
A complete Cataclysm tileset has a little over 24 hundred tiles.
Of course, that’s not as bad as, say, Cortex Command.
But frankly, I see absolutely no benefit to working on several hundred separate files that are really separate. Do you give each tile its own definition file? Do you sort through twenty hundred picture/textfile pairs when you need to extract a subset of your work to send to someone? Or do you have one definition file for the whole set?
You can much easier load a single 16xN tileset image file and split it into tiles for working with them - a little like this program does. It allows you to import tileset pages whole, and pick out which tiles you want to use, splitting them up for the user’s convenience, without having to keep every tile you make in a separate file and load it separately.
Oh, I don’t know. I use an ancient Paint Shop Pro version, mostly. Just zoom in, and sometimes use a 10x10 grid to see the tile sizes.
If you look for a good program to do pixel drawing there’s Grafx2.
[quote=“Sean Mirrsen, post:189, topic:3676”][quote=“Robik, post:187, topic:3676”][quote=“Sean Mirrsen, post:186, topic:3676”]Have two separate image files, each with its own definition file (which doesn’t have to be JSON for this purpose, plain text will do for indexed IDs and comments).
One person sends his pair of files to the other. The other person uses the program to load his set, and the other set - each set is broken up into individual images upon loading, so they can all be worked on individually. The end result is a single big set that can be saved together, and any overlap and conflicts can be resolved as needed before export. This setup allows to easily filter by author and save sub-selections of the entire loaded tileset, while still not resulting in hundreds of files for the OS to choke on.[/quote]
I am not saying it cannot be done your way, but why would I want to do something so complicated?
Beauty of my solution is that it is more simple for me to make, why program some sort of in-editor merging support, when there are directory and file merging utilities already, like WinMerge.
And if the only argument for such solution is hundreds of files to fragment your HDD and have your OS to choke on? Well, you should check how many files the CDDA has itself… or Windows folder for that matter.[/quote]When the beauty of your solution lies in how easy it is for you to make, rather than how easy it is for others to use, you may be better off making things for yourself only.
Cataclysm on the whole has 18-something hundred files.
A complete Cataclysm tileset has a little over 24 hundred tiles.
Of course, that’s not as bad as, say, Cortex Command.
But frankly, I see absolutely no benefit to working on several hundred separate files that are really separate. Do you give each tile its own definition file? Do you sort through twenty hundred picture/textfile pairs when you need to extract a subset of your work to send to someone? Or do you have one definition file for the whole set?
You can much easier load a single 16xN tileset image file and split it into tiles for working with them - a little like this program does. It allows you to import tileset pages whole, and pick out which tiles you want to use, splitting them up for the user’s convenience, without having to keep every tile you make in a separate file and load it separately.[/quote]
Well, so far, your arguments were that if would be hard for HDD and OS, not for the user. If it would be inconvenient for user, then the application is not well thought.
Each tile would have it’s own json, with links to its assigned game objects, but user will not have to edit them manually, they fill themselves automatically when user picks tiles for object.
For sending subset of your work, it is much easier to have files separated and let user use file manager of their choosing (I prefer FreeCommander and its folder and file comparing and synchronizing ) to copy only tiles the want to send, than trying to program equivalent into the editor itself.
Now, I don’t think I can convince you, and I do not want to. I just posted here to get people ideas and how they are working currently. So I appreciate your input even when I do not agree with you. In the end, after it is done, it will be tile-makers who will decide if it is good enough for them or not.
Oh, I don’t know. I use an ancient Paint Shop Pro version, mostly. Just zoom in, and sometimes use a 10x10 grid to see the tile sizes.
If you look for a good program to do pixel drawing there’s Grafx2.[/quote]
Thanks for info.
And sorry for hijacking your thread somewhat, it was not my intention 
It seems the last official experimental is broken. So I can’t test how well the code works.
On the old version ASCII fallback is fine. It can display some colors wrong and it has a number of other minor issues, but it works.
I could package the older version, but I’ll wait a bit to see if they fix the experimental.
Here’s a build if you want to test:
www.cesspit.net/misc/cataf.zip
This includes everything. It has my colors, it has ASCII fallback and it’s using by default RetroDays (with some minor changes as I was fiddling with it), since my tileset crashes the program for some reason.
Since RetroDays bsically covers most stuff, it’s actually rare to see ASCII, but the point is that you shouldn’t be able to see the “unknown” symbol as everything comes either from the tileset or it’s drawn in ASCII.
And there seem to be some problems displaying traps.
Updated to the latest experimental:
http://www.cesspit.net/misc/cataf3.zip
And I managed to sledgehammer my way through some Java code and made Chase’s tileset editor capable of generating bitmap ASCII.
[quote=“Sean Mirrsen”]And hopefully not earning an infraction for triple posting - I am prepared to humbly admit victory. 
Down at the bottom is all the generated tiles. It still needs some polish and proofing against user error (such as selecting a tileset of mismatched dimensions), but it can now autogenerate ASCII tiles from a bitmap file.
Updated program
Updated source
The RetroDays tileset padded with ASCII[/quote]
Well, “capable” is the wrong word - now all it can do is the bitmap ASCII. I gotta split them functions at some point. But it already seems to work.
Fixed traps:
http://www.cesspit.net/misc/cataf4.zip
Fixed some dll dependencies:
http://www.cesspit.net/misc/cataf5.zip
This build actually WORKS, compared to the current official experimental builds that crash. So basically this version is recent and working.
[quote=“HRose, post:198, topic:3676”]Fixed some dll dependencies:
http://www.cesspit.net/misc/cataf5.zip
This build actually WORKS, compared to the current official experimental builds that crash. So basically this version is recent and working.[/quote]
Its working indeed!
Great work. I noticed you went with one png file in the end instead of two.
Color seems a bit too bright in terms when it comes to the menu and font, more like a fluorescent bright and a bit hard on my eyes. I could always set my screen a more halogen tone so no worries but wondering if somehow there is a way to tweak it otherwise? Otherwise awesome and thanks though Any difference between the regular tile and full? Both seem the same but figured I would ask if I missed something.