Jump to content

User:ScotXW/Video game development software for Linux

From Wikipedia, the free encyclopedia
< User:ScotXW
This is an old revision of this page, as edited by ScotXW (talk | contribs) at 02:06, 6 July 2014 (→What software to use?: not Nvidia PerfKit, its Windows-only). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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.

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.

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.

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:


Retrieved from "https://en.wikipedia.org/w/index.php?title=User:ScotXW/Video_game_development_software_for_Linux&oldid=615770485"