[request] user-friendly mechanism for tiles override

[white_noise]

Back to this issue.
Can we PLEASE have a folder for tile replacements?
- put a .png file there
- name it correspondingly
- game should override (on the fly) the default tile with it

I don't know how hard is it to code, but for users it would be so much simplier to use.
And it would allow a tile-packs to exist. I.e. anyone would be able to pick one that he likes OR compose a mix from several packs without too much trouble.
And the best thing is that with newer version of the game you would just move this folder there and that's it. If some items would be removed from the game then their tiles will just not be used, but overall tile-set will still work with the remaning ones.

[Siegurt]

That isn't how tiles work, or indeed how programming works.

To be a little less tongue and cheek about it: tiles are the way the are, because that is one of the requirements for using the technology that does the display. While it is theoretically possible to replace that technology with a different system, one that works like you suggest, it would be an excessively large undertaking to create such a system.

[savageorange]

No.

Now, if you wanted to implement your own system that automatically detects changed PNGs and compiles them into the 'tilesheet' form DCSS uses, it probably would be pretty easy for devs to add something that checks the tilesheet files (say, once every 100 turns) and reload them if they change. That would be far simpler.

[white_noise]

Hm. I still don't understand what exactly prevents creating a rule to check specified folder for replacements before using default image?..
I mean what difference it makes if game takes image from given coordinates on a large tile-map or from single file?
Why it can't be implemented into current system?

[mps]

I'm not saying this is a worthwhile thing to do, but it's obviously possible to do it.

e: If you had a patch that did this, they might accept it. There is absolutely nothing that would prevent periodically checking some directory for appropriately named PNGs, checking their timestamps, and loading them as replacement tiles as necessary. It's just that no one would take the time to do it because it's a feature that would interest few people in the first place and probably no one would be interested enough to write it.

There might be a problem that as soon as such functionality is available, it would become the default way people who make tiles would want to package their stuff, since it's a lot more straightforward than packing things in sheets. There could be some "political" problem with that, idk.

[savageorange]

Personally I was trying to point out that most of it can be done outside of DCSS (and hence, since it's not in high demand, probably should be). Moreover, with inotify's recursive directory watches hooked up to the DCSS makefiles, it could be downright simple (a statement that by no means could be made about adding such a system to DCSS itself). Why do something complex if we could instead do something simple?

The politics of it are merely 'meh'. AFAICS, white_noise is the only one who cares about this. Logically, that means that white_noise is the only person who might bother to do it at all.

[gammafunk]

OP there's not really an underlying technology change needed, but there are two significant technical issues to deal with: (1) regenerating the large tilesheet images (required by dcss for efficient display) from the individual images either at startup or on-demand and (2) moving a bunch of tile data out of the binary and into a data format.

The first thing is easier do, since we already have an executable (called tilegen) that we generate on every platform to turning the individual images into tilesheets. Instead of shipping the tilesheets only like we do now, we'd ship the individual images, the association definition text files, and an updated version of this executable that could look at the modification times of these files to know when to regenerate a given tilesheet. The could be called by crawl when starting Tiles, but it might add too much startup time checking all images (we already have some startup time from checking all .des files for modifications). We could instead install a menu options or app to run tilegen in a terminal, so a user would update the image and then run tilegen as necessary.

The second issue involves moving at least the individual tile size and offset data out of autogenerated source that gets compiled into the binary and into a data format. This data is necessary for crawl to know where to find a given tile in the tilesheet. There's other data that's currently in autogenerated source that you'd likely want to move into a data format as well: the data on any variants for tilesets like those for plants, trees, and "animated" monsters like boulder beetles, the descriptive names of the tiles, and the order of the tiles in the tile index. Moving all of this data out of the binary would allow any changes done to the tiles definition files (rltiles/dc-*.txt) to apply to the final tilesheet when tilegen is run.

You can't achieve what you want just through the Makefile, since we don't ship a dev toolchain with crawl, and if we only cared about people who had a working toolchain installed, we'd just tell them to download the source, modify the image, and recompile.

Anyhow these changes would be nice to have, and would make it easier for tiles artists to make changes without thinking about compilation, but there's significant work involved. Patches are always welcome, and if you or anyone is serious about this (and is reasonably self-sufficient), you can stop by ##crawl-dev on IRC and ask me, |amethyst (neil), and others in the channel for help.