I had the same issue, but fixed it by editing ~/.local/share/Hammerfight/Config.ini and changing the line:

CORE_USE_SLEEP=true

to 

CORE_USE_SLEEP=false

Anon your answer actually worked.

I can't say I have idea what it actually did, or how you managed to figure that was the problem, but thanks.

(In reply to comment #1)
> I had the same issue, but fixed it by editing
> ~/.local/share/Hammerfight/Config.ini and changing the line:
> 
> CORE_USE_SLEEP=true
> 
> to 
> 
> CORE_USE_SLEEP=false

I had experimented with that too, but I was under the impression that it made the game go as fast as the CPU could run it.

nigga: does the game run at the same speed as in Windows?

Toggling CORE_USE_SLEEP helps *A LOT* on my machine. If CORE_USE_SLEEP is on, the game is unplayable and choppy -- I can barely get past the menu.

I think this problem is quite universal on Linux systems. Many on the Archlinux Humble Indie Bundle threads are complaining that both Hammerfight AND Cogs are too heavy for their machines. Considering Hammerfight's very light requirements on Windows, almost any recent machine should be able to play the Linux version if the port is adequate.

Using GTX 285 on nvidia 275.21, Core i7-2600K, 16GB RAM. There's no reason a game that requires 256MB RAM, Pentium III, and a DX8 card on Windows should run so terribly on Linux. :(

While playing with CORE_USE_SLEEP off, the game is smooth but the controls seem off -- it is difficult to move my craft and it seems to be constantly pulled downward. I have a 1000 DPI mouse (G500 turned all the way up), so this doesn't make much sense to me. :(

(In reply to comment #4)
> Toggling CORE_USE_SLEEP helps *A LOT* on my machine. If CORE_USE_SLEEP is on,
> the game is unplayable and choppy -- I can barely get past the menu.
> 
> I think this problem is quite universal on Linux systems. Many on the Archlinux
> Humble Indie Bundle threads are complaining that both Hammerfight AND Cogs are
> too heavy for their machines. Considering Hammerfight's very light requirements
> on Windows, almost any recent machine should be able to play the Linux version
> if the port is adequate.
> 
> Using GTX 285 on nvidia 275.21, Core i7-2600K, 16GB RAM. There's no reason a
> game that requires 256MB RAM, Pentium III, and a DX8 card on Windows should run
> so terribly on Linux. :(

Agree. To be fair, the original code must've been quite an outdated mess and nothing short of a reimplementation would have solved every issue.
Cogs runs fine on my Athlom 64 2.2GHz, 2GB RAM, GTX 460 756MB with Debian 6.0.2 btw.

I also tested momentarily the Windows build on a high-spec PC running Windows 7 and found it very buggy as well. The physics, for instance, were almost broken. As if the physics were being simulated only every other game cycle and with some wacky settings.

> While playing with CORE_USE_SLEEP off, the game is smooth but the controls seem
> off -- it is difficult to move my craft and it seems to be constantly pulled
> downward. I have a 1000 DPI mouse (G500 turned all the way up), so this doesn't
> make much sense to me. :(

tl;dr at bottom

It seems to actually work the other way - the slower your mouse, the better the game works.
Turn the resolution down as much as you can, then set the in-game DPI setting accordingly (maybe even lower than you'd think).
As best as I can tell, the way the game reads mouse movement is by, for each game cycle, getting the pointer's location and then centering the pointer.
If the pointer is so fast that every small movement can cover the whole 800x600 game area during a game cycle, then the game can not distinguish between a small movement and a large one. And if you're trying to move say, to the right, there will be instants when the pointer will not move very far to the right or will even move a little to the left e.g. when lifting the mouse from the desk. This, combined with the lack of sensitivity for small movements makes the ship unwieldy and glitchy.

tl;dr lower mouse resolution/pointer speed and change the DPI manually in the game settings to something low (e.g. 200).

Running ltrace on Hammerflight shows it calling usleep regularly for ~55ms at a time, maybe it was supposed to be 5.5ms?

Another improvement to stop the game taking 100% CPU, but still run smoothly is to leave CORE_USE_SLEEP as false and set the environment variable __GL_SYNC_TO_VBLANK=1 before running the game (at least with Nvidia cards.)

Confirming that the CORE_USE_SLEEP trick definitely helps and makes the game at least somewhat usable.

I don't see "__GL_SYNC_TO_VBLANK" in the file "Config.ini". Where can I set this variable to 1 ?

(In reply to comment #8)
> I don't see "__GL_SYNC_TO_VBLANK" in the file "Config.ini". Where can I set
> this variable to 1 ?

__GL_SYNC_TO_VBLANK is an environment variable. You can use it only for hammerfight by prefixing the command you use to run hammerfight (probably ./hammerfight) with __GL_SYNC_TO_VBLANK=1, so the command would look like __GL_SYNC_TO_VBLANK=1 ./Hammerfight. If you want to set that variable generally, you can place it in your bash profile with your other environment variables.

That will enable vsync, by the way, which is a feature that ensures images are not drawn in excess of the refresh rate of your monitor (i.e., FPS capped at 60). This prevents tearing.

This turned out to be a really stupid bug on my part; this is fixed in the next build (which, hopefully, we'll be pushing today or tomorrow).

I'll mark this bug as FIXED when the new build is live, so you all get notified. Thanks for your patience!

--ryan.

Oh, also, the next build has a GFX_SYNC_TO_VBLANK option in the config.ini, for those that want to enable that without the Nvidia environment variable.

--ryan.

Thanks Ryan, keep up the good work :)

Hi guys,
for me non of this solutions worked. The game doesn't run smoothly at all. Even the intro video isn't running smoothly. I think my Computer isn't the problem(quad core 2,4 ghz, 4 gb of ram and 1 gb gpu). I'm running (x)ubuntu 11.04

(In reply to comment #10)
> This turned out to be a really stupid bug on my part; this is fixed in the next
> build (which, hopefully, we'll be pushing today or tomorrow).
> 
> I'll mark this bug as FIXED when the new build is live, so you all get
> notified. Thanks for your patience!
> 
> --ryan.

Any update on this Ryan? I hear that the build is still at July 17.

(Changing several bugs at once, sorry if you get duplicate messages because you're watching several of these bug reports.)

This bug is, I believe, fixed in Build #2, which is now available.

Details on this build, and how to upgrade to it, are here: http://icculus.org/pipermail/hammerfight/2011-August/000007.html

--ryan.