Anyone else fed up with tile config madness?

**buzzkill** · May 13, 2012, 16:44

Originally posted by Magnate

In v4, a number of V's base items are now generated with affixes - lead-filled maces, scythes of slicing, mithril ammo and armour pieces, etc. So the base items no longer exist, which means that they need commenting out of the graf-???.prf files ... for ALL FIVE tile sets.

This is crazy. I just made the same set of edits five times. I know very very little about the tile-handling code (I'm an ascii player), but surely it can't be impossible to use a single graf.prf file for all five tile sets?

In thinking about how to achieve this, the obvious thought is that we get rid of the crazy sheet co-ordinates and move to individual files for individual tiles, arranged in a sensible file structure (e.g. lib/xtra/graf/tilesetname/scrolls/recall.png and so on).

Should we switch to individual tiles, naming become an issue. Either the names are hard coded, or we still need a prf of some sort to align the in game object with it's tile. I would hate to see folders and sub-folders and duplicate tiles with different names to accommodate slight differences among variants.

But since my skills are not up to that, maybe there's an interim fix. If I edit each of the tile sheets so that the tiles are in exactly the same order (i.e. the co-ordinates of the full helm are identical on every sheet), we could use a single graf.prf file, couldn't we?

Aligning the tile set would be a pita, and would introduce an identical problem. Adding or moving a tile in one set would necessitate making changes to every tile set. It also prevents (I think?) from different variants using different tiles for the same object.

If that's right, can someone please recommend the best/easiest graphics app for moving the tiles about.

I still move tiles one by one, pixel by pixel, using a an editor (paint dot net). There's an app called "Glue Sprite" that will split or reassemble a tile sheet, but it's fairly limited and crashes when used with larger sheets.

Other thoughts...
I would love to see a single prf that handles all variants. Something like...

Code:

# soft leather boots

DAJ:K:17:0x80:0x86
VAN:K:26:0x80:0x86
NPP:N:123:0x80:0x86

Each variant would only access the entries with it's own prefix. We could then add a secondary prefix to specify the tileset...

Code:

DAJ:32x32:17:0x80:0x86
DAJ:16x16:17:0x23:0x8A

That should work as long as variants use index numbers to specify objects. Should we break that as some point, as I believe vanilla intends to, things get more complicated.

It would be very nice if we could then move this to some sort of a minimal spreadsheet/database format. Something that could be opened, sorted and saved without the hassle of import/export parsing. This would likely mean everything for a single item being on a single line.

Code:

soft leather boots,daj,32x32,17,0x80:0x86

It would be a monster of a file, but the ability to sort individual columns would make it as easy as pie. BTW, importing/exporting from a spreadsheet is how I do large scale editing now.

The up side is that changing a graphic among a large number of variants become trivial, which I see as being important should UT32 take hold, as it seems to be.

Another thing I'd like to see is a wholescale revision of the lib/pref sub-folder structure (as well as the lib sub-folder structure but that's a whole other thread). All files for a particular tileset should be in their own unique folder...

Code:

lib/pref/32x32/graf.prf
lib/pref/32x32/xtra.prf
lib/pref/32x32/flvr.prf

Files common to all variants (are there any?) would reside in lib/pref.

**Magnate** · May 13, 2012, 17:06

Originally posted by buzzkill

Should we switch to individual tiles, naming become an issue. Either the names are hard coded, or we still need a prf of some sort to align the in game object with it's tile. I would hate to see folders and sub-folders and duplicate tiles with different names to accommodate slight differences among variants.

Yeah, there's also a lot of loading overhead too. I'm going off this idea.

Aligning the tile set would be a pita, and would introduce an identical problem. Adding or moving a tile in one set would necessitate making changes to every tile set. It also prevents (I think?) from different variants using different tiles for the same object.

I must admit that I hadn't been thinking much about variants, just how to minimise the effort required to add or change tiles in a single variant. But why would tiles need to move?

Code:

DAJ:32x32:17:0x80:0x86
DAJ:16x16:17:0x23:0x8A

