Angband 64 x 64 pixel tileset

[Shockbolt]

The legal status of the game is uncertain.

That said, I don't think your tiles would be a problem per se (unless you actually somehow use a picture from one of the movies or something). Rather the game itself may fall foul of copyright.

I trust there's no use in asking the copyright holders either

[d_m]

So here's what I'm suggesting: as you are adding the PNG support, do you think there is a way to add single tile support also to Angband and in doing so, I would be able to painstakingly paint each and every single tile in it's own way for the game? As a default, items that currently share the same tile could get the same reference to a tile, and I would manually rewrite that as I go along adding my tiles for Angband.

That sounds reasonable to me. I'll open a ticket about it.

[buzzkill]

I'm going through the text files with all the items, artifacts and npc's here now. It does confirm my thoughts that many items share the same tile ( I never really gave that any thoughts back in the days when I played Angband myself) , take cloaks and gauntlets for example: the artifact textfile has several references to unique gauntlets, yet the tilesheet does not have more than a few different gauntlet tiles.

So here's what I'm suggesting: as you are adding the PNG support, do you think there is a way to add single tile support also to Angband and in doing so, I would be able to painstakingly paint each and every single tile in it's own way for the game? As a default, items that currently share the same tile could get the same reference to a tile, and I would manually rewrite that as I go along adding my tiles for Angband.

I don't see what advantage single tile support gains us if I'm understanding it correctly. That is, each tile in it's own individual file.

Each item in the game having it's own unique tile can be accomplished now using our current format. Artifacts, except for the lights, have never had their own graphics else they would be obvious on sight/detection. Am I missing something? Generally once artifacts are ID'd they are in the pack/wielded/at home/sold/or destroyed, none of which require a graphic as they aren't seen.

I'm not at all opposed to this, I just don't see the need.

What I think would be cool is if individual enemies could have more than one tile (different weapons/poses). So a grouping of cave orcs wouldn't have to all be exactly identical, or even different tiles to reflect status effects (hasted/slowed/poisoned/sleeping).

[Shockbolt]

I don't see what advantage single tile support gains us if I'm understanding it correctly. That is, each tile in it's own individual file.

Each item in the game having it's own unique tile can be accomplished now using our current format. Artifacts, except for the lights, have never had their own graphics else they would be obvious on sight/detection. Am I missing something? Generally once artifacts are ID'd they are in the pack/wielded/at home/sold/or destroyed, none of which require a graphic as they aren't seen.

I'm not at all opposed to this, I just don't see the need.

What I think would be cool is if individual enemies could have more than one tile (different weapons/poses). So a grouping of cave orcs wouldn't have to all be exactly identical, or even different tiles to reflect status effects (hasted/slowed/poisoned/sleeping).

Diversity, and progress, that is why I suggested the improvements above. Single tile support would mean you would have no need for tile pickers, and changing a tile would be easier than anything if they were stored separately.

*added a few lost words, that's tiredness does to you *

[buzzkill]

Diversity, and progress, that is why I suggested the improvements above. Single tile support would mean you would have no need for tile pickers, and changing a tile would easier than anything if they were stored separately.

I see. It would make things easier. I often come up with a bunch of tiles and then it takes forever for me to muster up the will to actually add them to the tilesheet.

It could also render the graphic .prf files obsolete, save for flavored items (I think).

[Blue Baron]

Personally, I prefer the tileset. It is more work up front to get the tiles into the game, but less work for the game itself. Only one file to load and worry if it is correct or not. Also, using the tileset will run faster than the method that I can think of for single tile support.

I looked through TOME4's code a bit, but I didn't see the part where it decides what image to use, so I can't estimate speed differences. (or try to implement)

(I am thinking of a list, hash table or LRU queue of bitmaps with their id and rectangle. The id might be the attr/char pair. However searching through the list, table, or queue for every tile, every time it is drawn, and setting it up to draw, might slow the game down too much.)

As long as everyone is asking for stuff, I would like to see something like the grid_data structure passed to term_pict_xxx, so a platform can see the raw data and do what it needs to. I would also like to see a pair of lines like "else if (streq(b+1, "GENDER"))\n v = p_ptr->sex->title;" around line 566 of prefs.c, for the possibility of gender specific player character tiles.

[Shockbolt]

More tiles, vermin and whatnot encountered in the depths of Angband

