3.2 release candidate is upon us!

[Timo Pietilä]

Excellent, thank you for the update. We have only two known bugs left and then 3.2 can be released.

I have three which I thought I had made a track ticket but apparently I didn't. I'll make them now.

1. Game is slow for some reason when you use "overhead" term window and there is unseen monster activity nearby. That's noticeable at a degree that you know there is a monster nearby by the fact that game slows down at very early levels, not so much deeper in dungeon when there is always lots of monsters around.

2. Entire "overhead" -term window flickers when there is a visible monster with flicker on.

3. Stretched "Map" term window doesn't get properly updated, it leaves behind traces of areas that should not be there. To reproduce you need to "Look around" with look command, when you change sector in look-command same happens in map term window, and also when char passes sector border so that map moves to next position same happens.

1 and 2 might be related in that overhead view probably uses a lot of CPU to track monsters (even unseen ones) and refresh screen.

[PowerDiver]

1. Game is slow for some reason when you use "overhead" term window and there is unseen monster activity nearby.

I don't know what you mean by "overhead", but I could tell the difference running once and I think it was because there was a pit nearby. I was playing a warrior without any source of monster detection, so I cannot be sure. Might there be some call to refresh when a nearby non-visible monster gets a turn?

Maybe the current big coders are playing on machines less than 5 years old and cannot notice slowdowns as easily.

[Timo Pietilä]

I don't know what you mean by "overhead".

Term window with entire map visible. Names of those two are IMO wrong way around. Map shows you only part of the dungeon, and overhead shows entire dungeon.

[d_m]

Maybe the current big coders are playing on machines less than 5 years old and cannot notice slowdowns as easily.

I do most coding/playing on a netbook (1GHz atom processor, 1GB RAM) which is not huge but is certainly not an old 486.

