3.1 - Tiles bug?

[pndrev]

I tried out the tilesets with 3.1, to see what they look like. I noticed that when using David Gervais tiles, the unexplored 'void' of the dungeon gets filled with the 'cloak' icon (brown cape-like shape). This does not happen with other tilesets, that correctly display empty blackness.

[takkaria]

I tried out the tilesets with 3.1, to see what they look like. I noticed that when using David Gervais tiles, the unexplored 'void' of the dungeon gets filled with the 'cloak' icon (brown cape-like shape). This does not happen with other tilesets, that correctly display empty blackness.

What OS and version are you using?

[Mondkalb]

Same bug occured with an earlier version of Angband, 2.9 or so, I think.

[pndrev]

Vista 32, all updates / SP. German locale.

Angband 3.1.0 rc1099, edited win-prf for # as walls.

[andrewdoull]

I tried out the tilesets with 3.1, to see what they look like. I noticed that when using David Gervais tiles, the unexplored 'void' of the dungeon gets filled with the 'cloak' icon (brown cape-like shape). This does not happen with other tilesets, that correctly display empty blackness.

Ah. One of my favourite bugs. This occurs because the Windows port (and perhaps the underlying Angband code IIRC) makes the assumption that graphics tile (0,0) is the blank tile in various parts of the code. However the Gervais 32x32 tile set violates this assumption.

Historically this manifested itself as transparent graphics tiles ended up having the cloak as the background.

I just fixed it by moving the cloak to a new position, and setting the (0,0) tile to the background. I was never able to convince Robert Ruehlmann of the necessity of doing this...

Andrew

[takkaria]

Ah. One of my favourite bugs. This occurs because the Windows port (and perhaps the underlying Angband code IIRC) makes the assumption that graphics tile (0,0) is the blank tile in various parts of the code. However the Gervais 32x32 tile set violates this assumption.

Historically this manifested itself as transparent graphics tiles ended up having the cloak as the background.

I just fixed it by moving the cloak to a new position, and setting the (0,0) tile to the background. I was never able to convince Robert Ruehlmann of the necessity of doing this...

Does this mean I could just steal the UnAngband 32x32 tiles to avoid doing the work myself?

[Lebannen]

While I've replicated this in 3.1.0beta on Crossover, I've taken a look at 32x32.bmp and the top-left tile is still black. Even weirder - it looks like 3.0.9b uses the exact same bitmap, and that doesn't exhibit the issue...

[pndrev]

Yep, 3.0.9 worked fine.

[andrewdoull]

Yep, 3.0.9 worked fine.

Is it a possibility that the tile masks for PNG graphics included the original cloak mask on the blank tile?

Andrew

[Jungle_Boy]

My thought is that there was a fix made for the fact that the darkness was not at position one. Then the darkness was moved to position one and there was something in 3.09 that accounted for this. Then 3.1 came out with the original fix but not whatever they had in 3.09 so maybe the fix is fixing a problem that is not there and unfixes it

[pndrev]

Interesting: Copying the [Un] graphic set leads to the same problem, just with the blue cloak. Both blue and brown cloaks are in the 0,1 position in their respective tilesets, while 0,0 is the (correct) blank tile.

([Un] itself shows solid walls where blank space should be, btw.)

[Jungle_Boy]

I altered the graf-dvg.prf file so that the darkness line is:

# <darkness>
F:0:0x80:0x79

This seems to fix it as long as you are not using bigtile mode. If you are it only redraws half the tile.

[buzzkill]

This seems to fix it as long as you are not using bigtile mode. If you are it only redraws half the tile.

I do use bigtile, so I came up with another solution. I simple edited the 32x32.bmp and erased the cloak (colored it black). Cloaks still appear in the game as a black silhouette of themselves thanks to the mask32.bmp.

To take it one step further. Reassign the 'standard' cloak to another cloak graphic. You have 4 to choose from that aren't being used, 85, 86, 87 and 88.
Find graf-dvg.prf in your angband/lib/pref directory and change the following line. In this exapmle, I changed it to from 81 to 85.

### The Cloaks ###

[SIZE="3"][COLOR="Yellow"]K:cloak:Cloak~:0x80:0x[COLOR="Red"][B]85[/B][/COLOR][/COLOR][/SIZE]
K:cloak:Fur Cloak~:0x80:0x82
K:cloak:Elven Cloak~:0x80:0x83
K:cloak:Ethereal Cloak~:0x80:0x84

[buzzkill]

Edge of trap detection area bug (maybe)

Using Vista, DVG, Bigtile, 16x32, 12x20.fon

The edge of trap detection area appears as blackness. Whenever myself an enemy or an object is upon it, a dark elf (0x8d:0x81) appears behind our graphic (somewhat obscured by our graphic being place on top).

Even without the additional graphic bug, complete blackness is a bit much for the edge of trap detection area. May I suggest a simple black (or green) dot in the center of the tile.

[Jungle_Boy]

I do use bigtile, so I came up with another solution. I simple edited the 32x32.bmp and erased the cloak (colored it black). Cloaks still appear in the game as a black silhouette of themselves thanks to the mask32.bmp.

To take it one step further. Reassign the 'standard' cloak to another cloak graphic. You have 4 to choose from that aren't being used, 85, 86, 87 and 88.
Find graf-dvg.prf in your angband/lib/pref directory and change the following line. In this exapmle, I changed it to from 81 to 85.

### The Cloaks ###

[SIZE="3"][COLOR="Yellow"]K:cloak:Cloak~:0x80:0x[COLOR="Red"][B]85[/B][/COLOR][/COLOR][/SIZE]
K:cloak:Fur Cloak~:0x80:0x82
K:cloak:Elven Cloak~:0x80:0x83
K:cloak:Ethereal Cloak~:0x80:0x84

Very good idea, I ended up copying the coak tile over the tile at position 85 and then doing this.