FAangband - 64 x 64 graphics

[Shockbolt]

The long intro text can be read here: http://angband.oook.cz/forum/showpos...29&postcount=1

The short intro text is as follows: Assuming FAangband is a non-profit game, the following tiles posted in here can be used freely within FAangband and other Angband variants as long as they continue to stay non-profit versions.

The tiles painted for FAangband is likely to be added into the tilesheet being constructed for Angband V these days.

Should FAangband want to go commercial, a non-exclusive license will have to be acquired in order to continue using the tiles. I'm not doing this to be an ass, I do it simply because I think it is "unfair" to have my tileset used for free if you aim to make money from your game.

[Nick]

Brilliant, thanks - I'll put together a list of the extras needed some time soon.

As far as the licence goes, FAangband will become a paying game over my lifeless corpse.

I assume you're also OK with the tiles being used for my fork of FA, Beleriand? That may also add a little terrain, but it will probably also be largely a subset of what is needed for NPP.

[Magnate]

Can anyone else see this turning into shocklib, the tiles library for angband and its variants?

[Shockbolt]

Originally Posted by Magnate

Can anyone else see this turning into shocklib, the tiles library for angband and its variants?

Single tile library, arranged in folders and subfolders?

[andrewdoull]

Originally Posted by Nick

As far as the licence goes, FAangband will become a paying game over my lifeless corpse.

It's worth pointing out that Nick lives within half a days drive of me, and there's a lot of desert around to hide bodies in...

[nppangband]

Originally Posted by Shockbolt

Single tile library, arranged in folders and subfolders?

That sounds great. It would make it much easier to add new tiles rather than the current system. I would code it if I knew how. Maybe this question should go on the development folder, but what changes would have to happen to that each tile was it's own file?

[Zyphyr]

I haven't actually looked at the code, but I imagine each in a seperate file would result in simpler code - no need to break down the images internally. On the other hand, it would increase both memory and HD storage space due to each tile/file having its own overhead. That is presumably why the current system was implemented in the first place.

[Magnate]

Originally Posted by Zyphyr

I haven't actually looked at the code, but I imagine each in a seperate file would result in simpler code - no need to break down the images internally. On the other hand, it would increase both memory and HD storage space due to each tile/file having its own overhead. That is presumably why the current system was implemented in the first place.

Yes, but all those years ago both RAM and HD space were a whole lot tighter bottlenecks than they are now.

I've been thinking about this quite a bit - I think we need to stay clear of using any kind of index numbers. To specify exactly what each tile represents, we should use a system like

size-word1-word2.png

For monsters, word1 is taken from monster_base.txt, and word2 is the monster name from monster.txt

For objects, word1 is taken from object_base.txt, and word2 is either an sval (from object.txt) or an artifact name (from artifact.txt) or a flavour (from flavour.txt).

We probably also need a word1 "meta" for tiles which are neither objects nor monsters, e.g.

32x32-meta-pile.png
32x32-meta-unknown_object.png
32x32-meta-trap_border.png

etc. I guess we'll need to turn spaces in names into underscores, and dispense with the single quotes in artifact names.

This way anyone can contribute a single tile by calling it

32x32-sword-dagger.png
64x64-dragon-baby_green.png

or whatever.

It will certainly take up a lot more disk space, but it should be considerably more flexible for adding and changing individual tiles.

Thoughts?

[Shockbolt]

object_food_beef_jerky_1.png

object_food_ration_1.png

object_artifact_phial_of_galadriel_1.png

trap_spell_rune_of_teleportation_1.png

terrain_wall_dungeon_lower_1.png (bottom of the 2.5D wall)

terrain_wall_dungeon_top_1.png (top of the 2.5D wall, the part that would render partially ontop of player/npc/any object that was standing to the north)

terrain_floor_dungeon_1.png

weapon_sword_falchion_1.png

dragon_ancient_multi_colored_1.png

spiderkin_unique_ungoliant_1.png

spiderkin_spider_mirkwood_spider_1.png

Then either have the code downsize the graphics from 64x64 to 32x32 or smaller, or stick 64_ or 32_ to either the beginning of the file or the end of the file. Obviously, having the code downsize the graphics from 64 to smalles would mean a smaller .zip to download for the players.

As you see, I've ended each file with _1 , incase I go mental and decide that I want to make many versions of the same tile. This would be somewhat fun, as you could then call for the image of a broken sword, a rusty sword, a new sword, a sword that has flames running up it's blade, a sword with dripping poison etc.

[buzzkill]

Originally Posted by Magnate

I think we need to stay clear of using any kind of index numbers.

Why? Doesn't everywhere else else use index numbers?
Without much thought put into it, something like this...each tile size gets it's own folder, each tile type gets it's own sub-folder, each tile is named by index number plus descriptive name (just for ease of editing, doesn't need to be exact).

Thus 32x32/monsters/001-Filthy_Street_Urchin.png and 32x32/monsters/001-FSUrchin.png and 32x32/monsters/001.png would access the same tile.

Admittedly, I've no idea of the advantages/disadvantages of multiple folders, long file names, etc... anything really.