Reviving Iso-Angband, an isometric view addon for Angband

[buzzkill]

No, the (DG) tiles are not restricted to 16 potions (in Angband 3.1.2 I should add, I have not looked into older versions with tiles), so there could potentially be one tile for each description of a potion (I think some tiles are assigned to more than one type of potion still, but there are more than 16). For wands, staves etc there only exist ~8 tiles for each so they are used for more than one type each (e.g. birch staff and pine staff might look the same) but I believe this is more due to lack of tiles than any restriction on how many you can define.

I'm fairly sure this is all correct. New staff flavors were recently added to DaJ and it was easy enough for me to create new tiles for and include them by simply editing the prf files.

The DG tiles are highly recognizable. Being familiar with then, I can play with a bare minimum of (l)ooking, or without (l)ooking at all. Most of my looking is to access monster recall, or check HP/status effects, hardly ever to actually identify the enemy.

I was just suggesting the DG tiles as a shortcut to completion because you seemed to imply that creating tiles was becoming a burden... and I know how that feels.

[Hajo]

Some day I'll try updating to a recent Angband version. I think many of the old restrictions have been lifted. I fully agree with the idea to be able to identify things just by their looks.

For the time being I try to get unique shape+color combinations, but the old code seems limited to 16 mappings for the magic items each. So until an upgrade or a patch, I can't do much. Monsters and other items I can map freely and see to have them unique in appearance.

Thanks for letting me know what is important for you in a graphical display

[thapper]

No, the (DG) tiles are not restricted to 16 potions (in Angband 3.1.2 I should add, I have not looked into older versions with tiles), so there could potentially be one tile for each description of a potion (I think some tiles are assigned to more than one type of potion still, but there are more than 16). For wands, staves etc there only exist ~8 tiles for each so they are used for more than one type each (e.g. birch staff and pine staff might look the same) but I believe this is more due to lack of tiles than any restriction on how many you can define.

Anyway, one of the main reasons for me wanting to play with tiles is the possibility to recognize everything just by looking at its tile. If I can know what something is by using the 'l'ook command, I should be able to do it by just looking at its tile. I can't do this with the ascii characters (for instance several different age groups of dragons share the lower case 'd' etc).

[Hajo]

Thanks for the info on David Gervais' tileset. I really haven't looked at any updates since some time in 2003 ...

For me this makes a lot more sense than keeping the strict symbol+colour relationship that is inherited from ascii. I like the fact that mages look more like mages (with some silly colour effect around their hands) and rangers look more like rangers instead of them sharing the same shape just because they are share the same letter in ascii.

A few groups I have split up already. Persons have now quite many pictures, maybe too many. The dungeon inhabitants are roughly grouped into warriors, mages and priests. Townspeople are manifold ...

It is sometimes difficult to draw the line, what to group and what to split. If there is sufficient distinction I lean towards splitting. They way it is done, the code supports 1024 symbols now, instead of the 96 ASCII symbols, so there is some room for introducing new symbols.

If you then choose to have the same shape for a novice ranger and a ranger chieftain (and just change their colour) or if you decide to give them different shapes but clear attributes that define them as "rangers" (and therefore dangerous with ranged attacks) is not important.

Rangers share their image with archers (the bow seemed to be the defining characteristic), but are distinct from other people. People in general need more sorting though, I think, particularly the unique persons which are mostly just "p" still.

