Latest Oolite 1.90 on Debian 10

[Pasquale]

Hi all, i have downloaded and installed with success Oolite 1.90 on Debian 10, it works very well, however i have noticed sometime problems with keyboard, i have to press a key two or more time to get it working, for example "enter" or "F1", etc... This problem is common with all keys.

[Cholmondely]

Hi all, i have downloaded and installed with success Oolite 1.90 on Debian 10, it works very well, however i have noticed sometime problems with keyboard, i have to press a key two or more time to get it working, for example "enter" or "F1", etc... This problem is common with all keys.

Welcome!

Can't help (AppleMac, I'm afraid), but there are many others who can.

[hiran]

Hi all, i have downloaded and installed with success Oolite 1.90 on Debian 10, it works very well, however i have noticed sometime problems with keyboard, i have to press a key two or more time to get it working, for example "enter" or "F1", etc... This problem is common with all keys.

I run Oolite on Ubuntu 22 LTS, and I notice after game startup I have to press the first key twice. After that it behaves normally so I never bothered.
Seems to be persistent throughout the game for you?

Unfortunately I have no clue what might be the cause for it.

[Pasquale]

I run Oolite on Ubuntu 22 LTS, and I notice after game startup I have to press the first key twice. After that it behaves normally so I never bothered.
Seems to be persistent throughout the game for you?

Unfortunately I have no clue what might be the cause for it.

It behaves normally also for me, however, if i get time beetween two key press, i have noticed problems, for example after 1 or 2 minutes of relative keyboard inactivity.

[hiran]

I just looked up the relationships.

Ubuntu 22 is based on bookworm which equals to Debian 12.
If you are on Debian 10 you are more similar to a Ubuntu 18. Looking at the amount of changes that happened meanwhile I am not sure the Linux builds we provide will run there without problems.
https://askubuntu.com/questions/445487/ ... s-based-on

Have you tried compiling yourself?

(and note that Ubuntu 24 LTS has been released. It is just a matter of time until Github will switch to that release to provide the builds)

[Pasquale]

I just looked up the relationships.

Ubuntu 22 is based on bookworm which equals to Debian 12.
If you are on Debian 10 you are more similar to a Ubuntu 18. Looking at the amount of changes that happened meanwhile I am not sure the Linux builds we provide will run there without problems.
https://askubuntu.com/questions/445487/ ... s-based-on

Have you tried compiling yourself?

(and note that Ubuntu 24 LTS has been released. It is just a matter of time until Github will switch to that release to provide the builds)

No, I downloaded the precompiled binary package for Linux and installed libglu1-mesa, nothing else. It works fine but I have to be "active" all the time, otherwise there are problems with the keys. However, with low details graphics it seems to work better, even the keyboard. I use the universal frame buffer video driver, without acceleration, because the one for my chipset doesn't work on Debian 10.

[hiran]

No, I downloaded the precompiled binary package for Linux and installed libglu1-mesa, nothing else. It works fine but I have to be "active" all the time, otherwise there are problems with the keys. However, with low details graphics it seems to work better, even the keyboard. I use the universal frame buffer video driver, without acceleration, because the one for my chipset doesn't work on Debian 10.

Hmm. Could it be a performance issue? What framerate do you get? Who knows how to activate the display of the framerate?

I still believe the main issue is that you are trying to run code compiled on Ubuntu 22 on a platform more resembling Ubuntu 18.

When looking up relationships I also found pages mentioning the differences between Debian and Ubuntu. I understood that Debian is considered more stable and supporting older computers, whereas Ubuntu is better on current hardware especially when it comes to hardware and drivers. Maybe if you switch your graphics card could run with hardware support.

[Pasquale]

...What framerate do you get?...

13 - 15 FPS

...Maybe if you switch your graphics card could run with hardware support.

The game runs very well on my setup even with fbdev, which is very common in Linux. Only keys sometimes, I don't think recompiling fixes this little problem. I'm a Java programmer and would be happy to see everything ported to it, maybe I'll try to do that in the near future.

[hiran]

I'm a Java programmer and would be happy to see everything ported to it, maybe I'll try to do that in the near future.

Welcome aboard! We do already have some items covered which you can build on.
OoliteStarter is based on Java and comes with installers for all three operating systems.

[another_commander]

13 - 15 FPS

Looks like you are running on software 3D acceleration; this framerate is extremely low and carries tremendous input lag, which probably explains why keys need to be presses more than once sometimes.

Oolite should easily be able to hit 60+ fps at the very least on any OS (assuming prudent use of oxps). I would suggest a driver upgrade, if possible, to at least ensure that you get hardware graphics acceleration.

[hiran]

Looks like you are running on software 3D acceleration; this framerate is extremely low and carries tremendous input lag, which probably explains why keys need to be presses more than once sometimes.

Do I understand correctly the FPS rate is not only used to render the graphics but resembles the speed of the game loop and therefore the rate for polling the input devices?

[another_commander]

Do I understand correctly the FPS rate is not only used to render the graphics but resembles the speed of the game loop and therefore the rate for polling the input devices?

Render fps and game logic ticks are decoupled, the game can tick up to a minimum of 0.25 sec (which is why you will never see the fps counter dropping below 4). However, when both rendering and game logic are all run on the CPU then decoupled or not is of minor importance. The CPU will simply take the full load and generate whatever frames it can and this is what will result in lag.

[hiran]

Do I understand correctly the FPS rate is not only used to render the graphics but resembles the speed of the game loop and therefore the rate for polling the input devices?

Render fps and game logic ticks are decoupled, the game can tick up to a minimum of 0.25 sec (which is why you will never see the fps counter dropping below 4). However, when both rendering and game logic are all run on the CPU then decoupled or not is of minor importance. The CPU will simply take the full load and generate whatever frames it can and this is what will result in lag.

Interesting code architecture.
But the way you describe sounds applicable to one cpu/one process. If rendering and game logic are decoupled, can't they take advantage running on multiple cores?

[another_commander]

Interesting code architecture.
But the way you describe sounds applicable to one cpu/one process. If rendering and game logic are decoupled, can't they take advantage running on multiple cores?

Draw calls on the CPU will always be a lot, lot slower than on GPU no matter how well you might implement multi threading. Plus, Oolite is generally single threaded with just a few selected tasks being offloaded to separate cores (texture loading, logging, sound etc.).