That should work as long as variants use index numbers to specify objects. Should we break that as some point, as I believe vanilla intends to, things get more complicated.

Yes, this is the problem I have keeping v4 in sync with V - some of the object names have changed. I'd happily revert to numbers if it were up to me.

It would be very nice if we could then move this to some sort of a minimal spreadsheet/database format. Something that could be opened, sorted and saved without the hassle of import/export parsing. This would likely mean everything for a single item being on a single line.

Code:

soft leather boots,daj,32x32,17,0x80:0x86

It would be a monster of a file, but the ability to sort individual columns would make it as easy as pie. BTW, importing/exporting from a spreadsheet is how I do large scale editing now.

The up side is that changing a graphic among a large number of variants become trivial, which I see as being important should UT32 take hold, as it seems to be.

That seems fine to me - leaving the actual prf files as CSV and using spreadsheets to import/edit/export. Your code example above seems to offer the holy grail: a single prf file for all tilesets *and* all variants. I like it a lot.

Another thing I'd like to see is a wholescale revision of the lib/pref sub-folder structure (as well as the lib sub-folder structure but that's a whole other thread). All files for a particular tileset should be in their own unique folder...

... but this contradicts the previous unified example. I really like the idea of lib/pref/tiles.prf with a line for each tile in each tileset in each variant. Variants then parse their own lines, for the tileset they're interested in at that point.

Care to expand on your other thoughts about the lib/ folder structure? By all means start a new thread - I've been thinking about this myself and wonder if we're thinking the same things.

**AnonymousHero** · May 13, 2012, 17:20

Originally posted by Magnate

Yes, this is the problem I have keeping v4 in sync with V - some of the object names have changed. I'd happily revert to numbers if it were up to me.

I realize that this may sound crazy but... what about using UUIDs? That would be an extremely stable identifier which would never need to change for any particular object regardless of renaming/movement.

**buzzkill** · May 13, 2012, 17:43

Originally posted by Magnate

... but this contradicts the previous unified example. I really like the idea of lib/pref/tiles.prf with a line for each tile in each tileset in each variant.

You are correct. The unified prf would eliminate the need for changes to the file structure.

Care to expand on your other thoughts about the lib/ folder structure? By all means start a new thread - I've been thinking about this myself and wonder if we're thinking the same things.

Without going through the trouble of starting a thread since I don't have any concrete thoughts at the moment. It seems to me that while the game has progressed, the file structure has changed very little, if at all. Many folders lie empty and in other instances files that could logically me grouped together, such at save and user and bones, aren't.

My ideal would be (something like this)...

Code:

 Angband/data
Angband/edit
Angband/save

Everything the player (or game on behalf of the player) saves goes in the save folder, custom pref's, characters, bones or dumps. The core files that the player shouldn't mess with go in the data folder. The edit files, pref files, any core files that are typically customized by players seeking to tweak the game go in the edit folder.

If a player wants to upgrade from one version to a newer version, assuming compatibility, he only need to copy the save folder (and the edit if he has made changes).

Anything OS dependent should be in it's own subfolder.

Since I'm a graphics guy, (status-quo) I'd like to see all the files for a tile set together in one place. That means uniting the prfs and bmps into one folder Since they're useless individually, why the separation? (maybe throw the INI in there too)

**buzzkill** · May 13, 2012, 22:20

soft leather boots,daj,32x32,17,0x80:0x86

That seems fine to me - leaving the actual prf files as CSV and using spreadsheets to import/edit/export. Your code example above seems to offer the holy grail: a single prf file for all tilesets *and* all variants. I like it a lot.

[item name],[variant name],[tileset name],[item index number],[hex address row]:[hex address column]

item name : a name or description of the item, terrain, effect, etc.
variant name : an self explanatory abbreviated name for a variant
tileset name : the actual name of the file. The mask file (for bmps) would be assumed to have _mask suffix (32x32_mask.bmp). Do file names still need to be < 8 chars?
item index number : the index number of the item
hex address row/column : I'd like to see this handled as a single item. I see no advantage to handling them as separate values. I'd also like to remove the hex notation and switch over to decimal.