[andrewdoull]

Diversity, and progress, that is why I suggested the improvements above. Single tile support would mean you would have no need for tile pickers, and changing a tile would be easier than anything if they were stored separately.

Um. I don't see how single tiles per file stop you need a tile picker. You still have to say somewhere use this file for this monster...

[DarkGod]

Um. I don't see how single tiles per file stop you need a tile picker. You still have to say somewhere use this file for this monster...

Yes, in the monster definition file, you assign image names there so that shockbolt don't have to bother with them.
You can even make the image name be automatically made from the monster name, lowercase it, replace all non alphanumerics with _ and add .png at the end

[Blue Baron]

Yes, in the monster definition file, you assign image names there so that shockbolt don't have to bother with them.
You can even make the image name be automatically made from the monster name, lowercase it, replace all non alphanumerics with _ and add .png at the end

I am working on support for Angband pref files in the tile picker I wrote for myself. After I do, I can extract the angband pref file support and write a program that uses the names from the edit files to build a filename like you suggest, load the file, and copy the contents of the file to a tileset file at the coordinates from the pref files. Someone will still have to assign the coordinates in the pref file, but it will only have to be done once per entry.

The directory of shockbolt's tiles from TOME beta 28, without the oversized terrain tiles, it about 8.3MB, the compilation of those tiles that I put together for shockbolt was "only" 6.2MB. I think the performance loss, in load time, execution, and downloading, outweigh the convenience of the individual tiles. Especially when I can write a tool that restores most of that convenience.

I will post the source of the above on this forum when it is ready (it might be a while). I will include with it the source to a tool I have already extracted from my tile picker that will pre-multiply the color with the transparency in a png file.

Shockbolt: In the meantime, if you want to, you can make the tiles available (with the names as above, so I know where they go and to test the above tool) and I will add them to a tileset for you.

If anyone is interested in my tile picker, you would be welcome to use/redistribute the (Win32) executable under the terms of the Angband dual liscence, but I am not going to release the source to it anytime soon. I am not going to release the source because of some utility functions I use in it, and no open source code is used in it. When I rewrite/replace those utility functions, I will release it's source, but it won't be anytime soon.

Edit: as always, great tiles

[DarkGod]

Yeah 2MB is a terrible thing in this day and age
Actually TE3 now also supports loading from tilesets taht can be regenerated easily with a simple script and support is transparent: if it knows the tile is in a tileset it'll use it and if not it will load from a single tile file.
I have however found the speed gain to be minimal at best so ..

(But then TE4 loads data on a need to use basis, it doesnt preload everything)

[Blue Baron]

Yeah 2MB is a terrible thing in this day and age

umm an unnecessary 33% might be.

Actually TE3 now also supports loading from tilesets taht can be regenerated easily with a simple script and support is transparent: if it knows the tile is in a tileset it'll use it and if not it will load from a single tile file.
I have however found the speed gain to be minimal at best so ..

Actually, this seems like what I was visualizing a few posts above. (storing a pointer to a bitmap and a rectangle in that bitmap in a table.) What I am visualizing would have similar performance whether its using individual tiles or mixed individual/tileset tiles. The slowdown in execution that I see is in accessing this information. It seems like you are storing the filename in the core monster structure in TOME? In Angband, it would need another lookup and verification of the data and failure tests/ fallbacks. (If you suggest adding the data directly to to core structure, please keep in mind that the dev team wants to separate the core and ui more.) The users who would use the 64x64 tiles probably would not notice the performance hit, possibly 32x32 users too, but what about those using 16x16, 8x8, nomad's, and the retro tileset being made?

(But then TE4 loads data on a need to use basis, it doesnt preload everything)

Yeah that would be a big difference. But for Angband I don't see the need to write the code that will do the same effect as is currently done with less performance. (however minor the performance loss might be for some users). I understand Shockbolt's desire to not want to edit the pref files or build the tileset, that is why I am willing to write a tool to build the tileset. If the gervais format is used, the pref file won't need to be changed. (That same desire is why I wrote my tile picker in the first place for Z+.)

Edit: changed some wording.

[DarkGod]

umm an unnecessary 33% might be.

Well we all have our idea about that, making it a % wont change a thing, it is nothing IMO

Actually, this seems like what I was visualizing a few posts above. (storing a pointer to a bitmap and a rectangle in that bitmap in a table.) What I am visualizing would have similar performance whether its using individual tiles or mixed individual/tileset tiles. The slowdown in execution that I see is in accessing this information. It seems like you are storing the filename in the core monster structure in TOME? In Angband, it would need another lookup and verification of the data and failure tests/ fallbacks. (If you suggest adding the data directly to to core structure, please keep in mind that the dev team wants to separate the core and ui more.) The users who would use the 64x64

Why would adding a "tile id" to the core make is less split ?
It is exactly the same thing as having 'D' YELLOW in the core, and I dont see that moving out anytime soon. Just have a tile id like "mature_multihued_dragon", the the UI code will interpret it as it likes, it could try to load mature_multihued_dragon.png, it could check in a table if this ID corresponds to a tileset, ... (hell it could even be used to take out the char/attr pair).

tiles probably would not notice the performance hit, possibly 32x32 users too, but what about those using 16x16, 8x8, nomad's, and the retro tileset being made?

I don't see how that can make any difference, if you mean you would have to loop through a list for each tile each redraw to find the imagine, yeah this is obviously wrong. You'd use a hashtable, or a display cache, there is no reason for it to be slower.

Yeah that would be a big difference. But for Angband I don't see the need to write the code that will do the same thing for the users with less performance. (however minor it might be for some users). I understand Shockbolt's desire to not want to edit the pref files or build the tileset, that is why I am willing to write a tool to build the tileset. If the gervais format is used, the pref file won't need to be changed. (That same desire is why I wrote my tile picker in the first place for Z+.)

Oh I'm not trying to tell you how angband should do it, just saying that there are other ways to do work too

[Blue Baron]

Well we all have our idea about that, making it a % wont change a thing, it is nothing IMO

It is up to them, but I feel that a 33% increase in bandwith (well actually around 20%, with all of the other files) should matter to the ones who are providing the files to us for free. I also think a probably more than 33% increase in load time would matter to the users. but thats IMO. If I had something to compare it to, I would definately notice.

Why would adding a "tile id" to the core make is less split ?
It is exactly the same thing as having 'D' YELLOW in the core, and I dont see that moving out anytime soon. Just have a tile id like "mature_multihued_dragon", the the UI code will interpret it as it likes, it could try to load mature_multihued_dragon.png, it could check in a table if this ID corresponds to a tileset, ... (hell it could even be used to take out the char/attr pair).

Because it's not a tile id, but a specific filename for a specific graphics mode? Also, the checks that you mention are exactly what I think would be added for no gain(again increasing load time). about the char/attr pair, I think the ascii users are the majority of current angband users? Actually I would like it if the dev team were to do something like this, though I would want a pointer to void in the core structures that would be "owned" by the platform, that would be passed to the platform in term_pict_xxx, so there wouldn't need to be a table lookup. However, both of these do make the core less split, IMO.

I don't see how that can make any difference, if you mean you would have to loop through a list for each tile each redraw to find the imagine, yeah this is obviously wrong. You'd use a hashtable, or a display cache, there is no reason for it to be slower.

umm even a hash_table lookup takes time, and I disagree with adding any of it for the same result as the current implementation.

Oh I'm not trying to tell you how angband should do it, just saying that there are other ways to do work too

err I'm not trying to tell the dev team how to do it either, just what I think improves Angband, just like you.

[DarkGod]

[QUOTE=Blue Baron;55585]It is up to them, but I feel that a 33% increase in bandwith (well actually around 20%, with all of the other files) should matter to the ones who are providing the files to us for free. I also think a probably more than 33% increase in load time would matter to the users. but thats IMO. If I had something to compare it to, I would definately notice.

Because it's not a tile id, but a specific filename for a specific graphics mode? Also, the checks that you mention are exactly what I

Why would it be ? "clear_icky_thing" doesnt look specific to a graphic mode, the UI takes it and interprets it as it likes, it jsut so happens that tilesets can be made to use those ids directly.

think would be added for no gain(again increasing load time).

You'd need to do about two thousands or so lookup on start, seriously not even a 286 would choke over that.

about the char/attr pair, I think the ascii users are the majority of current angband users?

Well probably yes since the tilesets are not too good

err I'm not trying to tell the dev team how to do it either, just what I think improves Angband, just like you.

Ah sorry thought you were on it