For information and discussion about Oolite.
https://bb.oolite.space/
Welcome!Pasquale wrote: ↑Tue Apr 30, 2024 9:10 pmHi 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.Pasquale wrote: ↑Tue Apr 30, 2024 9:10 pmHi 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.
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 wrote: ↑Wed May 01, 2024 7:14 amI 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.
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 wrote: ↑Wed May 01, 2024 6:55 pmI 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)
Hmm. Could it be a performance issue? What framerate do you get? Who knows how to activate the display of the framerate?Pasquale wrote: ↑Thu May 02, 2024 9:18 amNo, 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.
13 - 15 FPS
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.
Welcome aboard! We do already have some items covered which you can build on.
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 wrote: ↑Mon May 06, 2024 9:00 amLooks 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.
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.another_commander wrote: ↑Tue May 07, 2024 11:01 amRender 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.
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.).