Notes |
(0012055)
ghend (reporter)
2011-04-02 18:57
|
Actually, with further testing it doesn't seem confined to orcs. 99 everything seems to flash into artifacts. |
|
(0012066)
jpeg (manager)
2011-04-02 19:34
|
It only appears to happen with monsters that use equipment, e.g. snakes, rats and cockroaches (vermin exterminators, rejoice!) appear to work fine. So does Sigmund, which leads me to the conclusion that the common denominator is that all these monsters have got a wielded weapon drawn onto their tile. Not all monsters wielding a weapon are affected, but those not wielding a weapon invariably aren't.
Also, once a couple of those humanoid monsters get killed, the odd tiles disappear, so the large number of them also plays a role. It doesn't have to be the same type of monsters, i.e. "33 hobgoblin, 33 orc, 33 gnoll v 33 ogre, 33 kobold, 33 goblin" shows the same result. |
|
(0012069)
jpeg (manager)
2011-04-02 22:44
|
Extending my previous observations, this only affects cached monster tiles, that is monsters that get their weapons displayed and presumably also ghosts and panlords (though I haven't tested that).
What happens is that in tileview.cc:699, tile_place_monster(), the monster is added in the cache registry. The returned value is then modified by any applicable flag to form the new tile value. Later, when the tile needs to be drawn, it is split into the base tile (t & TILE_FLAG_MASK) and the flag part (t & (~TILE_FLAG_MASK)). However, if the value returned by mcache.register_monster(mon) is greater than 2047, then (t & TILE_FLAG_MASK) loops around and starts back at zero.
Since TILEP_MCACHE_START currently resides at 1851, this leaves space for 196 cached monsters within los; all monsters beyond that value use item tiles instead. Apparently, the cache is recalculated anew every turn, but there still might be a connection to those tileref assertions we get occasionally (maybe if the same mcache index is shared by several monsters). I also don't understand what causes these odd flips where monsters are displayed properly at one point, and then shift to artefacts, and then back to monster tiles - all without a single monster leaving or entering los.
Apparently, tileidx_t being unsigned int is too small... |
|
(0014012)
dolphin (reporter)
2011-07-29 23:06
|
A friend was playing a priest of Beogh on -b1-29-gc0c5ec4 yesterday and saw the same thing after running into a large room of orcs. Just FYI. |
|
(0015281)
XuaXua (reporter)
2011-10-18 06:45
|
I can confirm this is happening in crawl_tiles-0.10-a0-1305 with my orc priest of Beogh
Screenshot attached. |
|
(0016157)
Stormphoenix (reporter)
2011-12-07 21:53
|
Also happening to me with large numbers of equipped orcs on Webtiles 0.9. |
|
(0016412)
edlothiol (developer)
2011-12-28 15:50
|
OK, I looked a bit more into this. The flipping happens because while the mcache entries for monsters in LOS are recreated on every viewwindow(), they can't reuse the same indexes because the old index for a monster is only freed _after_ its new mcache entry has been created (since the old index is freed when the new index is assigned to tile_fg). So the mcache indexes for the monsters basically flip between two values on every redraw.
I'm really not sure how to fix this. One additional bit for TILE_FLAG_MASK would probably fix this for a long while, but it doesn't seem like we have room for it, and there should be a better way anyway. |
|
(0016530)
Bubu (reporter)
2012-01-05 04:10
|
I encountered this also with webtiles 0.9. Screenie attached. |
|
(0018130)
edlothiol (developer)
2012-05-24 17:15
|
Fixed in 4537fb6. |
|