## 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.

## (Solved) How the Latest Wine-Staging Release, for Debian, Introduces a Packaging Problem: Unresolved Dependencies.

One piece of software which many Linux users benefit from is called “Wine”, which is an acronym that stands for ‘Wine Is Not an Emulator’ . This software allows some Windows programs to run under Linux, but has recently been made more powerful, to allow graphics-intensive games to run as well. The version of wine which I’ve been subscribing to is called ‘wine-staging’ , and contains the latest, bleeding-edge features that Wine is to contain, at any later point down the road.

But as I’ve been receiving updates to wine-staging, the latest update would have taken all my computers from version 4.0-rc2, to version 4.0-rc4, which means, ‘…Release Candidate 4′ . At that point, some of my computers could not install the update, because of unresolved package dependencies.

Apparently what’s been happening with Wine-Staging is twofold:

1. The original maintainers are no longer running the project, which also means that Wine is in the midst of a Code Freeze, and that present updates may offer fewer or no new features, from what Linux users are used to, and
2. In the interest of allowing the Windows games with the highest graphics requirements to run (potentially), the devs have nevertheless created a dependency of the latest Wine packages, on the OpenCL packages that install OpenCL natively under Linux.

‘OpenCL’ is a user-side API, which also requires system-side drivers for the specific graphics hardware, and which allows greatly parallel computations to be carried out on the GPU, instead of on the CPU. Apparently, some games use either ‘OpenCL’ or ‘CUDA’ these days, in order to incorporate complex Physics simulations into the game.

(I will assume that the version of CUDA which Wine emulates, requires OpenCL to be installed on the side of Linux.)

The problem under Debian which I’ve detected is, that the newly-introduced dependency of ‘wine-staging-amd64′ (as an example) is simply mainly:

‘ocl-icd-libopencl1′

Which means, that Wine will now insist on using the generic OpenCL drivers, that were developed for and by the Linux community, while not allowing the use of proprietary OpenCL drivers, that are closed-source, and that were developed by the manufacturers of each graphics card.

The problem with this is, that as users, we may only have one or the other OpenCL driver-set installed. We cannot install both the generic and the proprietary drivers. When we try to update Wine-Staging now, doing so will try to install the package above, which will also try to ‘kick out’ , any proprietary packages we may have installed, that provide OpenCL.

## How NOT to control our Gaming Keyboards, from a Linux computer.

One of the commodities which serious computer enthusiasts might want to buy, is a gaming keyboard. One reason may be the fact that by coincidence, gaming keyboards tend to be sound mechanical keyboards as well, which have per-key switches, which in turn have the desired tactile response, which bubble-keyboards today often lack.

But then, one of the features which gaming keyboards may add, is the ability to store and play back macros when in gaming-mode, those macros being key-sequences which a player needs to enter repeatedly, but tires of typing each time.

Another feature gaming keyboards can have, is fancy LED back-lights, which can even be customized to highlight different groups of keys, depending on how those groups of keys are important to certain uses of the KB. ( :1 )

I just bought the “ThermalTake eSports Poseidon Z RGB”, with Blue Key-Switches. The blue key-switches are switches that not only give good tactile feedback, but also make a distinct, high-pitched clicking sound, at exactly the right instant, during a key-press.

They have mechanical hysteresis.

One less-optimistic side-effect for this, under Linux, is the fact that some of the customization of this KB requires that proprietary software be used, of which there only exists the Windows version. The main functioning of the KB will work under Linux (Debian / Stretch), but if we want to program the layout-coloring / highlighting, then we need to use the proprietary software. These layouts can then be stored in 1 out of 5 Profiles, on the KB itself, which has its own 32-bit embedded micro-controller (i.e., this KB has its own CPU).

I tried to find out, whether I could install the software under a specific Wine folder, and then create symlinks to various device-files that exist natively under Linux, so that those device-files will appear as generic, DOS-type serial ports. Since Wine, by default, does not have direct access to the host machine’s USB-connected hardware.

The result was, that I bricked the keyboard. I needed some support from the retailer who sold me the keyboard, to recover a fully-functional instance.

The sum total of what this means, is that I can use this KB under Linux. I must just store its customizations using an old Windows laptop I have – a dual-boot ‘Acer Aspire 5020′ – after which I can disconnect the KB from that laptop, and connect it to my main (Linux) desktop again.

(Edit 04/05/2018 : )

(One problem with trying to photograph this keyboard with a simple phone-cam is, the fact that the LEDs produce light with high intensity. This light tends to saturate the light-sensor in a conventional camera-phone, which in turn results in a reduction, to the recorded color saturation. I.e., when the BG light-level is normalized by a camera-phone, the brightest primary colors are off-the-scale, but limited to scale as encoded.

Therefore, Blues will seem to look similar to Greens, and Yellows look similar to Whites.

When seen with the naked eye, all these colors look very deep. )

## Burning UDF 2.01 File Systems under Linux using a Script

In certain earlier postings, I wrote about the possibility of burning Blu-rays using the UDF File System, but using the GUI-application ‘K3b’, under Linux. One big problem with this approach was, that the version of UDF being applied was only 1.02, and that it was part of an ISO9660 / UDF bridge-format, which the earliest ISO9660-capable devices are able to read because of the ISO9660 backwards-compatibility, but which would present some of the error-correction capabilities that UDF is supposed to offer, to more-modern devices, via UDF 1.02 .

The issue with this would be, that UDF 1.02 may still not be robust enough, in its error-correction, and that we wish to burn UDF 2.01 File Systems, using open-source software, under Linux.

(Edit 10/22/2017 :

Actually, my recent findings seemed to suggest, that if we use ‘cdrecord’ to burn a Data-Disk Project, the UDF version it applies may already exceed that standard. )

