What hardware are you running ToME 4 on?

[edge2054]

Okay then, new question: is anyone here playing ToME 4 without issues on a computer with less than 2 GB of RAM?

I was on my old computer. Windows XP, 1.25 gigs of RAM.

[Emetivore]

I'm running ToME on a $3000 Alienware M18x laptop with dual Radeon 6990s. I have no problems ever.

Note that I own Skyrim and all kinds of other top-shelf games, and even with a system that can run everything at Ultra, I still prefer ToME .

[Calabria]

I'm running on a Linux laptop with a Pentium M at 2GHz, 2G of memory, and an Intel 915GM display card. LordEstravan, you never actually said what your hardware is, but I imagine it's newer than this. It runs fine, including with Shockbolt graphics, although I turned down the particle effects and turned off the background on the opening screen.

The Linux distribution comes with a number of libraries that probably duplicate those you already have. I found it speeded things up really considerably to not use most of those, instead using the distribution defaults. I think zlib (for compression) was a particular problem, for some reason. The only ones you really need are the SDL libraries; DarkGod is using a weird, fairly old version, for some reason.

[overtrix]

My machine has 1GB of RAM - not much in 2012 I know. Leaving the ToME window open during startup, saves, level changes etc the waits are impossible but by minimizing it (or whatever it's called, onto taskbar), things speed up many-many-fold and the game's playable. Heaven forbid that this should simply be the progress bars, e.g. perhaps being updated too tightly in the scheme of things, that would be really silly

[Kalirion]

I have 1.3 GHz Core 2 Duo, Intel 4500mhd integrated GPU, Windows 7x64, 4GB RAM.

As I stated in my own recent topic, the default tileset starts chugging in many areas, making movement take way too long - autoexploring about 3 spaces a second. I've tried all the graphics options, no help. CPU cores don't seem to get maxed out according to task manager, so not sure what the issue is. Maybe I'll try limiting affinity to one core?

Yes the saves/loads take way too long - I'll try to see if minimizing really does help.

[darkgod]

Did you check your video card driver is corectly setup for OpenGL?

[Kalirion]

Did you check your video card driver is corectly setup for OpenGL?

I know my card has issues with OpenGL, but disabling the OpenGL effects in the menu didn't improve performance. Or does OpenGL still get used?

Bad performance is not 100% consistent though. On one playthrough the Maze autoexploring was very slow, but on another it was relatively fast. One difference was that in the fast autoexplore run I was using a wand to destroy every trap I came across. Don't know if it's possible for traps which aren't even firing to impact performance though.

[darkgod]

OpenGL is always used; if your driver is bad at it it means your CPU will do it instead of your GPU which is *extremely slow*

[Kalirion]

OpenGL is always used; if your driver is bad at it it means your CPU will do it instead of your GPU which is *extremely slow*

Well, ASCII mode seems to fix most of the slowdown, so I guess OpenGL is the culprit.

[darkgod]

ASCII mode uses OpenGL too; but obviously it uses less of it; so probably

[SilentLion]

Hi,
I had issues just today on my brother's Lenovo notebook running Windows 7, the game was generally terribly slow, e.g. the startup load screen advanced 1% per 1-2 seconds. After it finally started up, the UI was very slow and unresponsive, the game was unplayable.

However, all this was fixed once I updated the graphics driver (the notebook has an "Intel Graphics Media Accelerator 4500M" video device). I just went to the Advanced settings section of the video device, clicked on "Update Driver" (or something like that) and Windows could download the new version of the driver and update it automatically.

[overtrix]

OMG - ça veut dire, OMDG - went and checked, I didn't have a video driver *at all* on this system. Fetching it via Windows Update has fixed everything. While I was at it, got an audio driver too ... the good old "doobly-doo, doo doo, dum doo" is back, glad you never changed that

[darkgod]

[Lord Estraven]

Alright... Since I now know this is an issue with Linux kernel 2.6.37.6, I am trying to see what can be done to mitigate it. Why? Because I'm a nerd.

Anyway I found something interesting. Setting vm.swappiness=1 (which should probably be done by default on Linux anyway) made T4 start and run fine, on the problem kernel! Until I got to the equipment screen, at which point the allocated virtual memory went from 300 MB to 800 MB and the swapfest started.

So at least I know it's not ignoring swappiness. What's strange, though, is that I can't figure out what the swapped-out memory is actually being used for! According to htop, the actual program memory is steady at ~70 MB, and there was free RAM available; so I really have no idea why 900 MB of swap was suddenly in use. Very very strange.

[Lord Estraven]

OMG. Solved. Finally. Had to boot with the 'noapic' kernel parameter. Hadn't thought of that, since my computer wasn't showing any of the gratuitous compatibility issues (e.g. random kernel panics) usually associated with needing noapic. Anyway there is now no memory growth at all.

(Until I drag-and-drop from the weapon slot into the inventory, but I think that's another bug entirely.)

So, I'm guessing the huge memory leakage I observed was due to some stranger interaction between the particular kernel and the hardware.