It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
So, I've just started playing this game, and it looks promising... but I've hit a bit of a performance wall.

Specifically, while the tutorial level went perfectly well, what followed was... pretty much unplayable, I fear. The framerate was low enough that the game was near to being fully unresponsive.

Now, my computer isn't the most powerful thing any more, and I'll grant that Ubuntu 22.04 (my current OS) seems oddly slower than the previous long-term-support version--but still, my specs (see below) seem as far as I perceive well above the game's minimum.

I've tried a few graphical settings in the hopes of improvement--specifically, disabling anisotropic filtering and texture filtering, enabling Vsync, and limiting the max FPS--but so far to no discernible effect. I've likewise tried both Vulkan (VkD) and good-old OpenGL, with no clear difference from the change.

Is there something else that I might look at to perhaps get the game to run playably...?

My specs:
OS: Ubuntu Linux 22.04.5 LTS
Computer: Dell Inspiron 15 3000 Series
CPU: Core i7 2.4Ghz (4-Core)
Memory: 8GB
GPU: GeForce 840M, 2GB
This question / problem has been solved by madame-rachelleimage
avatar
Thaumaturge: So, I've just started playing this game, and it looks promising... but I've hit a bit of a performance wall.

Specifically, while the tutorial level went perfectly well, what followed was... pretty much unplayable, I fear. The framerate was low enough that the game was near to being fully unresponsive.

Now, my computer isn't the most powerful thing any more, and I'll grant that Ubuntu 22.04 (my current OS) seems oddly slower than the previous long-term-support version--but still, my specs (see below) seem as far as I perceive well above the game's minimum.

I've tried a few graphical settings in the hopes of improvement--specifically, disabling anisotropic filtering and texture filtering, enabling Vsync, and limiting the max FPS--but so far to no discernible effect. I've likewise tried both Vulkan (VkD) and good-old OpenGL, with no clear difference from the change.

Is there something else that I might look at to perhaps get the game to run playably...?

My specs:
OS: Ubuntu Linux 22.04.5 LTS
Computer: Dell Inspiron 15 3000 Series
CPU: Core i7 2.4Ghz (4-Core)
Memory: 8GB
GPU: GeForce 840M, 2GB
That system is underpowered. There's a couple things you can try though. First make sure clock burst is enabled on your CPU - [url=https://askubuntu.com/questions/1163804/how-to-enable-cpu-turbo-boost-in-ubuntu#:~:text=Disabling%20Intel%20Turbo%20Boost%20in%20ubuntu%20(4%20answers)%20Closed%205]https://askubuntu.com/questions/1163804/how-to-enable-cpu-turbo-boost-in-ubuntu#:~:text=Disabling%20Intel%20Turbo%20Boost%20in%20ubuntu%20(4%20answers)%20Closed%205[/url]

This is default on Windows, however make sure your CPU has sufficient cooling to handle it. Clock burst increases the CPU's speed by about 50%-70% so it isn't the greatest thing in the world but it does help.

Second make sure your "particles" setting in the graphics settings are set to low.

Thirdly you can lower the effective resolution by entering the console (~ on USA keyboards, might be different for other keyboards) and enter "vid_scalefactor 0.5" in the console. This reduces the pixel fill required to draw a scene and may further assist with speeding things up if your GPU is bottlenecking on shaders.

Another thing you can try also is "gl_lightmode 0" to enable GZDoom's "classic" lightmode - this diminishes the effect of distance fading for the sector drawing - it may also help.

Last thing you can try is running it in a simple DE like Openbox or LXDE. Your existing DE might be too heavy on resources, or its composition manager may be bugged. (Linux and older NVidia do not play well together at all)

--

Oh, and one more thing: If you are attempting to run the game using GZDoom - DON'T!!!!!!! It will not perform well. Use either the included engine or compile from this source tree: https://github.com/HandsOfNecromancy/HandsOfNecromancy2-Engine
Post edited October 06, 2024 by madame-rachelle
First of all, thank you for your response--it is appreciated! ^_^

That system is underpowered.
I mean, it's not great, but it meets the minimum system requirements posted on the store page (and indeed, slightly exceeds them), as far as I can tell.

(Specifically: It meets the OS and clock-speed requirements, and I believe exceeds the core-count, memory, SSE2, and Vulkan requirements.)

(And it's not like it doesn't run at least some other indie games happily enough--even relatively recent ones.)

However!

In attempting to try out your suggestions--primarily the particle setting--I've discovered something new:

This slowdown only happens on the save that I have coming from the tutorial into the first episode!