This posting will describe how such a File System can be written using a script, which I have tested myself, but which does not offer any type of GUI at all.

First of all, in order for this to work, our Linux computer needs a reasonably recent Kernel version, because what the script will do is create an empty UDF File System, and then mount that as a loop-device, so that the same script can batch-copy the contents of the Present Working Directory, (the PWD, as it’s called under Linux,) to this File-System, after which the FS is unmounted, and burned onto a Disk.

If our Kernel-version is not recent, then to mount and/or to batch-copy may fail, and for no other reason. I’ve tested this to work using Kernel version ‘4.4.0-30-generic’, which is by far not the standard Kernel-version that my Debian / Jessie repositories would offer.

Another prerequisite is, the package called:

‘udftools’

Which we would use to create the empty File System, but which we won’t be using to do anything other than that. ‘udftools’ can be installed using our standard Debian package-manager, and offers support up to UDF 2.01 as its maximum. This package also contains the commands for growing a UDF File System, ‘wrudf’, but because I did not trust the package-version of UDF being offered, I chose not to use it. ‘wrudf’ is supposed to work somewhat like the ‘growisofs’ command would work, within a GUI-application such as K3b, but K3b does not recognize it out-of-the-box. In fact, I do not envy anybody, who needs to use ‘wrudf’ to grow their UDF File System.

This is the script which I have tested:

#!/bin/bash

if [ ! -e "/dev/sr1" ] ; then
exit 1
fi

if [ ! -x "/usr/bin/mkudffs" ] ; then
exit 1
fi

if [[ $UID -ne 0 ]] ; then echo "This script must be run as root" 1>&2 exit 1 fi rm -f /tmp/image.udf echo "Creating Sparse File..." truncate -s 24G /tmp/image.udf echo "Formatting File System..." mkudffs --media-type=dvdram --spartable=2 --vid="BD_$1" /tmp/image.udf || \
exit 1

echo "Mounting File System..."

mkdir -p /media/udfimage || exit 1

mount -t udf -o loop,rw /tmp/image.udf /media/udfimage
rm -rf /media/udfimage/lost+found
chown -R root:root /media/udfimage

echo "Writing to File System. This may take some time..."
cp -rf ./* /media/udfimage

echo "Unmounting File System..."
umount /media/udfimage

echo "Burning File System. This may take some time..."

unset SUDO_COMMAND
export GENISOIMAGE=/usr/bin/genisoimage

growisofs -dvd-compat -Z /dev/sr1=/tmp/image.udf

echo "Cleaning Up..."
rm -f /tmp/image.udf

eject
echo "Done."




There are a few observations about this script, which anybody would wish to know about, who might want to use it. First of all, this script will expect one command-line argument, which is going to be prefixed with the string ‘BD_’ and then applied as the volume-ID of the file-system to be created. This will appear on computers, and on some playback-devices, as the name of whatever disk we have inserted. The exact naming is not critical, just as the exact naming for ISO9660-based Volumes may not be critical. It’s a formality which should be taken care of.

Secondly, this script expects to be run while the PWD is whatever directory we wish at the root of our created File System, and expects to be run as root. This poses an obvious security gap, as anybody could use this script in order to burn a copy of a folder, which he or she never had permission to read, if he could get root privileges with this script.

I have done my best to allow this script to be run using ‘sudo’, if it was placed in my system-directory:

‘/usr/local/bin/UDF-Burn.sh’

But, I have never tested whether it can be made to run using ‘sudo’ in this way. It might not, because it consists of a shell-script, which might only cause the script-interpreter to be elevated to ‘root’, but not all the commands within the script! My readers may test this as they wish, but since I’m the only real user of my own computers, I’ve always just felt comfortable to make myself ‘root’, and then just to run this script.

In the interest of allowing this script to be run via ‘sudo’, I have set the variables ‘SUDO_COMMAND’ and ‘GENISOIMAGE’ as would be appropriate. This has to do with the behavior of ‘growisofs’ to use an external helper, in order actually to grow certain types of File Systems, and an unscrupulous user could run this as ‘sudo’, and could set this external command to be anything he wanted it to be. It would allow an unscrupulous user to execute an arbitrary program as root, if my script did not take care to re-set this variable to the correct path.

The reader may be reassured to know, that by default, if one of his scripted commands throws an error, the execution of the script will continue after that command, as if nothing had gone wrong. This discovery actually cost me several blank disks, until I had sprinkled a few error-checking commands into it.

Hence, the output which the user sees could be:

Error: ‘/tmp/image.udf’  Is A Directory

After which Bash will try to keep running the rest of the script… And then, the next important question becomes, whether the ‘mkudffs’ command can eventually still execute successfully, which I did bracket, If it cannot store the File-System Image it creates at that location…

I also figured, that I was more likely to uninstall the package ‘udftools’ by accident, than I was, eventually to downgrade the kernel, on a computer which I had already established, could mount a UDF 2.01 File System correctly. But, if the reader has such fears, he can also just add:

|| exit 1

To the mount command…

I suppose another observation I should add about how this script will behave, is that it will create an empty, 24GB File-System Image right off the bat, and start to build the data within. A possible nuisance, because this would represent the total amount of raw space that a device would hold – unformatted – and the entire 24GB will be written to the Blu-ray disk every time the script is used, regardless of how little data we might actually want written to the disk. I chose 24GB because the true amount of raw space on a single-layered Blu-ray is actually ~24.8GiB, and the format does not allow for fractional values to be put on the command-line. So for our purposes, we only have 24.0GiB of raw, unformatted space to work from.

I suppose I could have sat down with a calculator, to determine that 24.7GiB ~= 25292MiB …

(Updated 10/24/2017 : )