Angband.oook.cz
Angband.oook.cz
AboutDownloadVariantsLadderForumCompetitionSpoilersComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old May 13, 2012, 14:11   #1
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 4,988
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate Send a message via Skype™ to Magnate
Anyone else fed up with tile config madness?

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).

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?

If that's wrong, can someone please explain why it's not possible, and whether there's another way.

If that's right, can someone please recommend the best/easiest graphics app for moving the tiles about.
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old May 13, 2012, 16:44   #2
buzzkill
Prophet
 
buzzkill's Avatar
 
Join Date: May 2008
Location: Indiana, USA
Posts: 2,908
Donated: $8
buzzkill is on a distinguished road
Quote:
Originally Posted by Magnate View Post
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.

Quote:
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.

Quote:
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.
__________________
www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.
buzzkill is offline   Reply With Quote
Old May 13, 2012, 17:06   #3
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 4,988
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate Send a message via Skype™ to Magnate
Quote:
Originally Posted by buzzkill View Post
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.
Quote:
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?
Quote:
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.
Quote:
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.
Quote:
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.
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old May 13, 2012, 17:20   #4
AnonymousHero
Knight
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 547
AnonymousHero is on a distinguished road
Quote:
Originally Posted by Magnate View Post
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.
AnonymousHero is offline   Reply With Quote
Old May 13, 2012, 17:43   #5
buzzkill
Prophet
 
buzzkill's Avatar
 
Join Date: May 2008
Location: Indiana, USA
Posts: 2,908
Donated: $8
buzzkill is on a distinguished road
Quote:
Originally Posted by Magnate View Post
... 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.

Quote:
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)
__________________
www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.
buzzkill is offline   Reply With Quote
Old May 13, 2012, 22:20   #6
buzzkill
Prophet
 
buzzkill's Avatar
 
Join Date: May 2008
Location: Indiana, USA
Posts: 2,908
Donated: $8
buzzkill is on a distinguished road
Quote:
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:
heels    , npp    , 054                   , 32x32.png, 121         , 156:128
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:
unused    , npp    , 055                   , 32x32.png, 121         , 000:000
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.
__________________
www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.
buzzkill is offline   Reply With Quote
Old May 14, 2012, 05:06   #7
Nick
FAangband maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 49
Posts: 4,322
Donated: $60
Nick is on a distinguished road
Quote:
Originally Posted by buzzkill View Post
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.
__________________
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them.
Nick is offline   Reply With Quote
Old May 14, 2012, 12:07   #8
Nomad
Swordsman
 
Nomad's Avatar
 
Join Date: Sep 2010
Location: England
Posts: 450
Nomad is on a distinguished road
Quote:
Originally Posted by Magnate View Post
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.
Nomad is offline   Reply With Quote
Old May 14, 2012, 18:15   #9
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 4,988
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate Send a message via Skype™ to Magnate
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 ...
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Tile lighting Shockbolt Development 2 October 9, 2011 20:20
Tile painters: request for a new tile takkaria Development 8 June 17, 2011 12:01
Specifying system fonts in config.h? Therem Harth Variants 5 December 20, 2010 02:24
Tile issues in 3.1.0 beta amoeba801 Vanilla 4 April 25, 2009 20:48
[NPP] Whoa... or... Quest Results in Madness ElectricPaladin Variants 0 February 17, 2008 06:38


All times are GMT +1. The time now is 03:56.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.