A bit of my personal history, experimenting in 3D game design.

I was wide-eyed and curious. And much before the year 2000, I only owned Windows-based computers, purchased most of my software for money, and also purchased a license of 3D Game Studio, some version of which is still being sold today. The version that I purchased well before 2000 was using the ‘A4′ game engine, where all the 3DGS versions have a game engine specified by the latter ‘A’ and a number.

That version of 3DGS was based on DirectX 7 because Microsoft owns and uses DirectX, and DirectX 7 still had as one of its capabilities to switch back into software-mode, even though it was perhaps one of the earliest APIs that offered hardware-rendering, provided that is, that the host machine had a graphics card capable of hardware-rendering.

I created a simplistic game using that engine, which had no real title, but which I simply referred to as my ‘Defeat The Guard Game’. And in so doing I learned a lot.

The API which is referred to as OpenGL, offers what DirectX versions offer. But because Microsoft has the primary say in how the graphics hardware is to be designed, OpenGL versions are frequently just catching up to what the latest DirectX versions have to offer. There is a loose correspondence in version numbers.

Shortly after the year 2000, I upgraded to a 3D Game Studio version with their ‘A6′ game engine. This was a game engine based on DirectX 9.0c, which was also standard with Windows XP, which no longer offered any possibility of software rendering, but which gave the customers of this software product their first opportunity to program shaders. And because I was playing with the ‘A6′ game engine for a long time, in addition owning a PC that ran Windows XP for a long time, the capabilities of DirectX 9.0c became etched in my mind. However, as fate would have it, I never actually created anything significant with this game engine version – only snippets of code designed to test various capabilities.

Continue reading A bit of my personal history, experimenting in 3D game design.

Example Python code, that saves text to the Linux clipboard, persistently.

There are some quirks as to how the Linux X-server clipboard works, which have been observed for some time, but which will also affect how to write a Python script / program, that saves some text to the clipboard, but with the intention that the script should exit immediately, while the copied text should remain on the clipboard.

What works against that, is the way the X11 clipboard works generally, which is, that there is no part of the actual O/S, which stores the clipboard contents. Instead, the application being copied from stores this data, and the data is not transferred until another application, or the same application, pastes it again. This has as consequence, that if the first application tries to store the data to the clipboard but then exits, and if the second application next tries to paste it, the clipboard, by first approximation, will be empty because the first application, which was holding the data, has quit.

There may exist some Linux environments in which the desktop manager takes over in a case like that, to hold a copy of the data that was Copied, but my Debian / Stretch, Plasma 5.8 computer, which I name ‘Phosphene’, fails to do so. And this is also how or why, the Plasma 5 clipboard utility, which is named ‘Klipper’, will sometimes still show that last item at the top of its clipboard history, but why that item cannot be pasted (using <Ctrl>+V), until an earlier item is selected within Klipper, and then the item of interest is selected again, so that this most-recently copied item will actually be available on the clipboard again.

In principle, ‘Klipper’ has a setting which states ‘Assure clipboard never empty’. But, long story short, that setting does not work

(Update 4/09/2019, 6h05 : )

Actually, I have learned an intricacy, of how the Plasma 5, Klipper app interacts with the X11 clipboard, and which I was not aware of before. Apparently, the actual clipboard has 3 ‘slots’: ‘Primary’, ‘Secondary’, and ‘Clipboard’. Mouse-Highlighting will cause ‘Primary’ to point to the selected text, while <Ctrl>+C Copying will cause ‘Clipboard’ to point to the selected text. After that, middle-clicking with the mouse will Paste from ‘Primary’, while <Ctrl>+V will Paste from ‘Clipboard’.

When using <Ctrl>+C, an ideally Linux-compliant application will actually leave with both clipboard targets pointing at the selection, while certain applications such as Firefox will only end up with ‘Clipboard’ pointing at the selected text.

