OGRE 1.11.5 Working on ‘Phosphene’

One of the open-source software projects which has often fascinated me, is called OGRE, which stands for Open-Source Graphics Rendering Engine. It’s a very powerful set of libraries, that allows good coders to design 3D graphics applications, which take full advantage of hardware-accelerated – i.e., GPU-based – rendering, of virtual 3D scenes designed by such users, into simulated 2D camera views, within the same scene. This is one of the most common modes in which 3D Graphics is operated.

One of the things that OGRE is not, is a full-fledged game engine unto itself. This is due to:

  • Lack of sound implementation (Additionally linking applications to the SDL Library may solve that),
  • Lack of scripting support, without some sort of add-on. I think I compiled it with Python support, which would supply scripting, if my coding was good enough.

Modern builds of OGRE break with the past, in that they no longer use ‘OIS’ as their input system. Instead, at least their Sample Browser uses the ‘SDL library’ to do the same.

One of the feats which I have now accomplished on the computer named ‘Phosphene’, which is a Debian / Stretch, Debian 9 system, was to compile version 1.11.5 of this engine because I’m curious about Game Design, which I have been for a long time. And one of the reasons I feel that this software is stable on Phosphene, is due to the information which I already provided in This past posting. The past posting announced observations which I made, when this same hardware was called the computer ‘Plato’, but already running Debian Stretch.

What my observation essentially suggests is, that running 3D, OpenGL applications can in fact break the compositor because they suspend it, but that there is a work-around.

(Updated 2/20/2019, 19h00 … )

Continue reading OGRE 1.11.5 Working on ‘Phosphene’

An Update on how to Create One’s Own Movies, to Play on Home Entertainment Systems.

In a previous posting, I shared information on how it’s possible to burn Blu-ray disks using a Linux computer.

I’d just like to recap, what that posting was meant to provide instructions to do. A Blu-ray Disk essentially has 3 levels of formatting. Actually, the formatting has more than 3 levels, but the following is a simplification:

  1. Low-Level Formatting into blocks,
  2. Formatting of the blocks into a File-System,
  3. A special arrangement of the files, into the format required for Blu-ray players to recognize the content of the disk, as a movie and not just as data.

My posting never suggested, that Linux users wanting to burn their own movies, should use DRM or encryption of any kind.

Nevertheless, this way of doing things has become a bit contentious, and so I’d just like to mention, that I no longer recommend that users do it the way I had first written.

What I now recommend users actually do, is to use their favourite Video Editing application to export a movie as an MP4 File, or as an MTS File, or as an OGV File, or as whatever type of media file they like. And then, users can either burn this file onto a physical Blu-ray, as data, which will then have formatting levels (1) and (2) above but not (3), or that users write this file to a USB Key. That way the decision will be at the discretion of the Blu-ray player, or up to any other component of the Home Entertainment System, whether to accept this format of video for playback on the big screen.

I no longer recommend that users actually imitate the formatting layer (3) above, as if their disk was a commercial Blu-ray Movie Disk. It would be a data disk.

Continue reading An Update on how to Create One’s Own Movies, to Play on Home Entertainment Systems.

Bug: PackageKit refreshes packages list from repositories, every 5 minutes.

I have recently installed a (Linux) Debian / Stretch Operating System, on existing hardware that I had, but an O/S version that uses Plasma 5 as its desktop manager, and that is officially a “Kanotix” build. Because Linux users often like to have the same level of comfort as Windows users, and like to be able to update and/or install software using the point-and-click method, as often as possible, Kanotix has chosen to use the GUI application “Apper” to manage software updates. This application uses the background-daemon “PackageKit”, to execute what the user told it to do, using the elevated privileges with which this background daemon runs.


But there is a known bug in this arrangement, which has just come to my attention this morning. PackageKit was polling the repositories for software updates every 5 minutes! While some people might think it’s cool, to be up-to-date about new packages, to within 5 minutes, in fact it’s not cool. And, if the repository-servers get the idea that they’re being spammed by continuous requests, they may even black-list the IP addresses that are doing so! So what can be done as a work-around, until the coders actually fix this bug?

Continue reading Bug: PackageKit refreshes packages list from repositories, every 5 minutes.

A disadvantage in running Linux, on a multi-core CPU that’s threaded.

One of the facts about modern computing is, that the hardware could include a multi-core CPU, with a number of virtual cores different from the number of full cores. Such CPUs were once called “Hyper-Threaded”, but are now only called “Threaded”.

If the CPU has 8 virtual cores, but is threaded as only 4 full cores, then there will only be a speed advantage, when running 4 processes. But because processes are sometimes multi-threaded, each of those 4 processes could consist of 2 fully-busy threads, and benefit from a further doubling of speed because each full core has 2 virtual cores.

It’s really a feature of Windows to exploit this fully, while Linux tends to ignore this. When Linux runs on such a CPU, it only ‘sees’ the maximum number of virtual cores, as the logical number of cores that the hardware has, without taking into account that they could be pairing in some way, to result in a lower number of full cores.

And to a certain extent, the Linux kernel is justified in doing so because unlike how it is with Windows, it’s actually just as cheap for a Linux computer to run a high number of separate processes, as it is to run processes with the same number of threads. Two threads share a code segment as well as a data segment (heap), but have two separate stack segments as well as different register-values. This makes them ‘enlightened processes’. Well they only really run faster under Windows (or maybe under OS/X).

Under Linux it’s fully feasible just to create many processes instead, so the bulk of the programming work does not make use as much of multi-threading. Of course Even under Linux, code is sometimes written to be multi-threaded, for reasons I won’t go into here.

But then under Linux, there was also never effort put into the kernel recognizing two of its logical cores, as belonging to the same full core.

(Updated 2/19/2019, 17h30 … )

Continue reading A disadvantage in running Linux, on a multi-core CPU that’s threaded.