Forgot your password?
Close
typodupeerror
Games Linux

Developing Games On and For Linux/SteamOS 145

Posted by Soulskill
from the year-of-linux-on-the-console dept.
An anonymous reader writes "With the release of SteamOS, developing video game engines for Linux is a subject with increasing interest. This article is an initiation guide on the tools used to develop games, and it discusses the pros and cons of Linux as a platform for developing game engines. It goes over OpenGL and drivers, CPU and GPU profiling, compilers, build systems, IDEs, debuggers, platform abstraction layers and other tools."
This discussion has been archived. No new comments can be posted.

Developing Games On and For Linux/SteamOS More

Developing Games On and For Linux/SteamOS

Comments Filter:

  • Some Additions (Score:4, Interesting)

    by Anonymous Coward on Wednesday December 25, 2013 @08:24PM (#45784591)
    • For Linux IDEs the article misses Netbeans which has a stable and reliable C/C++ Plugin that directly supports CMake projects .
    • A list of c++ cross platform libraries is never complete without mentioning boost - severall C++11 features where inspired or even copied from it.
    • OpenGL dropped a lot of its old API and you should develop against the Core profile to get most out of performance enhancements.
    • Since GLSL shaders are a must with the core API you should make soure to specify a shader version in every shader (at least with the NVIDIA driver this forces it to be stricter) one of the portability problems is that NVIDIA compiles both CG shaders and GLSL shaders with the same compiler and it currently allows you to use CG constructs in GLSL code.
    • Test running code on AMD/Intel/NVIDIA cards shows that each of them varies on how strict they parse GLSL, to make sure that your code runs on all of them you have to test against all of them (thought testing against intel might be enough, from limited tests it seemed to be the strictest).
    • CPU profiling: Until you get into very small ranges you can sample by randomly stopping the program in a debbuger - the line appearing most often in the stacktrace is likely the culprit.
    • GPU profiling/debbuging: since AMD bought and then killed the vendor agnostic gDebbuger (after releasing an AMD only version) before releasing CodeXL the only alternative is a windows setup with visual studio (not free - express does not support plugins) and Nvidia visual Insight(free). Older versions of gDebbuger might still be available but are rather limited.

The more cordial the buyer's secretary, the greater the odds that the competition already has the order.

Close