So...

soft leather boots,daj,UT32.bmp,17,128:134

Since we've gotten this far with little if any disagreement, let me take it one step further. Let's throw in a version/revision number too. Different version of the same variant often need a different prf or at least partial changes to the prf. The revision number need not be in any way related to the actual version numbering of the release, not that it couldn't be as long as the version numbering is continuously incremental using integers only. I know I didn't explain that well, so something like this.

Code:

item name, variant, latest revision number, file name, index number, address
boots    , npp    , 053                   , 32x32.png, 121         , 128:134

The above line would refer to NPP 0.53. After NPP 0.53 Jeff decided to do away with boots and instead add high heels using the same index number, 121, we wouldn't want them using the same tile, so the following line would be added to the prf (without removing the previous line).

Code:

[B]heels[/B]    , npp    , [B]054[/B]                   , 32x32.png, 121         , [B]156:128[/B]

You can see that just the revision number and the address changed (and the name).

Jeff would just have to, as would become common practice, to specify in the code that this version of NPP, lest say NPP v.54, uses prf revision 054 (same as 54). What that means is that it will use items notated as revision 54 whenever possible. In the case that it cannot find a particular item designated as revision 054, it will instead use the previous revision, 053 and so on (052) and so on (051) until if finds one.

So player of NPP 0.53 will see boots, and players of NPP 0.54 will see heels, all with the same universal prf. Confusing? only slightly.

Should he at some point (NPP 5.5/pef revision 055) decide to remove both heels and boots from the game, adding nothing in their place, we could denote that by something like this. I don't think that will cause any problems.

Code:

[B]unused[/B]    , npp    , [B]055[/B]                   , 32x32.png, 121         , [B]000:000[/B]

Anyone see a problem with this, or have a problem with this. While I can't do any of the coding work, I can help out with on the prf end.

**Nick** · May 14, 2012, 05:06

Originally posted by buzzkill

variant name : an self explanatory abbreviated name for a variant

Vanilla has one of these, in savefile.c:

Code:

static const byte savefile_name[4] = "VNLA"

FA has one too, but in defines.h:

Code:

#define SAVEFILE_NAME "FAAN"

I suspect at least some other variants will have them.

**Nomad** · May 14, 2012, 12:07

Originally posted by Magnate

In v4, a number of V's base items are now generated with affixes - lead-filled maces, scythes of slicing, mithril ammo and armour pieces, etc. So the base items no longer exist, which means that they need commenting out of the graf-???.prf files ... for ALL FIVE tile sets.

How about creating a central "tile index" pref file separate from the tile set specific prefs? So index.prf would specify all the tiles required for the current game, maybe in some sort of type:index:name format like this:

Code:

feature:0:Nothing
feature:1:Open floor
...
monster:0:Player
monster:1:Filthy street urchin
monster:2:Scrawny cat
...
soft armour:0:Robe
soft armour:1:Jerkin

Then allow the tile set pref files to specify tiles in simple name:coordinates form like:

Code:

Nothing:0x80:0x80
Open floor:0x80:0x81
...
Player:0x90:0x90

Parse the index file for the names of the required tiles, and then load just those ones from the tile list in graf-xxx.prf, ignoring any additional entries for tiles not needed by this version/variant. That way if you need to remove objects/monsters, you can just comment them out from the single tile index file, and though entries for them will still exist in the multiple tile set files, they'll just be skipped because the index file hasn't requested them.

**Magnate** · May 14, 2012, 18:15

But I don't think this (Nomad's) suggestion deals with the issue of two different variants using different tiles for the same object, does it? In this approach the tile for each object is determined by the tileset, whereas buzzkill's approach adds an extra column for specifying the variant.

You're right that this is a simpler solution for V alone though. But since either approach needs to be implemented by someone familiar with the tiles code, it's really up to them.

So, Blubaron, what are you drinking? First round's on me ...

Anyone else fed up with tile config madness?

Anyone else fed up with tile config madness?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment