User:ScotXW/Video game development software for Linux

The Linux API is composed out of the System Call Interface of the Linux kernel, the GNU C Library (by GNU), libdrm, libalsa and libevedv (by freedesktop.org).

Distribution of binaries: You develop for the Linux API, but what do you compile against? x32 ABI? Linux Standard Base? Which PMS to use? .deb or .rpm? Valve's SteamOS is Debian-based and includes Steam for distribution! Is Ubuntu Software Center suitable alternative? Anything else?

While playing with Category:Video game development software for Linux I stumbled over some problems with the article "Linux gaming" in its version: July 2014. Even after extensive work, cf. August 2013 it is still too extensive.

• John Carmack: Linux is not the right platform for video games (Aug 2013 "(XInput and Xaudio2 are good APIs!)" "A good shim layer should have far less impact on performance than the variability in driver quality."
  • Properly evangelized, with Steam as a monetized distribution platform, this is a plausible path forward.
• Programming Linux Games
• OpenAL?
• http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX
• http://blog.wolfire.com/2010/01/DirectX-vs-OpenGL-revisited

• If your game (as shipped) depends on more than libGL, libALSA (also called libasound and alsa-lib), libX11/libWayland-client, (or libopenal or libao or liboss), you're doing something wrong.

PhysX runs natively on Linux, but it has not been possible to use GPU acceleration. Computation could only be done on the CPU. AMD TrueAudio is used equivalently. BOTH, PhysX as well as TrueAudio require some kernel component, a device driver for the Linux kernel, though PhysX has one: the Nvidia driver. Sadly, PhysX interfaces with it over CUDA.

What APIs to target?

Linux kernel/glibc ⟨ Linux kernel–user space API ⟩⟨ middleware ⟩⟨ Game engines could be programmed to take advantage of all the hardware features, but they are not because they have to work through the software layers and APIs that stand between themselves and the hardware.

Anything has to talk to the kernel to get to the hardware, and anything from the hardware arrives through the kernel at user-space. evdev feeds input stuff. The game engine is on the far right and includes some middleware and especially a rendering engine.

Kernel API

program for the Linux kernel–user space API = Linux kernel System Call Interface + GNU C Library = mostly POSIX/Single UNIX Specification-compliant but not UNIX® certified. Also, Linux has system calls additionally to those in POSIX!

• Android: Google replaced glibc with their darn libBionic. bionic does NOT aim to be glibc-compatible. There is libHybris as compatibility layer, but that would not only cost some performance, it also seems that libBionic is pretty limited. Serious video game developers leave "Android" to app-developers programming in Java.
• Tizen, Sailfish OS use glibc/uClibc.
• OS X is a UNIX® certified system, and both OpenGL and SDL are available; DirectX is not.

other APIs

• Microsoft's own proprietary DirectX for Microsoft Windows contains a couple of APIs, the current ones being Direct3D11, XAudio2 and XInput2. All APIs in DirectX have a considerable amount of development behind them and there have been a couple of complete design failures and a couple of intensive revamps! ... but Direct3D11 still does not make game developers happy, Direct3D12 has been announced as another total re-design for the year 2015.
  • XBox One is also said to use DirectX exclusively, so no OpenGL; but SDL is supposed to work in the future, http://www.libsdl.org/tmp/SDL/README-winrt.txt
  • PlayStation 4 introduced GNM, GNMX and even PlayStation Shader Language (PSSL) for rendering and something else for sound and input.
  • Wii U uses some TeraScale graphics from AMD, probably they use OpenGL

Graphics

Whether rendering calculations are outsourced through the high-level OpenGL or through the low-level Mantle, kernel components like DRM/GEM/TTM regulate access and do book-keeping.

• rendering: use latest OpenGL or latest OpenGL ES; cross-platform

It may be true that “OpenGL has been held hostage by CAD companies for over a decade. That is why ES was created”, but it is the only rendering API available on all operating systems. Hmm, maybe it is not available on the XBox'es... natürlich.

Playing around with low-level access through the system calls offered by DRM or KMS driver is probably not interesting. Neither are Render nodes or the GBM for serious game developers. On the other sides, John D. Carmack did work Utah GLX because the available Linux graphics were not good enough. Neither was the DirectX version available then!

Graphics device drivers

• AMD's proprietary graphics device driver "Catalyst" has been available for Linux long since and supports OpenGL, OpenGL ES, etc.; their Mantle API is only available for Windows though...
• Nvidia's proprietary graphics device driver for Linux is excellent, it is as good as the Windows variant

The free and open-source graphics device driver for Linux are continuously working their way up the food chain. Each and every one is composed out of five parts:

1. Linux kernel component DRM
2. Linux kernel component KMS driver: basically the device driver for the display controller
3. user-space component libDRM
4. user-space component in Mesa 3D; currently most of these components are written conforming to the Gallium3D-specs and ideas
5. und natürlich: a special and distinct 2D graphics device driver for the darn X Window System; but this component is finally about to be replaced by Glamor!

Audio

• sound: Simple DirectMedia Layer (SDL) is recommended, I don't know whether SDL is as good as XAudio2, development of SDL 2.x is financed by Valve Corporation.

Input

• input: Simple DirectMedia Layer (SDL) is recommended, I don't know whether SDL is as good as XInput2, development of SDL 2.x is financed by Valve Corporation.

Development utilizes other available APIs, see Category:Linux APIs.

Windowing system

• the past was X Window System: clients use libX or XCB; support in various toolkits available; uses GLX, accepts evdev through XKB
• the future is Wayland: clients use libwayland-client; support in Qt 5, GTK+ 3.10; uses EGL/GBM, accepts evdev also through XKB

As long as you do not develop your application to run in a window, the windowing system should not matter much..., I think.

Graphics rendering on Linux has been severely slowed down by the darn X Window System, don't even bother to go through its history, see the short version: here; Glamor will further reduce the burden for everybody!

Hardware access

The last operating that allowed user-space direct hardware access was DOS... consoles also have an operating system, and given their DRM-stuff, there will always be some limitations unless you ditch the operating system completely and program completely on the bare metal.

What software to use?

Even through Linux is rather used by people who program than by people who do not, the software available for development could always be better: especially graphical user interface often lack one feature or the other. And its always being worked on.

Graphics debugging seems to be a problem, thus Valve developed the VOGL OpenGL debugger. For a long time Valgrind /ˈvælɡrɪnd/ has been exclusively available for Linux, then somebody did some ports to OS X and Android, but not yet to Windows.

• Nvidia PerfKit, a comprehensive suite of performance tools to help debug and profile OpenGL and Direct3D applications, is not available for Linux. As written the FOSS drivers are being worked on, e.g. http://www.phoronix.com/scan.php?page=news_item&px=MTczNTQ

Milk Category:Software testing tools, Category:Debuggers, Category:Profilers, etc. for suited software. It does not have to be free and open-source! It just has to run on Linux.

Available know-how and experience in porting games to Linux

In case somebody has been developing for Microsoft Windows exclusively, maybe even Microsoft Visual Studio...

There have been a couple of companies in the business of Linux porting, in Wikipedia see Category:Linux game porters. Simple DirectMedia Layer v2.x was nicely introduced at the SteamDevDays 2014 (http://www.steamdevdays.com/) on 11 February 2014. Who is interested in a better article, should watch at least these two videos by Ryan C. Gordon:

• Getting Started with Linux Game Development
• Game Development with SDL 2.0
• slides for both available here: http://icculus.org/SteamDevDays/

Sandbox

"Game programmers should spend a great deal of time developing a good graphics engine, and a designer should place a high priority on obtaining quality artwork for a game, enlist the help of a skilled digital artist to produce acceptable game artwork."

• Input Subsystem
• Display Subsystem
• Audio Subsystem
• Network Subsystem
• Update Subsystem
• Game Loop

• Display Subsystem

The display subsystem conveys the game’s status to the player in a visually impressive way, whether through 2D or 3D graphics. Regardless of the type of graphics produced by the display subsystem, the structure of the code is substantially the same.

The display subsystem is responsible for taking advantage of the available 3D accelerator hardware. Taking advantage of 3D accelerator hardware is not automatic and requires special effort by the programmer, which is usually accomplished through an API (essentially a big library of subroutines) like OpenGL or Mantle.

• Update Subsystem

A game engine has to track a lot of rapidly changing data, such as the state of the player and the condition of each enemy—information that must be updated frame by frame to keep the game responsive. The "update subsystem" manages the "keeping track". The update subsystem is the game’s brain, 'cause it is the system where the game’s rules can be applied. This includes rules for movement upon the player, “plays” the role of each enemy (which might involve a certain amount of artificial intelligence), ensures that every object is within the allowed boundaries, and inflicts injuries. It could almost be said that the other game modules are merely interfaces to the update subsystem.

The update subsystem should be kept separate from the "game loop".

• Game Loop

The game (see Figure 1–1) loop is the “glue” that binds the various game subsystems. It is simply a while loop that runs throughout the entire game, looping anywhere from 30 to 60 times per second. The game loop invokes the correct routines to gather input from the player and from the network, updates

the status of all objects in the game, draws the next frame of graphics, and produces audio. While this process may sound complicated, it is actually quite trivial, because all of this functionality is provided by the game’s input, network, graphics, and audio subsystems. The game loop should start as soon as the game’s other subsystems have been initialized, and should end when the player exits the game. It may be a good idea to separate the menu system from the main game loop in some cases, but doing so could actually complicate the game’s code. With a properly written game loop, a game becomes a “state machine” that acts on its current state based on the player’s input. Organization is important too, since the game loop sequences the other subsystems. This should not be a haphazard decision; for instance, the data gathered from the networking subsystem often influences the decisions of the other subsystems, so it should be invoked first. The graphics subsystem should probably be last, since it reflects the data generated by all of the other subsystems. As you can see, a game engine is conceptually simple, but the devil is in the details.

Marshalling

In the Microsoft Windows family of operating systems the entire device drivers for Direct3D are kernel-mode drivers. The user-mode portion of the API is handled by the DirectX runtime provided by Microsoft.

This is an issue because calling kernel-mode operations from user-mode requires performing a system call, and this inevitably forces the CPU to switch to "kernel mode". This is a slow operation, taking on the order of microseconds to complete. During this time, the CPU is unable to perform any operations. As such, minimizing the number of times this switching operation must be performed would optimize performance to a substantive degree.

Linux OpenGL drivers, are split in two: a kernel-driver and a user-space driver. The user-space driver, does all the translation of OpenGL commands into machine code to be submitted to the GPU. To reduce the number of system calls, the user-space driver implements marshalling. If the GPU's command buffer is full of rendering data, the API could simply store the requested rendering call in a temporary buffer and, when the command buffer is close to being empty, it can perform a switch to kernel-mode and add a number of stored commands all at once.

Debugging

On Mac OS X, we have a whole suite of free OpenGL tools including the profiler, driver monitor, and shader builder. On Windows and Linux there is the NVIDIA PerfKit, as well as AMD's GPU PerfStudio and ShaderAnalyzer. If anyone has used both sets of tools and is informed about how they compare, please post your experiences in the comments!

Low-level rendering API

• http://www.firaxis.com/?/blog/single/why-we-went-with-mantle
  • Mantle changes things by working at a lower level than its competitors. Much of the work that drivers used to do on an application’s behalf is now the responsibility of the game engine. This means that the Mantle API is able to be backed by a very small, simple device driver, which is thus considerably faster. It also means that this work, which must still be done, is done by someone with considerably more information, the game engine!. Because the engine knows exactly what it will do and how it will do it, it is able to make design decisions that drivers could not.

Vulkan

Main articles: Vulkan (API) and SPIR

Mantle, Metal, DX12 are all proprietary API’s that enable the GPU to be programmed in a very explicit way. Vulkan (API), with its Mantle roots, is also a very explicit API, and it achieves this in a cross-OS, cross-GPU fashion. To better understand the real benefit of these explicit APIs, we need to go back to their inspiration: the game console. For years, the console game engineers have been developing their software directly on the hardware. The extended life-cycles of video game consoles allows these platforms to reach a large audience; and using a 3D API can get in the way of creating a better game engine. The engine developers took over the responsibilities of building command buffers, keeping them in flight and managing the GPU resources required to ensure the hardware worked properly and efficiently. Ultimately the console game engines were able to squeeze the maximum performance out of the GPU while still leaving plenty of CPU bandwidth available for the game logic itself.

Traditional PC and mobile hardware are in a different boat. With new and better hardware coming out very frequently from competing vendors, change comes quickly on these platforms. 3D APIs are necessary to insulate the engine developer from a proliferation of hardware traditionally at a cost to overall performance. The task of building command buffers, keeping them in flight and managing GPU resources falls primarily to the drivers. Efficiently getting the most performance out of PC Hardware has become more complicated than the console way of programming directly to the hardware. The previously mentioned explicit APIs recognize that challenge, and have embraced the type of programming traditionally done on consoles allowing game engine developers to write more directly to the hardware. Vulkan's explicit approach exposes the nature of how modern GPUs work while still managing to abstract away most of the hardware and OS differences. The result is a manageable number of special cases that can be written by engine developers to enable a broad range of hardware to work more effectively than ever.