Game moving awfully slow

As of 0.A-259-ga33ee4f, the game moves slow. What I mean is, that one key press takes a few seconds to register. Multiple key presses result in moving in one lower than the number of key presses.

I’ve tried just playing Cata, nothing else open. Not working.

Menus work just fine though.

I’m getting the exact same problem.

Aghh… It’s still doing it.

Tiles or Curses? What OS?

I can’t seem to replicate this.

Tiles on windows 7. I think it has to do with large viewports for the game.

I agree, I am running the game on full screen 1920 pixels by 1088, using Windows 7.
Pressing a key will result in a quick flash in game showing hashtags on the black borders along the side, for less than a second. Also moving a square and then pressing “s” to save the game will revert my character back to the space before I moved. Loading the save game places me to the space I had originally moved to, however.

Actually, pressing any key will revert my character back to the past space. Examine, save, drop, grab, smash nearly everything.

I didn’t have any slowness problems in 0.A, but they are back with a vengeance in the experimentals.

I saw mentions on git that slowness might be related to viewport dimensions. Is it true?

I don’t think so, it happened to me with a 16x9 viewport, and the same with the default.

Windows 7 (x86)
Windows Tiles build ver. 0.A-559-g512efdd

Had to delete LANG folder (game thinks i am russian and CDDA have no RU translation, nor i want it to).
Had to download those 3 DLL’s (SDL2?) from this forum, otherwise game wasn’t loading.

Any size of window (from default to 158*61), any type of tilesets, even with tiles turned off - it takes around 100-500 ms for the game to register any keypress. Everything “lags” after a command:

  • typing name of item in any menu (like sorting inventory in AIS);
  • moving around;
  • opening any menues;
  • shooting, fighting, etc.

Have same problems with all 0.A builds, including initial “stable” one.
All 0.9’s, including all experimentals, works good without mentioned troubles.

P.S. This lag is especially noticable when trying to move cursor on the big map. Takes around 1000-1500 ms between keystroke and the actual move.

Dang Crador, that’s a nice bug report.

I, too, seem to be having this problem since the migration to SDL2. It seems to get worse the more tiles are drawn on screen. The easiest way to see that is to use the zoom function—when zoomed all the way out, each step can take 3-4 seconds.

Curses runs smooth as butter, and profiling with Valgrind seems to confirm that drawing is what causes the game to choke up with tiles. In fact, cataclysm-tiles with tiles turned off is still much slower than similar sized curses window. Tiles chokes up both when I download it from Jenkins, and when I build it myself (with or without the release flag, in 32 and 64).

I’m not sure whether this is something wrong with Cata or with my SDL2 installation and some other thing on my system. I’m running this on a laptop with a built-in Intel graphics chipset, so it’s not exactly the greatest graphics hardware, but it handled pre-SDL2 Cata versions with no complaints. One caveat: I’m running Linux, Ubuntu 13.10. 13.10 doesn’t have libsdl2-ttf in the official repos, and other parts of libsdl2 seem to be older than the latest stable: 2.0.0, while latest is 2.0.2. I guess because of that, tiles don’t work right for me with those libs installed (that’s a screenshot with tiles enabled, and it shows a large, non-refreshing stripe down the middle, and no tiles).

I also found an Ubuntu PPA with snapshots of libsdl2 (so newer, but unstable). With these, I can actually get tiles to show up, but I do get the slowdowns. So, really, I’m inclined to believe the fault is here on my end, except for the fact that others seem to be experiencing the same things on Windows with (presumably) release SDL 2.0.2. I might try to build 2.0.2 myself next, and see if it ends up working any better. I’d also appreciate hearing from anyone else, who’s running experimental builds on Ubuntu.

That’s it, really. The person switching to SDL2 also switched to a GPU-based drawing API.

In my case, decreasing the viewport dimensions slightly (I used to play with 120x50, now it’s 100x40) helped, the lag’s still there, but not as noticeable.

My laptop’s also running on a built-in Intel graphics card and I had no problems before the SDL2 (and GPU-based drawing) switch.

If you can compile, try this branch please:

It forces the game to use software rendering mode. This might speed things up for you if you don’t have a beefy GPU.

If that helps, can consider making it a graphics option.

Confirmed here and merged, software rendering is significantly faster on my system. It’s still going to need some extra work though, it’s still a bit slower than on 1.2 I think.

Current “windows tiles” experimental (0.A-643) adds an option to turn Software rendering on.
It works faster on my PC with integrated graphics. But it brought troubles with some tilesets like Tsu’s and Waldo’s 24 - the only two i see sense using (others are either unusable or not different from ASCII, imho).

Also, 3 DLL’s you need to launch windows tiles client are not in build yet.

The graphical glitches are a result of issues with rotation. It can probably be hackfixed, but I’m not sure how exactly.