why is 4.2.2 so slow

[Sky]

Because clearly tiles are better ?

[Cuboideb]

The latest nightly builds, https://github.com/angband/angband/releases , include changes that avoid using Term_mark() for handling double-height tiles. The Windows, SDL, SDL2, and Mac front ends all make use of that. Feedback about whether that makes the performance with the Shockbolt tiles good enough or if more still needs to be done would be helpful, as would reports about any rendering artifacts.

Good work! It seems to work very well on windows. The only flickering I see comes from the grid occupied by the player.

Thank you!

Edit: if topbar is enabled double height tiles aren't cleared in row 3. Perhaps you could use ROW_MAP or something.

[Sky]

my early impression is that the delay is completely gone. I will let you know once i get near a big vault.

[backwardsEric]

Edit: if topbar is enabled double height tiles aren't cleared in row 3. Perhaps you could use ROW_MAP or something.

The front ends currently have a test of row > 2 when drawing the upper halves of double-height tiles, looks like that'll have to be generalized to handle if the topper is enabled.

[Cuboideb]

@backwardsEric - In screen_load, there is a call to Term_Redraw if tile_size > 1. I think this causes a flickering with spell casting keymaps (ie: maa').

I'm doing some playtesting after adding a check for !inkey_next to ignore keymaps. This is the proper way to handle this problem?

[backwardsEric]

@backwardsEric - In screen_load, there is a call to Term_Redraw if tile_size > 1. I think this causes a flickering with spell casting keymaps (ie: maa').

According to the history of ui-output.c, Nick added that clearing more than eleven years ago. He may remember the reason. I suspect it's there to redraw any tile whose upper left corner wasn't affected by whatever the screen_load() is trying to undo but whose padded area was damaged. Such a tile wouldn't be redrawn by the current logic in ui-term.c if I'm understanding it correctly.

I'm doing some playtesting after adding a check for !inkey_next to ignore keymaps. This is the proper way to handle this problem?

I'm not sure if your question is referring to how to ignore keymaps or to the flickering. For the former, I'll have to plead ignorance. For the latter, my guess, based on what I said above, is that the clearing still would be necessary in general. Would have to change ui-term.c to do some sort of checking for changes in the padded areas to be able to drop the clearing done in screen_load().

[Nick]

According to the history of ui-output.c, Nick added that clearing more than eleven years ago. He may remember the reason. I suspect it's there to redraw any tile whose upper left corner wasn't affected by whatever the screen_load() is trying to undo but whose padded area was damaged. Such a tile wouldn't be redrawn by the current logic in ui-term.c if I'm understanding it correctly.

It looks to me like that was 6 years ago; IIRC it was because I was despairing of other ways to stop leftover tile artefacts.

[Cuboideb]

Sorry, I was unclear. That line must be kept there. Otherwise, some dialogs aren't properly disposed (ie: the one triggered by the return key)

I'm playtesting this (added a check for inkey_next):

/* Redraw big graphics */
if (screen_save_depth == 0 && !inkey_next &&
   (tile_width > 1 || tile_height > 1))
   Term_redraw();

I think the flickering is produced by a flashing spell selection menu (seen in windows, android).

I must say I'm not completely sure about that change. I want to try with different keymaps to check proper behavior.

[backwardsEric]

There's a pull request up on Angband's GitHub page to add extra checks for changes in the padded areas of big tiles and trigger a redraw of the tile when changes are found. With that, the extra clear in screen_load() no longer appears to be necessary. The pull request removes it.

[Cuboideb]

Thanks! It looks great. I will test that when it arrives to the master branch.

[Nick]

OK, that's pulled in now.

[Cuboideb]

Thank you both. It works very well.