I have been looking at the flicker code (although I think it may be platform-specific because it performed well in some tests I ran) but I should do more testing under WINE (it may relate to how main-win does refreshes, I'm not sure). I wasn't able to get serious slow-downs under SDL or GCU.

Does anyone else notice these slowdowns? If so, on which platform(s)?

I am not sure these issues will be able to be closed before 3.2 is out, but I will try to make sure they are in trac.

[Timo Pietilä]

Does anyone else notice these slowdowns? If so, on which platform(s)?

To get that start a new char, open a overhead term window, find a breeder and wake it up, then retreat to place where you can be safely while they move at the other side of the wall. Look how much time you use resting.

It isn't bad slowdown, not in modern computers, but it is slowdown that can actually be noticed, which is quite odd, considering how old this game is. It should run in modern computers so fast that no slowdown could possibly be perceivable.

It gets a lot worse if there is a flickering monster nearby. Actually it might require turning real-time flicker on, because I don't recall seeing that slowdown without it. Also switching to map term window instead of overhead window almost (but not completely) eliminates the slowdown.

[d_m]

To get that start a new char, open a overhead term window, find a breeder and wake it up, then retreat to place where you can be safely while they move at the other side of the wall. Look how much time you use resting.

It isn't bad slowdown, not in modern computers, but it is slowdown that can actually be noticed, which is quite odd, considering how old this game is. It should run in modern computers so fast that no slowdown could possibly be perceivable.

It gets a lot worse if there is a flickering monster nearby. Actually it might require turning real-time flicker on, because I don't recall seeing that slowdown without it. Also switching to map term window instead of overhead window almost (but not completely) eliminates the slowdown.

The breeder suggestion is good, I will summon one in a big room in debug mode and see what happens.

[PowerDiver]

I do most coding/playing on a netbook (1GHz atom processor, 1GB RAM) which is not huge but is certainly not an old 486.

I was playing on an athlon64 when I thought I noticed the slowing. A step up from a 486. I don't know how it compares to an atom.

[Magnate]

It gets a lot worse if there is a flickering monster nearby. Actually it might require turning real-time flicker on, because I don't recall seeing that slowdown without it. Also switching to map term window instead of overhead window almost (but not completely) eliminates the slowdown.

This is quite important - could you confirm whether there is any slowdown if the "flickering monsters" option is off?

I mostly play on a 5-year-old Compaq Evo N610c (1.8GHz P4), and I never see slowdown with SDL or x11 or gcu (despite *always* playing with the overhead view in a subwindow), but I never use flicker because it gives me a headache. I see horrible slowdowns with -mgtk, but that has nothing to do with nearby monsters, it's just the port.

[Jungle_Boy]

I noticed a couple issues with the most recently nightly.

1. I play with the gervais tiles and bigtile mode, (tile width 16x32) it looks like spell effects and shooting are not being displayed correctly. This only happens with bigtile, doubletile, and triple tile. With those options unchecked it displays correctly. Status effects suffer from the same issue in that they do not display in bigtile mode.

2. It looks like there are some highlighted tiles being left near the health bars that are not being redrawn correctly.

3. This may be an intended change but when you have a list up such as inventory and press 'e' to go to equipment the first press escapes out of the current list and the second press brings up the equipment window. Perhaps this is related to the macro issue in that some keypresses are being used to escape lists rather than pull up the correct one.

Also I'm excited to see fractional blows implemented since warriors are one of my favorite classes, it does make it a little difficult to calculate damage since the numbers aren't nice and round anymore. Perhaps we could add a damage/round number to the 'I'nspect screen?

*edit* I also forgot, with the show unique monsters in a special color option on they do not display correctly in tile mode but I think that is basically an ASCII option since they still display as purple in the monster list, which I like.

[PowerDiver]

This is quite important - could you confirm whether there is any slowdown if the "flickering monsters" option is off?

animate_flicker was no when I noticed the slowdown.

To me, it is no big deal, noticeable but not annoying. I would not categorize it as a bug that should block a release.

[Mimu]

1. Game is slow for some reason when you use "overhead" term window and there is unseen monster activity nearby. That's noticeable at a degree that you know there is a monster nearby by the fact that game slows down at very early levels, not so much deeper in dungeon when there is always lots of monsters around.

Hmm. From a programmer's point of view: if you have a constant delay between frames, but during some frames have to process AI for 200 monsters instead of 20, the former is obviously going to be theoretically slower.

This could be partially mitigated by a very simple fix that there's no reason not to throw in: add one extra variable to track how many milliseconds have passed since the last update, and subtract that from the delay per frame (capping at 0 or 1 milliseconds). It would smooth out things somewhat.

[ewert]

Having finished my mage, I think I will start coding stuff (for me ) again. Will try to do it more coordinated in git, so any major changelines are their own forks etc. so if any are liked it is easier to pick them one by one.

I peeked at the current gits, and it seems there are different stuff in taks and angbands gits. Is the angband/master currently (and in the future) considered to be the vanilla proper? So that is the git/branch that I will want to grab to start reapplying previous changes and coding new ones?

[Magnate]

I noticed a couple issues with the most recently nightly.

1. I play with the gervais tiles and bigtile mode, (tile width 16x32) it looks like spell effects and shooting are not being displayed correctly. This only happens with bigtile, doubletile, and triple tile. With those options unchecked it displays correctly. Status effects suffer from the same issue in that they do not display in bigtile mode.

2. It looks like there are some highlighted tiles being left near the health bars that are not being redrawn correctly.

3. This may be an intended change but when you have a list up such as inventory and press 'e' to go to equipment the first press escapes out of the current list and the second press brings up the equipment window. Perhaps this is related to the macro issue in that some keypresses are being used to escape lists rather than pull up the correct one.

Also I'm excited to see fractional blows implemented since warriors are one of my favorite classes, it does make it a little difficult to calculate damage since the numbers aren't nice and round anymore. Perhaps we could add a damage/round number to the 'I'nspect screen?

*edit* I also forgot, with the show unique monsters in a special color option on they do not display correctly in tile mode but I think that is basically an ASCII option since they still display as purple in the monster list, which I like.

It is indeed an ASCII option - I thought uniques had special tiles anyway? (You can tell I don't play with tiles.) If they don't, I wouldn't know how to go about colouring tiles, so someone else would have to implement that.

Yes, during the O-combat discussion I realised that damage per round is a whole lot more useful than damage per blow - that's why S displays it on the char screen. I'll make a ticket for that.

I think you may be right that the double-keypress thing is related to the macro problem. We'll see if they go away together ...

With 4 tilesets (each of which can be stretched in 2 directions) on 5 platforms there are so many issues with the display of various things in tile modes that there is no way we can fix them all. We will try and make sure that macros and inscriptions still work, but little visual glitches will probably have to wait.

[Magnate]

Having finished my mage, I think I will start coding stuff (for me ) again. Will try to do it more coordinated in git, so any major changelines are their own forks etc. so if any are liked it is easier to pick them one by one.

I peeked at the current gits, and it seems there are different stuff in taks and angbands gits. Is the angband/master currently (and in the future) considered to be the vanilla proper? So that is the git/branch that I will want to grab to start reapplying previous changes and coding new ones?

Yes, the canonical repository is the master branch of git://github.com/angband/angband - please fork all new work from that.

Takk's personal repo looks a bit different as he is in the middle of major rewrites to both the input layer and tile handling. Neither of these is for 3.2 though.

[Dean Anderson]

Hmm. From a programmer's point of view: if you have a constant delay between frames, but during some frames have to process AI for 200 monsters instead of 20, the former is obviously going to be theoretically slower.

This could be partially mitigated by a very simple fix that there's no reason not to throw in: add one extra variable to track how many milliseconds have passed since the last update, and subtract that from the delay per frame (capping at 0 or 1 milliseconds). It would smooth out things somewhat.

Frames in Angband don't work like that.

The only time constant delay between frames is used is when there is an animation occurring - for example a spell or arrow being fired. When that is happening, nothing else in the game is being done or modified; so it's just a case of draw current animation frame, delay, draw next animation frame, delay, and so forth...

When there isn't an animation being used, the game will update a single "frame" - which includes AI processing and other time intensive stuff - and then wait for a keypress before drawing the next one.

Actually, it is still possible to notice a delay in that situation. Let's imagine that you're not holding a key down, but pressing it manually every .5 of a second (500 milliseconds). If the system is running quickly, you might have the following situation (and I've made these numbers up):

Press Key -> 20ms processing -> 5ms screen refresh -> 475ms wait for next key.

But if the system is running slowly, you might instead get:

Press Key -> 270ms processing -> 5ms screen refresh -> 225ms wait for next key.

In either case, the total delay between keypresses is the same, but in the second one there will be a noticeable lag or "sluggishness" in the game's response time.