For the orcs I have given the captains/chieftains a different image (although I haven't tested yet if this works well). Orcs have been a fairly big group already.

Keep on going with what you think is the best approach, I look forward to more updates with more tiles!

Thanks for the encouragement Feedback is good though, particularly if it helps to improve the "readability" of the display, also the ease of learning the shapes. And last but not least, the to hear about the wishes and impressions of the players.

(By the way, just out of curiosity, for the potions, are you planning to have the small tile picture that you had (at least a week or so ago) and just change its colour? It'll be quite difficult to keep apart all the 50 odd different ones... Even with allowing some different shapes it's a mess trying to remember which potions are good and bad just from looking at them.)

At the moment the potions look all the same, just differently colored. I think this is a limitation of the Angband core though (at least of 2.9.3), which allows only 16 mappings for potions in a pref file. I think it was intentional that the player cannot tell too much about a potion from the color.

# Potions (!)
S:0xE0:0x90/0x81
S:0xE1:0x91/0x81
S:0xE2:0x92/0x81
S:0xE3:0x93/0x81
S:0xE4:0x94/0x81
S:0xE5:0x95/0x81
S:0xE6:0x96/0x81
S:0xE7:0x97/0x81
S:0xE8:0x98/0x81
S:0xE9:0x99/0x81
S:0xEA:0x9A/0x81
S:0xEB:0x9B/0x81
S:0xEC:0x9C/0x81
S:0xED:0x9D/0x81
S:0xEE:0x9E/0x81
S:0xEF:0x9F/0x81

This also applies to wands, staves, and scrolls. There are mappings of 16 definitions for each which are randomly assigned in each new game. I'd suspect that this mapping restriction also applies to "real" tile sets, and they can't have more than 16 visual variations for potions either?

If I look at this I wonder a bit ... Angband had only 15 colors and black, and currently the iso view works the same, so one of these must come out as a purely black shape without any contours or details. I haven't seen that problem though in my tests. Maybe I was just lucky.

I was wondering if I could define a color range for the otherwise unused color 0 ... but that is a different discussion. People suggested to have a unique color for all unique monsters, so maybe that could be an idea. of have special treatment for multi-hued monsters.

[thapper]

In a way you are right, the David Gervais tiles are not keeping the symbol+colour duality in a strict sense but, IMHO, they do keep it to a large degree.

For example, a white dragon looks exactly as a red dragon, only coloured in white shades instead of red shades. Hounds look in principle identical (changes only in left/right direction and minor details in their tails) but are coloured differently.

For other symbol groups things change more, trolls look quite different between themselves but they all keep a "trollish" look, defined by the shape and look of the head, and their general body shape. This is the case for most humanoids, demons, undead. They have a feature that define them as a group, most of the time how the head look, and they change attributes such as which weapon they have, or their colour, or something else.

For me this makes a lot more sense than keeping the strict symbol+colour relationship that is inherited from ascii. I like the fact that mages look more like mages (with some silly colour effect around their hands) and rangers look more like rangers instead of them sharing the same shape just because they are share the same letter in ascii.

If you then choose to have the same shape for a novice ranger and a ranger chieftain (and just change their colour) or if you decide to give them different shapes but clear attributes that define them as "rangers" (and therefore dangerous with ranged attacks) is not important.

Keep on going with what you think is the best approach, I look forward to more updates with more tiles!

(By the way, just out of curiosity, for the potions, are you planning to have the small tile picture that you had (at least a week or so ago) and just change its colour? It'll be quite difficult to keep apart all the 50 odd different ones... Even with allowing some different shapes it's a mess trying to remember which potions are good and bad just from looking at them.)

[Hajo]

I can't give a clear answer. Maybe I just don't know the right things, so I could not make the proper decisions.

Scaling bitmaps always comes with a quality loss. But I think that the idea basically would work. At least for monsters and items. Terrain and dungeon features like doors and stairs must be adapted, but most likely can be taken from existing isometric tile sets. David Gervais has made a pretty good one I think.

For me, personally, one of the "defining" points in roguelike display was the duality of symbol and color. The symbol defined the group or category which the thing in question belongs to, and the color identified the individual specifics of the thing inside the group.

I must admit when I restarted this project I have not checked the currently available tile sets. So maybe there is already everything there, and I just don't know it.

I was under the impression, though, that the tile sets give up the duality of symbol and color, and try to go for symbols that are individual identifiers. A fire dragon looks differently from a frost dragon, not only that it is red instead of blue, but they have just different pictures. And I was under the impression that in some cases the pictures are hard to tell apart. I might be pretty wrong in this assumption, since it's based on knowledge from about 10 years ago, and maybe even older.

The iso display code should support the "individual picture" approach, at least it did in the past, and even if currently not active it should be easy to restore the function. With that, it should be quite doable to take a sprite sheet, scale it to the right proportions, split it into the right input files for the iso view, write a proper pref file, and, done.

Right now the view is configured as a "text mode" display though. While the (traditional) graphical frontends use the attr+char values to form a 14 bit integer that is the tile number inside the set, the current iso code uses the lower four bits of attr as color, like the text mode displays do. The upper 3 bits of attr and the 7 from char form a 10 bit integer which is the tile number. Like having a "symbolic font" with 1024 glyphs.

The tile/glyph is then drawn in the color that the object has assigned in the pref files.

(The 8th bits from attr and char are not really usable, thus the odd 7 bit and 3+4 bit splits).

I want to keep the "symbol+color" duality. Even the idea to have abstract symbols. I just want a tiny change.

ASCII are non-symbolic abstractions, since their shape is not representing their meaning. I try to change that into symbolic abstraction, with shapes that have a meaning. But I want to keep a fairly abstract display with the shape telling the category of the thing, and the color telling the individual type within the category.

This is why I haven't tried to work with the old tiles. They are not abstract enough, and they are not suitable for the re-coloring approach. But overall this is just a matter of taste, and not a technological problem.

[buzzkill]

Maybe this is a stupid question but... why not just resize/edit the Vanilla tile set for use with ISO?

[Hajo]

Progress has slowed down, which might have many reasons, but one of them is, that I have become a bit bored again with Angband. To counter that I've started to work on a personal Angband variant, but again, this leaves less time for Iso-Angband with the vanilla core.

But a few things were done, still. At least all images and the image configuration are shared between the projects, so progress in one is also progress for the other:

- Line archer/ranger image.
- Fixed novice paladin config.
- Slightly improved centipede image.
- Image config for edible mushrooms.
- Ball and chain image and config.
- Whip image and config.

Ball-and-Chain, Whip, Edible Mushroom:

[Hajo]

Thanks, makes me happy to hear that

I did more testing in regard to the (l)ook function crash, and at least in the scenario where the crash had happened in my testing game it is gone since the change. I've released a new version with this fix and no other changes.

Download:

http://www.funkelwerk.de/data/iso-angband/releases/iso-angband-0_2_8_5.zip

[nppangband]

The screenshots look amazing. This is truly great stuff. Well done.

[Hajo]

I had this crash in the (l)ook function again. This time I was able to debug it, and it seems there were illegal memory reads in "target_set_interactive_prepare" in file xtra2.c

I assume this has been long fixed in current Angband versions. Also the xtra2.c file much different from the version that Angband 2.9.3 had ... also maybe the problem only happens with "center view on player" option.

Anyways. I think I finally could fix this, and the next release will have the fix.

[Hajo]

I've assembled a new version. Besides a newly introduced image for cloaks, this version features signs for shop entrances. I always had troubles to memorize the 1-8 shop numbers, and the visual clues help me a lot:

Click for full size.

For Windows users, there is a precompiled executable included. Also two starting batch files, "start_small.bat" and "start_large.bat" which choose a smaller or larger font, and therefore start with a smaller or larger window.

Download:

http://www.funkelwerk.de/data/iso-angband/releases/iso-angband-0_2_8_4.zip

Sources and images are included as well. I did some changes to main-sdl.c and I think it should compile for Linux, too, but I had no chance to test that yet (try Makefile.isov-sdl for the SDL based code).

Thanks, d_m, for testing the compile on Linux, and the report about the problem in main-sdl.c!

Known bugs and problems:

http://www.funkelwerk.de/forum/index.php?topic=197.0

If you find a new problem, please let me know. Particularly misconfigured images.

[Hajo]

Good to know that it finally worked

I'll include the adapted main-sdl.c in the next release.

The rotation of the numpad against the display confuses me at times too. I have tried to configure the keymap differently, but I didn't get it right. I must learn more about the ways Angband interprets key presses first. If I cannot get it it to work, then a compass with the numbers displayed for the directions might give a visual clue.

[d_m]

OK, well I must have been doing something wrong.

I made the changes you specified to main-sdl.c and then ran that exact make command and everything turned out great.

One feature request would be an isometric number pad somewhere in a corner so that I could figure out which diagonal I need to use

[Hajo]

The directory was renamed to "iso". I don't think the main-x11.c module still works. It was not used since the very first Iso-Angband versions anymore, and the directory was renamed later. The SDL module replaced the X11 module at some point and was used for both Linux and Windows builds since then.

I'm a bit puzzled that the makefile did try to compile main-x11.c. It should not do that.

I'm using this to call make:

cd src
make -f Makefile.isov-sdl

I think I got the problems with main-sdl.c sorted. I have added

extern errr SDL_init_screen_cursor(Uint32 w, Uint32 h);
extern errr SDL_DrawCursor(SDL_Surface *dst, SDL_Rect *dr);

static errr Term_text_sdl(int x, int y, int n, byte a, cptr s);

Just below the other procedure declarations at the start of the file.

And I have changed the lines that triggered the compiler error to this:

static errr Term_pict_sdl(int x, int y, int n,  const byte *ap, const char *cp)
{
	term_data *td = (term_data*)(Term->data);

	if (!td->gt || !td->gt->face)
	{
		Term_text_sdl(x, y, n, *ap, cp);
	} else

I think the declaration inside Term_pict_sdl was a leftover from an older version where the procedure had a different signature.

I want to do some more tests, to be sure the changes have no bad effects. But I must get some sleep first.

Edit: I just noticed that the compiler call in your message differes from the one that my console shows:

gcc -Wall -O1 -pipe -g -D"USE_ISOV_SDL" -D"USE_ISOV"
-D"USE_TRANSPARENCY" -c main-sdl.c -o main-sdl.o

I'm just posting this because the defines are important to activate the right code blocks. Maybe there is more makefile confusion here.

Edit 2: The automake/autoconfig (?) code that came with the Angband 2.9.3 codebase most likely does not work with my sources. It is a remnant from my try to update the Angband 2.9.1 codebase to 2.9.3 and I haven't removed these files since I was not quite sure if they are needed. Actually I wanted to leave the Angband code as untouched as possible.