User:ScotXW/Video game development software for Linux

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."
• 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

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

• 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 simple 2D graphics, or advanced 3D rendering (the type of graphics you use doesn’t matter, as long as they are appropriate for the game). 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 display hardware. Serious gamers often equip their machines with snazzy 3D graphics cards, which can bring enormous performance and quality improvement to 3D games. However, this performance boost is not automatic and requires special effort by the programmer, which is usually accomplished through an API (application programming interface, essentially a big library of routines) like OpenGL. 3D acceleration is beyond the scope of this book, but we’ll demonstrate how to get OpenGL up and running in Chapter 4. Before you can show off your graphics code, you’ll need something to display. Although it is common for programmers to develop temporary artwork for testing purposes, few are skilled artists, and they usually find it necessary to enlist the help of a skilled digital artist to produce acceptable game artwork. Players are a finicky bunch, and they are most intolerant of subpar graphics. 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.

• Update Subsystem

Games generally have to track a lot of rapidly changing data, including the state of the player and the condition of each enemy—information that must be updated frame by frame to keep the game moving. The update subsystem manages this data. The update subsystem is the game’s brain. It enforces the game’s 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.

Don't throw the update subsystem into 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.

Mode switching (Linux/Windows)

A more substantive and modern performance difference arises because of the structure of the hardware drivers provided by hardware developers. Under DirectX, IHV device drivers are kernel-mode drivers installed into the operating system. The user-mode portion of the API is handled by the DirectX runtime provided by Microsoft. Under OpenGL however, the IHV driver is broken into two parts: a user-mode portion that implements the OpenGL API, and a kernel-mode driver that is called by the user-mode portion.

This is an issue because calling kernel-mode operations from user-mode requires performing a system call (i.e. making the CPU 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. For example, 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. This is known as marshalling.

Because Direct3D IHV drivers are kernel-mode, and the user-mode code is out of the IHV's hand, there is no chance for such optimizations to occur. Because the Direct3D runtime, the user-mode portion that implements the API, cannot have explicit knowledge of the driver's inner workings, it cannot effectively support marshalling. This means that every Direct3D call that sends commands to the hardware must perform a kernel-mode switch, which again, takes time in the order of microseconds to complete. This has led to a number of behaviors regarding use of Direct3D, the most important being the need for submitting large batches of triangles in one function call.

Since OpenGL's IHV drivers have a user-mode component to them, IHVs have the ability to implement marshalling, thus improving performance. There is still kernel-mode switching, but the theoretical maximum number of switches under OpenGL implementations is simply equal to the Direct3D standard behavior.

Direct3D 10, the release included with Windows Vista allows portions of drivers to run in user-mode, making it possible for IHVs to implement marshalling, thus bringing the two back into relative performance parity. Mac OS X's OpenGL system is very similar, where IHVs implement a simpler version of the OpenGL API (with both user and kernel mode components), and Apple's additions to the runtime provide the direct interface to the user code, and some basic work to make IHVs' jobs easier.

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.