The only real pitfall in understanding ‘Klipper’ was, the fact that while it does keep a copy of the clipboard’s contents ‘on the side’, regardless of how they were Copied, Pasting that copy directly after the application Copied from has closed, is only facilitated for middle-clicking with the mouse, not for the <Ctrl>+V -type Pasting.

However, left-clicking on one of the entries in the Klipper History will cause the ‘Clipboard’ X11 pointer to point to it, unless that just happens to be the most-recent entry.

Basically, the user community wanted an alternative to Windows, that has familiar features, and instead, the Linux developers left them a well-hidden Easter Egg. (:1)


I recently needed to install a Python script, which hashes a domain-name, password combination, and which has as feature the ability to save the hash-code ‘to the clipboard’, instead of just printing it out, so that the user should next be able to paste the hash-code, and in some cases do so, without the hash-code ever being displayed. This script failed to work in its original version and I needed to modify it, to get it to work the way I wanted it to work.

(Updated 4/09/2019, 15h40 … )

Continue reading Example Python code, that saves text to the Linux clipboard, persistently.

About the Frame-Rate of Hardware-Accelerated Animations.

One of the subjects which I’ve posted about before, is that in the case of typical hardware-accelerated animations, the frame-rate, which some people just know as ‘the FPS of the animation’, is actually lower than the refresh-rate of the monitor.

Well, if the user is running Plasma 5 as his desktop-manager – which is Linux-based – then he can open ‘System Settings -> Desktop Behaviour -> Desktop Effects’, and he will see a list of available compositing effects, that would all be hardware-accelerated, and under the section of ‘Tools’, there is an effect named ‘Show FPS’. Enabling that effect, and then clicking on ‘Apply’, will cause a piece of OSD information to display, that actually shows the frame-rate. The user will notice that it does not equal the refresh rate of his monitor.

But there is a catch to this. Often, the rendering software will place an upper limit on the frame-rate. Frame-rates actually higher than the refresh rate of the display device accomplish no useful purpose, and there used to be a simple, command-line test which Linux users could run, which was called ‘glxgears’. This would display a very simple animation, of a red, a green and a blue gear, rotating smoothly. In very early versions of this test-program, a frame-rate of something unreasonable, such as 2000 or maybe even 5000 FPS might result, which simply represents a waste of GPU power. The gears would still rotate at the same, correct apparent speed, but each frame-cycle would be fewer than 1 millisecond apart on average. Therefore, more-recent versions of this test-program will cap the frame-rate at the refresh rate of the monitor, and the gears will display as rotating at the same, smooth speed.



An update on how to use Latte-Dock.

One of the features which I have posted about recently, is the Plasma 5 add-on called ‘Latte-Dock’. Specifically I wrote, How the user can install version 0.6.0 of this add-on, if it isn’t in the package repositories. What I had also written was, that a safe practice in using Latte-Dock would be, to keep the default Plasma 5 application-launcher in his panel, as a back-up, so that he will always have an application-launcher to click on, even if Latte-Dock crashes.

Well since then I have learned that a more avant-garde way exists to use Latte-Dock, which is, to place the default application-launcher onto the dock as well. This can easily be done because the default application launcher is a widget like any other, which can be dragged to this dock. As an additional detail, a method exists to get v0.6.0 of Latte-Dock to open the application launcher, by just pressing the Super Key, assuming that it has been added to the dock. The instructions I’ve just linked to do not count for later versions of Latte-Dock because those versions already have a check-box in their GUI, which does the same thing.

Hence, I’ve decided to be more progressive in my test-setup for Latte-Dock, and have also placed my only application-launcher onto this dock:


There is one detail which the reader should note however. I have kept one quick-launcher in the upper-left-hand corner of the screen, in the Plasma panel: The launcher that restarts Latte-Dock from the GUI with one click. The reason I have kept this safeguard is the observation that Latte-Dock can still crash from time to time, which means that the user would be without an application launcher, until he or she gets to restart the dock.

But this way, the layout of that desktop is even more different from the Windows-like layout – common to Plasma 5 and KDE 4 – than it only was a few days ago.