If I just start a new game, going directly into the first episode without the tutorial, the game seems to run fine! (At least from a very brief test for these purposes--I don't intend to play properly today.) But if I load the save-game that I made after entering from the tutorial, the game is, as mentioned previously, unplayable!

(To explain: I initially played through the tutorial, which then brought me into the first episode, at the start of which I made a save. And I suppose that, having a save at the start of the game, I didn't think to try starting anew when I encountered trouble.)

So it seems like something may have been broken--at least in my specific save--on the transition from tutorial to first episode, or something like that...?

Well, either way, I'm excited to get to soon play the game! ^_^
Post edited October 06, 2024 by Thaumaturge
Yeah it should be able to.

One other thing I remembered - Linux and old Nvidia GPU's are terrible together. The only way I was ever able to get my Nvidia GPU to run acceptably was to install the actual Nvidia.com drivers, not the ones that came with Linux. Which means a lot of things are incompatible after you do. I am not really sure what you want to do here, because that obviously means some things will break if you do that. But, at least, the game should run better if you do.
Oh, I am already running the NVidia drivers!

(Indeed, I updated them just recently.)

I've certainly had trouble with getting just the right ones for my system in the past, but so far the latest seem to be working.
Sorry for the double-post, but it seems that the problem is in fact not solved after all! :/

Specifically, starting the game with the first level of the first episode did indeed allow me to play that level with no trouble at all--even at fairly high settings. The gameplay was smooth and fun!

... Until I completed the level and transitioned into the next, at which point the problem occurred again. :/

So, it seems now that every time I transition from one level to another, the framerate drops through the floor.

And--somehow!--this issue persists in saves made within the new level!

(While, conversely, loading a save made without the issue being present--e.g. from a level started directly from the main menu--works as expected.)

At a guess, could it be that (in this version, at least), the level isn't being cleaned up after completion, leaving the game trying to handle two levels at once?

And that the level (or reference to it) is being saved in the save-file, thus prompting it to be loaded when that save is loaded?
avatar
Thaumaturge: Sorry for the double-post, but it seems that the problem is in fact not solved after all! :/

Specifically, starting the game with the first level of the first episode did indeed allow me to play that level with no trouble at all--even at fairly high settings. The gameplay was smooth and fun!

... Until I completed the level and transitioned into the next, at which point the problem occurred again. :/

So, it seems now that every time I transition from one level to another, the framerate drops through the floor.

And--somehow!--this issue persists in saves made within the new level!

(While, conversely, loading a save made without the issue being present--e.g. from a level started directly from the main menu--works as expected.)

At a guess, could it be that (in this version, at least), the level isn't being cleaned up after completion, leaving the game trying to handle two levels at once?

And that the level (or reference to it) is being saved in the save-file, thus prompting it to be loaded when that save is loaded?
The bug sounds most interesting.
As a temporary workaround I suppose you could try to use the console to manually load levels and see how that works for you, whether there are further slowdowns.

To change levels try this command with the episode and mission you want:

changemap e4m1

Additionally you could try running the game using different method. For example if you used Konsole terminal, try a different one, or run from default CLI without running the desktop whatsoever; Things like that. Maybe the game doesn't get properly cleared between levels like you said.

Hope you get it fixed, the game is really worth it.
Post edited October 07, 2024 by Kristijonas
avatar
Kristijonas: The bug sounds most interesting.
Well, there is that for it, in fairness! It is a surprising and odd issue to encounter--especially as I imagine that not many others are experiencing it!

(Unless I'm, like, the only person playing it on Linux...?)
avatar
Kristijonas: As a temporary workaround I suppose you could try to use the console to manually load levels and see how that works for you, whether there are further slowdowns.

To change levels try this command with the episode and mission you want:

changemap e4m1
Hmm... Trying that, it seems that I can only change levels when I'm already within a level--and that changing levels in this way still incurs the issue. :/

It was a good idea, however, so thank you for it! ^_^
avatar
Kristijonas: Additionally you could try running the game using different method. For example if you used Konsole terminal, try a different one, or run from default CLI without running the desktop whatsoever; Things like that. Maybe the game doesn't get properly cleared between levels like you said.
This, as it turns out, was a very good idea!

To be specific:

I've been running the game via a desktop file that runs a shell-script, all as set in place by the installer (as far as I recall). Run this way, things are as I described above: the game is fine for one level, then becomes unplayable when the next is transitioned to, or when a save from an unplayable level is loaded.

If, however, I run the shell-script directly from a terminal... everything just works! Even saves that previously were unplayable!

I do note quite a lot of output in the terminal as I play--and a difference in that output between saves that (run via the desktop file) worked, and saves that didn't:

When a save that worked is loaded, I see the following message printed over and over again:
"log singularity error"

And when a save that was unplayable is loaded, I instead see the message below printed over and over again:
"log domain error"

(I think that I have those the right way around.)

So... maybe this is some weird conflict with the logging system of all things...? o_0
Do you have Wine installed? Try running the Windows version - https://drive.google.com/file/d/1mmHD-gosAe-nfL3Z3zP4-ymzOe_pMJcV/view?usp=sharing (simply unzip it in the same folder as the game and run handsofnecromancy2.exe)

Ideally, other than input, initialization, and presentation, the Windows build should be identical to the Linux build, but this will help to rule out whether this is a bug specific to the Linux build.
Post edited October 09, 2024 by madame-rachelle
So in one of the included math libraries inside of GZDoom there is a non-fatal printing of errors if a math log() function is called where the input <= 0.0.

This is what causes the console message spam. Since it's done with a regular "printf" and not "Printf" (meaning, it doesn't use GZDoom's console function, just the terminal output function), that means endless messages can be printed about that. This problem would be extremely worse if it used GZDoom's console Printf function because it doesn't take much to overwhelm that - but at least the problem would have been noticed a lot quicker if that were the case.

I'm guessing this might be a significant source of the slow-downs - Linux deals with the console 100% of the time, even if apps are pure GUI. Unlike Windows, Linux has no distinction between a console app and a gui app - every app is a console app. So spamming it can cost an awful lot of resources that does not get noticed in Windows. Each message has to be processed even if you actually never see it.

In the next version, I am going to silence that. I don't know where the log() spam is coming from, I've tried several methods to ensure that my own inputs will not cause that but it still spams a log domain error after I change the level, and it does that even when I run the game via Wine. I cannot silence the message other than with an engine update to completely remove the messages. The math errors are clearly non-fatal, but ideally they should be handled some other way, but that is something for the GZDoom team to figure out sometime in the future.

Regardless, if this is the case, then removing the messages is going to be the route we go for this.
Post edited October 10, 2024 by madame-rachelle
Ah, of course! I should have guessed that it was the maths version of "log" and not the "writing messages" version of "log" when "domain" was mentioned! ^^;

I must have logging on the brain!

I hadn't yet gotten around to trying the Windows version through WINE when you posted the last message above, but from what you say, I think that I'll wait for the update before continuing!

(I mean, I could keep playing from the terminal--but if there's an update coming that will obviate that, then I might as well wait!)

Thank you so much for investigating! I appreciate the work, as well as the communication! ^_^
Thanks for making the Linux version of “Hands of Necromancy II” here on GOG.
I'll buy the game at the normal price when it works properly as I don't use Wine.
Post edited November 02, 2024 by LinuxFire
madame-rachelle, you can also look here please?
https://www.gog.com/forum/hands_of_necromancy/linux_version/page1
Post edited November 02, 2024 by LinuxFire
avatar
LinuxFire: Thanks for making the Linux version of “Hands of Necromancy II” here on GOG.
I'll buy the game at the normal price when it works properly as I don't use Wine.
Note that you don't have to use WINE in order for it to work: just run the game from the terminal.

(Or at least, that worked for me, and presuming that you're having the same problem as had I.)
Post edited November 02, 2024 by Thaumaturge
Hello,
The game doesn't work for me, here are the logs when running it in the terminal:


❯ /home/gnu68/GOG\ Games/Hands\ of\ Necromancy/start.sh
Running Hands of Necromancy

(handsofnecromancy:14854): Gdk-CRITICAL **: 14:40:18.820: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed
Hands of Necromancy hon1-v3.0-vk - 2024-07-04 15:43:35 -0400 - SDL version
Compiled on Jul 4 2024


❯ OS: Solus 4.6 Convergence, Linux 6.11.5-307.current on x86_64
Hands of Necromancy version hon1-v3.0-vk
W_Init: Init WADfiles.
adding /home/gnu68/GOG Games/Hands of Necromancy/game/engine-vkdoom.pk3, 694 lumps
adding ./HandsOfNecromancy.ipk3, 1073 lumps
adding ./hon-audio.pk3, 499 lumps
adding ./hon-interface.pk3, 1397 lumps
adding ./hon-maps.pk3, 50 lumps
adding ./hon-music.pk3, 15 lumps
adding ./hon-sprites.pk3, 4641 lumps
adding ./hon-worldassets.pk3, 991 lumps
Using video driver x11
Number of detected displays 2 .
Creating window [2048x1152] on adapter 0
Gtk-Message: 14:40:22.134: Failed to load module "appmenu-gtk-module"