The DarkMod Wiki - User contributions [en]

DarkRadiant - Compiling in Linux

2020-12-16T13:25:50Z

Orbweaver: No need to install libtool any more

== Install Required Packages ==

=== Ubuntu 20.04 ===

Copy and paste the following into a terminal:

sudo apt-get install git g++ gettext cmake pkg-config zlib1g-dev libjpeg62-dev libxml2-dev libsigc++-2.0-dev libgtest-dev
sudo apt-get install libwxgtk3.0-gtk3-dev libpng-dev libftgl-dev libglew-dev libalut-dev libvorbis-dev python3-dev pybind11-dev

=== openSUSE Tumbleweed ===

Copy and paste the following into a terminal:

sudo zypper install git libtool automake gcc-c++ gettext-tools zlib-devel libjpeg62-devel libxml2-devel libsigc++2-devel gtest
sudo zypper install wxWidgets-3_0-devel ftgl-devel glew-devel libvorbis-devel freealut-devel python38-devel python3-pybind11-devel

=== Mageia 8 ===

Copy and paste the following into a terminal, run as user who has the required permissions to install the packages:

sudo urpmi git make automake libtool gcc-c++ libzlib-devel libjpeg-devel libwxgtku3.0-devel libsigc++2.0-devel
sudo urpmi libftgl-devel libglew-devel libpython3-devel libopenal-devel libfreealut-devel libvorbis-devel lib64gtest-devel

=== Ubuntu 19 / 18 / 17 ===

Copy and paste the following into a terminal:

sudo apt-get install git g++ gettext automake libtool pkg-config zlib1g-dev libjpeg62-dev libwxgtk3.0-dev libxml2-dev
sudo apt-get install libsigc++-2.0-dev libpng-dev libftgl-dev libglew-dev python3-dev libalut-dev libvorbis-dev pybind11-dev

=== Debian 9 ===

Copy and paste the following into a terminal:

sudo apt-get install git automake libtool pkg-config gettext zlib1g-dev libjpeg62-turbo-dev libwxgtk3.0-dev
sudo apt-get install libxml2-dev libsigc++-2.0-dev libpng-dev libftgl-dev libglew-dev libalut-dev libvorbis-dev python-dev pybind11-dev

=== Fedora 26 / 25 ===
Copy and paste the following into a terminal:

sudo dnf install git automake libtool gcc-c++ zlib-devel libjpeg-turbo-devel wxGTK3-devel libxml2-devel libsigc++20-devel
sudo dnf install libpng12-devel ftgl-devel glew-devel libvorbis-devel freealut-devel python-devel pybind11-devel

Note that the wxGTK package does not yet support Wayland environments, which is the default since Fedora 25 (DarkRadiant will just segfault during startup). You'll need to [https://fedoraproject.org/wiki/Changes/WaylandByDefault deactivate it] for the moment being.

=== Arch Linux ===
The following packages are requred after starting from an Anarchy installation using Gnome as Window Manager.

sudo pacman -S automake libtool wxgtk ftgl glew freealut pybind11

=== CentOS 7 x64 ===

Copy and paste the following into a terminal, run as user who has the required permissions to install the packages:

sudo yum -y install gcc gcc-c++ git automake libtool zlib-devel libjpeg-turbo-devel wxGTK3-devel libxml2-devel
sudo yum -y install libsigc++20-devel ftgl-devel glew-devel boost-devel openal-soft-devel freealut-devel libvorbis-devel python-devel

CentOS 7 ships with an older compiler, so you'll need to install a more recent GCC first (following the directions on [https://stackoverflow.com/questions/36327805/how-to-install-gcc-5-3-with-yum-on-centos-7-2 stackoverflow]):

sudo yum install centos-release-scl
sudo yum install devtoolset-4-gcc*
scl enable devtoolset-4 bash

Note that the <tt>wxGTK3-devel</tt> package doesn't create a <tt>wx-config</tt> symlink in the <tt>/usr/bin</tt> directory, that's why you need to pass an additional <tt>--with-wx-config=/usr/bin/wx-config-3.0</tt> argument to the ./configure script below, like this:

./configure --enable-darkmod-plugins --with-wx-config=/usr/bin/wx-config-3.0

=== Slackware 14.2 ===

Slackware doesn't provide precompiled packages on the one hand (unlike Debian or Arch), but already ships with a lot of libraries on the other. Stuff like git, automake, libtools and development libraries like zlib and boost are already present, but wxWidgets, openAL, ALut and FTGL need to be installed by means of a SlackBuild script. The following has been done in Slackware 14.2, so your mileage may vary.

Download the Source tarballs and the SlackBuild packages from these URLs:

* https://slackbuilds.org/repository/14.2/libraries/wxGTK3/
* https://slackbuilds.org/repository/14.2/libraries/ftgl/
* https://slackbuilds.org/repository/14.2/libraries/OpenAL/
* https://slackbuilds.org/repository/14.2/libraries/freealut/

Download and extract the SlackBuild <tt>.tar.gz</tt> files in your <tt>~/Downloads</tt> folder (or anywhere else where you want to have them). For instance, the wxGTK3 package can be untar'd like this:

tar xzf wxGTK3.tar.gz
cd wxGTK3
chmod +x wxGTK3.SlackBuild

Do this for all of the above libraries, that should give you the directories <tt>ftgl/</tt>, <tt>OpenAL/</tt>, <tt>wxGTK3/</tt> and <tt>freealut/</tt>. Next, download the Source Tarballs (the <tt>.tar.bz2</tt>) files from the links above and place them next to the corresponding SlackBuild script. Then run the scripts for each of them and install the build output in your system in a second step:

./wxGTK3.SlackBuild

This produced (on my end at least) the package <tt>/tmp/wxGTK3-3.0.2-i486-2_SBo.tgz</tt> which can be installed by the <tt>installpkg</tt> command:

installpkg /tmp/wxGTK3-3.0.2-i486-2_SBo.tgz

Do the same for the rest of the libraries (ftgl, OpenAL, freealut). Be aware that the freealut package depends on the OpenAL package, so you need to do the OpenAL one first. Once you have these installed, you can proceed to the build section (<tt>git clone</tt> and <tt>configure</tt> and <tt>make</tt>).

=== Gentoo ===

DarkRadiant can be built and installed from an unofficial ebuild repository (overlay). The easiest way to do this is with [https://packages.gentoo.org/packages/app-portage/layman app-portage/layman], which must be installed with the <tt>git</tt> use flag.

In the 'overlays' section in <tt>/etc/layman/layman.cfg</tt>, add:

https://raw.githubusercontent.com/varingst/varingst-overlay/master/overlay.xml

Then fetch and add the overlay:

# layman -f -a varingst

Now that the overlay is added, you can build and install DarkRadiant with Portage:

# emerge darkradiant

To sync the overlay, either do it manually with layman:

# layman -s varingst

Or look into the [https://wiki.gentoo.org/wiki/Project:Portage/Sync various ways to hook into the portage sync system].

=== Distributions with GCC 4.8 or earlier ===
DarkRadiant's codebase makes heavy use of C++11 features, in particular std::regex which has been supported from GCC 4.9 on. Not all distributions ship with g++ 4.9 by default (for example Ubuntu 14.04 does not), but it's possible to install a more recent compiler suite. Get the GCC 4.9 package and ensure that the makefiles are called with the correct setup, e.g.
CXX="g++-4.9" ./configure --enable-darkmod-plugins && make -j3 && make install

=== Older Distributions / Compiling DarkRadiant 1.8 and older ===
The instructions about how to compile DR 1.8 (based on GTK) in distributions published in 2012 and older have been removed. They should still be in the [http://wiki.thedarkmod.com/index.php?title=DarkRadiant_-_Compiling_in_Linux&oldid=18927 history] of this page, should they ever be needed.

== Obtain the source ==

Make sure you have the git client installed, this is covered in the package installation commands above.
Next, change to the directory where you want the source code to be in and then clone the Git repository with:

git clone git://github.com/codereader/DarkRadiant.git

Once the initial clone is done, the source can be updated to the latest version from inside the working directory with:

git pull

== Configure and Compile ==
DarkRadiant employs the CMake build system under Linux as used in many open-source projects. Make sure you have the CMake toolchain downloaded, this is covered in the package installation commands above.

To build DarkRadiant, run the typical chain of CMake and make commands:

cmake .
make
[sudo] make install

By the above, a release build will be created; if a debug build is required pass the <tt>-DCMAKE_BUILD_TYPE=Debug</tt> option to the cmake command script.

Other points to note about the configure process:

* The DarkMod-specific plugins are built by default, the <tt>-DENABLE_DM_PLUGINS=OFF</tt> argument will disable them.
* The CMake script autodetects required dependencies, and will conditionally enable optional components of DarkRadiant (such as the sound plugin) based on what it finds.
* For quick testing of a DarkRadiant build, it is desirable to install it into a temporary location rather than the default of <tt>/usr/local</tt>; for this, simply pass a prefix option such as <tt>-DCMAKE_INSTALL_PREFIX=/tmp/dr</tt> to cmake, after which DarkRadiant will be installed in <tt>/tmp/dr/bin/darkradiant</tt>.

=== Multiprocessor Systems ===

You can pass the <tt>--jobs=N</tt> parameter to make:
make --jobs=2
to use more than one processor for the compilation. This will eat lots of RAM, so don't do this on machines with little available memory.

=== Building a .deb package ===

To build a Debian/Ubuntu package, simply run

dpkg-buildpackage -rfakeroot

in the main <tt>darkradiant</tt> directory. The .deb will be created in the parent directory.

{{coding}}
{{darkradiant|sort=Compilation}}

DarkRadiant - Compiling in Linux

2020-12-16T13:25:24Z

Orbweaver: Install CMake rather than Automake

== Install Required Packages ==

=== Ubuntu 20.04 ===

Copy and paste the following into a terminal:

sudo apt-get install git g++ gettext cmake libtool pkg-config zlib1g-dev libjpeg62-dev libxml2-dev libsigc++-2.0-dev libgtest-dev
sudo apt-get install libwxgtk3.0-gtk3-dev libpng-dev libftgl-dev libglew-dev libalut-dev libvorbis-dev python3-dev pybind11-dev

=== openSUSE Tumbleweed ===

Copy and paste the following into a terminal:

sudo zypper install git libtool automake gcc-c++ gettext-tools zlib-devel libjpeg62-devel libxml2-devel libsigc++2-devel gtest
sudo zypper install wxWidgets-3_0-devel ftgl-devel glew-devel libvorbis-devel freealut-devel python38-devel python3-pybind11-devel

=== Mageia 8 ===

Copy and paste the following into a terminal, run as user who has the required permissions to install the packages:

sudo urpmi git make automake libtool gcc-c++ libzlib-devel libjpeg-devel libwxgtku3.0-devel libsigc++2.0-devel
sudo urpmi libftgl-devel libglew-devel libpython3-devel libopenal-devel libfreealut-devel libvorbis-devel lib64gtest-devel

=== Ubuntu 19 / 18 / 17 ===

Copy and paste the following into a terminal:

sudo apt-get install git g++ gettext automake libtool pkg-config zlib1g-dev libjpeg62-dev libwxgtk3.0-dev libxml2-dev
sudo apt-get install libsigc++-2.0-dev libpng-dev libftgl-dev libglew-dev python3-dev libalut-dev libvorbis-dev pybind11-dev

=== Debian 9 ===

Copy and paste the following into a terminal:

sudo apt-get install git automake libtool pkg-config gettext zlib1g-dev libjpeg62-turbo-dev libwxgtk3.0-dev
sudo apt-get install libxml2-dev libsigc++-2.0-dev libpng-dev libftgl-dev libglew-dev libalut-dev libvorbis-dev python-dev pybind11-dev

=== Fedora 26 / 25 ===
Copy and paste the following into a terminal:

sudo dnf install git automake libtool gcc-c++ zlib-devel libjpeg-turbo-devel wxGTK3-devel libxml2-devel libsigc++20-devel
sudo dnf install libpng12-devel ftgl-devel glew-devel libvorbis-devel freealut-devel python-devel pybind11-devel

Note that the wxGTK package does not yet support Wayland environments, which is the default since Fedora 25 (DarkRadiant will just segfault during startup). You'll need to [https://fedoraproject.org/wiki/Changes/WaylandByDefault deactivate it] for the moment being.

=== Arch Linux ===
The following packages are requred after starting from an Anarchy installation using Gnome as Window Manager.

sudo pacman -S automake libtool wxgtk ftgl glew freealut pybind11

=== CentOS 7 x64 ===

Copy and paste the following into a terminal, run as user who has the required permissions to install the packages:

sudo yum -y install gcc gcc-c++ git automake libtool zlib-devel libjpeg-turbo-devel wxGTK3-devel libxml2-devel
sudo yum -y install libsigc++20-devel ftgl-devel glew-devel boost-devel openal-soft-devel freealut-devel libvorbis-devel python-devel

CentOS 7 ships with an older compiler, so you'll need to install a more recent GCC first (following the directions on [https://stackoverflow.com/questions/36327805/how-to-install-gcc-5-3-with-yum-on-centos-7-2 stackoverflow]):

sudo yum install centos-release-scl
sudo yum install devtoolset-4-gcc*
scl enable devtoolset-4 bash

Note that the <tt>wxGTK3-devel</tt> package doesn't create a <tt>wx-config</tt> symlink in the <tt>/usr/bin</tt> directory, that's why you need to pass an additional <tt>--with-wx-config=/usr/bin/wx-config-3.0</tt> argument to the ./configure script below, like this:

./configure --enable-darkmod-plugins --with-wx-config=/usr/bin/wx-config-3.0

=== Slackware 14.2 ===

Slackware doesn't provide precompiled packages on the one hand (unlike Debian or Arch), but already ships with a lot of libraries on the other. Stuff like git, automake, libtools and development libraries like zlib and boost are already present, but wxWidgets, openAL, ALut and FTGL need to be installed by means of a SlackBuild script. The following has been done in Slackware 14.2, so your mileage may vary.

Download the Source tarballs and the SlackBuild packages from these URLs:

* https://slackbuilds.org/repository/14.2/libraries/wxGTK3/
* https://slackbuilds.org/repository/14.2/libraries/ftgl/
* https://slackbuilds.org/repository/14.2/libraries/OpenAL/
* https://slackbuilds.org/repository/14.2/libraries/freealut/

Download and extract the SlackBuild <tt>.tar.gz</tt> files in your <tt>~/Downloads</tt> folder (or anywhere else where you want to have them). For instance, the wxGTK3 package can be untar'd like this:

tar xzf wxGTK3.tar.gz
cd wxGTK3
chmod +x wxGTK3.SlackBuild

Do this for all of the above libraries, that should give you the directories <tt>ftgl/</tt>, <tt>OpenAL/</tt>, <tt>wxGTK3/</tt> and <tt>freealut/</tt>. Next, download the Source Tarballs (the <tt>.tar.bz2</tt>) files from the links above and place them next to the corresponding SlackBuild script. Then run the scripts for each of them and install the build output in your system in a second step:

./wxGTK3.SlackBuild

This produced (on my end at least) the package <tt>/tmp/wxGTK3-3.0.2-i486-2_SBo.tgz</tt> which can be installed by the <tt>installpkg</tt> command:

installpkg /tmp/wxGTK3-3.0.2-i486-2_SBo.tgz

Do the same for the rest of the libraries (ftgl, OpenAL, freealut). Be aware that the freealut package depends on the OpenAL package, so you need to do the OpenAL one first. Once you have these installed, you can proceed to the build section (<tt>git clone</tt> and <tt>configure</tt> and <tt>make</tt>).

=== Gentoo ===

DarkRadiant can be built and installed from an unofficial ebuild repository (overlay). The easiest way to do this is with [https://packages.gentoo.org/packages/app-portage/layman app-portage/layman], which must be installed with the <tt>git</tt> use flag.

In the 'overlays' section in <tt>/etc/layman/layman.cfg</tt>, add:

https://raw.githubusercontent.com/varingst/varingst-overlay/master/overlay.xml

Then fetch and add the overlay:

# layman -f -a varingst

Now that the overlay is added, you can build and install DarkRadiant with Portage:

# emerge darkradiant

To sync the overlay, either do it manually with layman:

# layman -s varingst

Or look into the [https://wiki.gentoo.org/wiki/Project:Portage/Sync various ways to hook into the portage sync system].

=== Distributions with GCC 4.8 or earlier ===
DarkRadiant's codebase makes heavy use of C++11 features, in particular std::regex which has been supported from GCC 4.9 on. Not all distributions ship with g++ 4.9 by default (for example Ubuntu 14.04 does not), but it's possible to install a more recent compiler suite. Get the GCC 4.9 package and ensure that the makefiles are called with the correct setup, e.g.
CXX="g++-4.9" ./configure --enable-darkmod-plugins && make -j3 && make install

=== Older Distributions / Compiling DarkRadiant 1.8 and older ===
The instructions about how to compile DR 1.8 (based on GTK) in distributions published in 2012 and older have been removed. They should still be in the [http://wiki.thedarkmod.com/index.php?title=DarkRadiant_-_Compiling_in_Linux&oldid=18927 history] of this page, should they ever be needed.

== Obtain the source ==

Make sure you have the git client installed, this is covered in the package installation commands above.
Next, change to the directory where you want the source code to be in and then clone the Git repository with:

git clone git://github.com/codereader/DarkRadiant.git

Once the initial clone is done, the source can be updated to the latest version from inside the working directory with:

git pull

== Configure and Compile ==
DarkRadiant employs the CMake build system under Linux as used in many open-source projects. Make sure you have the CMake toolchain downloaded, this is covered in the package installation commands above.

To build DarkRadiant, run the typical chain of CMake and make commands:

cmake .
make
[sudo] make install

By the above, a release build will be created; if a debug build is required pass the <tt>-DCMAKE_BUILD_TYPE=Debug</tt> option to the cmake command script.

Other points to note about the configure process:

* The DarkMod-specific plugins are built by default, the <tt>-DENABLE_DM_PLUGINS=OFF</tt> argument will disable them.
* The CMake script autodetects required dependencies, and will conditionally enable optional components of DarkRadiant (such as the sound plugin) based on what it finds.
* For quick testing of a DarkRadiant build, it is desirable to install it into a temporary location rather than the default of <tt>/usr/local</tt>; for this, simply pass a prefix option such as <tt>-DCMAKE_INSTALL_PREFIX=/tmp/dr</tt> to cmake, after which DarkRadiant will be installed in <tt>/tmp/dr/bin/darkradiant</tt>.

=== Multiprocessor Systems ===

You can pass the <tt>--jobs=N</tt> parameter to make:
make --jobs=2
to use more than one processor for the compilation. This will eat lots of RAM, so don't do this on machines with little available memory.

=== Building a .deb package ===

To build a Debian/Ubuntu package, simply run

dpkg-buildpackage -rfakeroot

in the main <tt>darkradiant</tt> directory. The .deb will be created in the parent directory.

{{coding}}
{{darkradiant|sort=Compilation}}

DarkRadiant - Compiling in Linux

2020-12-16T13:21:13Z

Orbweaver: Update Linux compilation steps to match the new CMake build

== Install Required Packages ==

=== Ubuntu 20.04 ===

Copy and paste the following into a terminal:

sudo apt-get install git g++ gettext automake libtool pkg-config zlib1g-dev libjpeg62-dev libxml2-dev libsigc++-2.0-dev libgtest-dev
sudo apt-get install libwxgtk3.0-gtk3-dev libpng-dev libftgl-dev libglew-dev libalut-dev libvorbis-dev python3-dev pybind11-dev

=== openSUSE Tumbleweed ===

Copy and paste the following into a terminal:

sudo zypper install git libtool automake gcc-c++ gettext-tools zlib-devel libjpeg62-devel libxml2-devel libsigc++2-devel gtest
sudo zypper install wxWidgets-3_0-devel ftgl-devel glew-devel libvorbis-devel freealut-devel python38-devel python3-pybind11-devel

=== Mageia 8 ===

Copy and paste the following into a terminal, run as user who has the required permissions to install the packages:

sudo urpmi git make automake libtool gcc-c++ libzlib-devel libjpeg-devel libwxgtku3.0-devel libsigc++2.0-devel
sudo urpmi libftgl-devel libglew-devel libpython3-devel libopenal-devel libfreealut-devel libvorbis-devel lib64gtest-devel

=== Ubuntu 19 / 18 / 17 ===

Copy and paste the following into a terminal:

sudo apt-get install git g++ gettext automake libtool pkg-config zlib1g-dev libjpeg62-dev libwxgtk3.0-dev libxml2-dev
sudo apt-get install libsigc++-2.0-dev libpng-dev libftgl-dev libglew-dev python3-dev libalut-dev libvorbis-dev pybind11-dev

=== Debian 9 ===

Copy and paste the following into a terminal:

sudo apt-get install git automake libtool pkg-config gettext zlib1g-dev libjpeg62-turbo-dev libwxgtk3.0-dev
sudo apt-get install libxml2-dev libsigc++-2.0-dev libpng-dev libftgl-dev libglew-dev libalut-dev libvorbis-dev python-dev pybind11-dev

=== Fedora 26 / 25 ===
Copy and paste the following into a terminal:

sudo dnf install git automake libtool gcc-c++ zlib-devel libjpeg-turbo-devel wxGTK3-devel libxml2-devel libsigc++20-devel
sudo dnf install libpng12-devel ftgl-devel glew-devel libvorbis-devel freealut-devel python-devel pybind11-devel

Note that the wxGTK package does not yet support Wayland environments, which is the default since Fedora 25 (DarkRadiant will just segfault during startup). You'll need to [https://fedoraproject.org/wiki/Changes/WaylandByDefault deactivate it] for the moment being.

=== Arch Linux ===
The following packages are requred after starting from an Anarchy installation using Gnome as Window Manager.

sudo pacman -S automake libtool wxgtk ftgl glew freealut pybind11

=== CentOS 7 x64 ===

Copy and paste the following into a terminal, run as user who has the required permissions to install the packages:

sudo yum -y install gcc gcc-c++ git automake libtool zlib-devel libjpeg-turbo-devel wxGTK3-devel libxml2-devel
sudo yum -y install libsigc++20-devel ftgl-devel glew-devel boost-devel openal-soft-devel freealut-devel libvorbis-devel python-devel

CentOS 7 ships with an older compiler, so you'll need to install a more recent GCC first (following the directions on [https://stackoverflow.com/questions/36327805/how-to-install-gcc-5-3-with-yum-on-centos-7-2 stackoverflow]):

sudo yum install centos-release-scl
sudo yum install devtoolset-4-gcc*
scl enable devtoolset-4 bash

Note that the <tt>wxGTK3-devel</tt> package doesn't create a <tt>wx-config</tt> symlink in the <tt>/usr/bin</tt> directory, that's why you need to pass an additional <tt>--with-wx-config=/usr/bin/wx-config-3.0</tt> argument to the ./configure script below, like this:

./configure --enable-darkmod-plugins --with-wx-config=/usr/bin/wx-config-3.0

=== Slackware 14.2 ===

Slackware doesn't provide precompiled packages on the one hand (unlike Debian or Arch), but already ships with a lot of libraries on the other. Stuff like git, automake, libtools and development libraries like zlib and boost are already present, but wxWidgets, openAL, ALut and FTGL need to be installed by means of a SlackBuild script. The following has been done in Slackware 14.2, so your mileage may vary.

Download the Source tarballs and the SlackBuild packages from these URLs:

* https://slackbuilds.org/repository/14.2/libraries/wxGTK3/
* https://slackbuilds.org/repository/14.2/libraries/ftgl/
* https://slackbuilds.org/repository/14.2/libraries/OpenAL/
* https://slackbuilds.org/repository/14.2/libraries/freealut/

Download and extract the SlackBuild <tt>.tar.gz</tt> files in your <tt>~/Downloads</tt> folder (or anywhere else where you want to have them). For instance, the wxGTK3 package can be untar'd like this:

tar xzf wxGTK3.tar.gz
cd wxGTK3
chmod +x wxGTK3.SlackBuild

Do this for all of the above libraries, that should give you the directories <tt>ftgl/</tt>, <tt>OpenAL/</tt>, <tt>wxGTK3/</tt> and <tt>freealut/</tt>. Next, download the Source Tarballs (the <tt>.tar.bz2</tt>) files from the links above and place them next to the corresponding SlackBuild script. Then run the scripts for each of them and install the build output in your system in a second step:

./wxGTK3.SlackBuild

This produced (on my end at least) the package <tt>/tmp/wxGTK3-3.0.2-i486-2_SBo.tgz</tt> which can be installed by the <tt>installpkg</tt> command:

installpkg /tmp/wxGTK3-3.0.2-i486-2_SBo.tgz

Do the same for the rest of the libraries (ftgl, OpenAL, freealut). Be aware that the freealut package depends on the OpenAL package, so you need to do the OpenAL one first. Once you have these installed, you can proceed to the build section (<tt>git clone</tt> and <tt>configure</tt> and <tt>make</tt>).

=== Gentoo ===

DarkRadiant can be built and installed from an unofficial ebuild repository (overlay). The easiest way to do this is with [https://packages.gentoo.org/packages/app-portage/layman app-portage/layman], which must be installed with the <tt>git</tt> use flag.

In the 'overlays' section in <tt>/etc/layman/layman.cfg</tt>, add:

https://raw.githubusercontent.com/varingst/varingst-overlay/master/overlay.xml

Then fetch and add the overlay:

# layman -f -a varingst

Now that the overlay is added, you can build and install DarkRadiant with Portage:

# emerge darkradiant

To sync the overlay, either do it manually with layman:

# layman -s varingst

Or look into the [https://wiki.gentoo.org/wiki/Project:Portage/Sync various ways to hook into the portage sync system].

=== Distributions with GCC 4.8 or earlier ===
DarkRadiant's codebase makes heavy use of C++11 features, in particular std::regex which has been supported from GCC 4.9 on. Not all distributions ship with g++ 4.9 by default (for example Ubuntu 14.04 does not), but it's possible to install a more recent compiler suite. Get the GCC 4.9 package and ensure that the makefiles are called with the correct setup, e.g.
CXX="g++-4.9" ./configure --enable-darkmod-plugins && make -j3 && make install

=== Older Distributions / Compiling DarkRadiant 1.8 and older ===
The instructions about how to compile DR 1.8 (based on GTK) in distributions published in 2012 and older have been removed. They should still be in the [http://wiki.thedarkmod.com/index.php?title=DarkRadiant_-_Compiling_in_Linux&oldid=18927 history] of this page, should they ever be needed.

== Obtain the source ==

Make sure you have the git client installed, this is covered in the package installation commands above.
Next, change to the directory where you want the source code to be in and then clone the Git repository with:

git clone git://github.com/codereader/DarkRadiant.git

Once the initial clone is done, the source can be updated to the latest version from inside the working directory with:

git pull

== Configure and Compile ==
DarkRadiant employs the CMake build system under Linux as used in many open-source projects. Make sure you have the CMake toolchain downloaded, this is covered in the package installation commands above.

To build DarkRadiant, run the typical chain of CMake and make commands:

cmake .
make
[sudo] make install

By the above, a release build will be created; if a debug build is required pass the <tt>-DCMAKE_BUILD_TYPE=Debug</tt> option to the cmake command script.

Other points to note about the configure process:

* The DarkMod-specific plugins are built by default, the <tt>-DENABLE_DM_PLUGINS=OFF</tt> argument will disable them.
* The CMake script autodetects required dependencies, and will conditionally enable optional components of DarkRadiant (such as the sound plugin) based on what it finds.
* For quick testing of a DarkRadiant build, it is desirable to install it into a temporary location rather than the default of <tt>/usr/local</tt>; for this, simply pass a prefix option such as <tt>-DCMAKE_INSTALL_PREFIX=/tmp/dr</tt> to cmake, after which DarkRadiant will be installed in <tt>/tmp/dr/bin/darkradiant</tt>.

=== Multiprocessor Systems ===

You can pass the <tt>--jobs=N</tt> parameter to make:
make --jobs=2
to use more than one processor for the compilation. This will eat lots of RAM, so don't do this on machines with little available memory.

=== Building a .deb package ===

To build a Debian/Ubuntu package, simply run

dpkg-buildpackage -rfakeroot

in the main <tt>darkradiant</tt> directory. The .deb will be created in the parent directory.

{{coding}}
{{darkradiant|sort=Compilation}}

DarkRadiant coding standards

2020-08-26T08:31:35Z

Orbweaver: Additional shared ptr typedef option

Although DarkRadiant was forked from GTKRadiant, the style of legacy GTKRadiant code should ''not'' be used as an example for new code. Therefore these '''coding standards''' should be used for new code, in order to maximise readability for developers.

==Indentation==

* Prefer 4-space indentation in new code. However, when editing legacy code which is using a different indentation style, it is acceptable to maintain consistency with the legacy code rather than reformatting. Try to avoid mixing tabs and spaces within the same file as this can break alignment when viewing diffs.
* Function and method bodies should use either the [https://en.wikipedia.org/wiki/Indentation_style#Allman_style Allman] or [https://en.wikipedia.org/wiki/Indentation_style#K&R_styleK&R K&R] brace styles, and where possible the opening brace should be in column 0. This enables developers using Vim to make use of the "[[" shortcut to jump to the beginning of the method.

==Naming conventions==

* All new code should be in a namespace, such as '''ui''' for UI-related code or '''model''' for code dealing with models.
* Class names should begin with a capital letter and capitalise each word: '''RenderablePicoModel''', '''TextMenuItem'''
* Classes represent "things", therefore they should be named after nouns not verbs: '''ModuleLoader''' rather than '''LoadModule'''.
* Each class should be in a file pair with file names matching the class name: '''MyClass''' is contained in '''MyClass.h''' and '''MyClass.cpp'''. Local classes used in a single .cpp file may be defined within that .cpp file. It is also acceptable to define trivial data structures returned by methods in the header file declaring the method, if that data structure is not used elsewhere.
* Method names and local variables should start with a lowercase letter, with subsequent words using camelcase: '''start()''', '''getDataStructure()'''. With wxWidgets, however, the convention is different — methods begin with capital letters just like class names. When writing code that is tightly bound to wxWidgets, it is acceptable to use this same style for methods (but please be consistent).
* Member variables should begin with an underscore: '''_widget'''. Do not use the "m_name" convention in new code, as this is harder to read.

===Typedefs===
Using the typedef keyword can improve readability and save typing by providing a simple name for a more complex data structure, however inappropriate use can also reduce readibility by forcing the reader to look up numerous typedefs which do no more than rename a standard type.

For example:

typedef std::vector<std::string> StringList

is a good typedef, because it is obvious what the type means, it allows easy editing if it were required to change it to a std::list rather than a vector (for example), and it makes it easy to work with derived types ('''StringList::iterator''' rather than '''std::vector<std::string>::iterator''').

On the other hand,

typedef float ShaderScaleParameter

is a bad typedef. It provides no improved readability over simply using the primitive type, and gives the impression to a reader unfamiliar with the code that a more complex data structure is being used.

* Never use typedefs to rename a standard type (unless there is a specific purpose, like providing a standard public typedef as part of a functor interface).

==General code structure==

* Always use Object-Oriented design methods wherever possible. Think in terms of objects which define methods to act on those objects, rather than C-style functions that process data structures passed as arguments. Non-member functions are OK for minor tasks, as long as they are within a namespace rather than at global scope.
* Never use global variables (non-constants at file or global scope). Constants at file scope are acceptable, either as primitive types or composite data structures (e.g. vectors or maps) whose content never needs to change.

===Data types and objects===

* Always use STL or other library objects (e.g. wxWidgets), rather than home-grown reinventions of the same thing. Use '''std::string''' for string variables, and '''std::map''' in favour of '''HashedCache'''. Classes that use these home-grown versions should be modified so as not to use them if at all possible, and eventually they will be removed.
* Note that ''we are no longer using Boost'', since modern C++ provides almost all of the Boost facilities we previously needed (shared pointers, std::function etc), and avoiding Boost greatly simplifies the Windows build. If you are developing on a platform where Boost is easily available, be careful not to accidentally add a new Boost usage which will break Windows compilation.
* Do not use '''const char*''' objects except where necessary to pass to a library function (such as the C-based GTK library), or where a string constant is needed. Functions that accept or return strings should use '''std::string''' instead.

=== Data allocation ===
Use '''std::shared_ptr'''s (or '''std::unqiue_ptr''') wherever you need to allocate objects on the heap, as these objects auto-destruct when the last ptr instance is destroyed. Use '''new''' only if you need tight control of when the object should be removed from the heap, or to instantiate GUI classes that auto-destruct in their callbacks.

A shared ptr should be named like this (Ptr suffix):
typedef std::shared_ptr<MyClass> MyClassPtr;

It is also acceptable to add the shared ptr typedef inside the class itself, e.g.

<nowiki>
class MyClass
{
using Ptr = std::shared_ptr<MyClass>
};</nowiki>

which allows the type to be referenced as '''MyClass::Ptr'''.

===Static variables===

If a static variable is required, encapsulate it within a small method that returns a reference to the static, e.g.
MyObject& staticInstance() {
static MyObject _instance;
return _instance;
}
This ensures that the static instance will be initialised when the method is first called, which avoids problems with the undefinability of static initialisation.

===Access===

* All data members should be private, except in data structures which provide no methods (other than constructors).
* Members which need to be accessed externally should be provided with get/set methods. This is an important part of separating interface from implementation, since a get/set method might actually modify more than one member variable, or even perform a calculation without referencing members at all.

===Comments===

Exactly where and how to place comments is a matter of personal preference. However, at the very least, ''all'' public methods and functions should be commented in their associated header file, with details of their parameters, return value and function, along with any other important information (such as prerequisites for calling the function, who is responsible for destroying returned data etc.).

{{darkradiant-internal|sort=Coding}}

DarkRadiant coding standards

2020-08-26T08:26:49Z

Orbweaver: Add note about not using Boost

Although DarkRadiant was forked from GTKRadiant, the style of legacy GTKRadiant code should ''not'' be used as an example for new code. Therefore these '''coding standards''' should be used for new code, in order to maximise readability for developers.

==Indentation==

* Prefer 4-space indentation in new code. However, when editing legacy code which is using a different indentation style, it is acceptable to maintain consistency with the legacy code rather than reformatting. Try to avoid mixing tabs and spaces within the same file as this can break alignment when viewing diffs.
* Function and method bodies should use either the [https://en.wikipedia.org/wiki/Indentation_style#Allman_style Allman] or [https://en.wikipedia.org/wiki/Indentation_style#K&R_styleK&R K&R] brace styles, and where possible the opening brace should be in column 0. This enables developers using Vim to make use of the "[[" shortcut to jump to the beginning of the method.

==Naming conventions==

* All new code should be in a namespace, such as '''ui''' for UI-related code or '''model''' for code dealing with models.
* Class names should begin with a capital letter and capitalise each word: '''RenderablePicoModel''', '''TextMenuItem'''
* Classes represent "things", therefore they should be named after nouns not verbs: '''ModuleLoader''' rather than '''LoadModule'''.
* Each class should be in a file pair with file names matching the class name: '''MyClass''' is contained in '''MyClass.h''' and '''MyClass.cpp'''. Local classes used in a single .cpp file may be defined within that .cpp file. It is also acceptable to define trivial data structures returned by methods in the header file declaring the method, if that data structure is not used elsewhere.
* Method names and local variables should start with a lowercase letter, with subsequent words using camelcase: '''start()''', '''getDataStructure()'''. With wxWidgets, however, the convention is different — methods begin with capital letters just like class names. When writing code that is tightly bound to wxWidgets, it is acceptable to use this same style for methods (but please be consistent).
* Member variables should begin with an underscore: '''_widget'''. Do not use the "m_name" convention in new code, as this is harder to read.

===Typedefs===
Using the typedef keyword can improve readability and save typing by providing a simple name for a more complex data structure, however inappropriate use can also reduce readibility by forcing the reader to look up numerous typedefs which do no more than rename a standard type.

For example:

typedef std::vector<std::string> StringList

is a good typedef, because it is obvious what the type means, it allows easy editing if it were required to change it to a std::list rather than a vector (for example), and it makes it easy to work with derived types ('''StringList::iterator''' rather than '''std::vector<std::string>::iterator''').

On the other hand,

typedef float ShaderScaleParameter

is a bad typedef. It provides no improved readability over simply using the primitive type, and gives the impression to a reader unfamiliar with the code that a more complex data structure is being used.

* Never use typedefs to rename a standard type (unless there is a specific purpose, like providing a standard public typedef as part of a functor interface).

==General code structure==

* Always use Object-Oriented design methods wherever possible. Think in terms of objects which define methods to act on those objects, rather than C-style functions that process data structures passed as arguments. Non-member functions are OK for minor tasks, as long as they are within a namespace rather than at global scope.
* Never use global variables (non-constants at file or global scope). Constants at file scope are acceptable, either as primitive types or composite data structures (e.g. vectors or maps) whose content never needs to change.

===Data types and objects===

* Always use STL or other library objects (e.g. wxWidgets), rather than home-grown reinventions of the same thing. Use '''std::string''' for string variables, and '''std::map''' in favour of '''HashedCache'''. Classes that use these home-grown versions should be modified so as not to use them if at all possible, and eventually they will be removed.
* Note that ''we are no longer using Boost'', since modern C++ provides almost all of the Boost facilities we previously needed (shared pointers, std::function etc), and avoiding Boost greatly simplifies the Windows build. If you are developing on a platform where Boost is easily available, be careful not to accidentally add a new Boost usage which will break Windows compilation.
* Do not use '''const char*''' objects except where necessary to pass to a library function (such as the C-based GTK library), or where a string constant is needed. Functions that accept or return strings should use '''std::string''' instead.

=== Data allocation ===
Use '''std::shared_ptr'''s (or '''std::unqiue_ptr''') wherever you need to allocate objects on the heap, as these objects auto-destruct when the last ptr instance is destroyed. Use '''new''' only if you need tight control of when the object should be removed from the heap, or to instantiate GUI classes that auto-destruct in their callbacks.

A shared ptr should be named like this (Ptr suffix):
typedef std::shared_ptr<MyClass> MyClassPtr;

===Static variables===

If a static variable is required, encapsulate it within a small method that returns a reference to the static, e.g.
MyObject& staticInstance() {
static MyObject _instance;
return _instance;
}
This ensures that the static instance will be initialised when the method is first called, which avoids problems with the undefinability of static initialisation.

===Access===

* All data members should be private, except in data structures which provide no methods (other than constructors).
* Members which need to be accessed externally should be provided with get/set methods. This is an important part of separating interface from implementation, since a get/set method might actually modify more than one member variable, or even perform a calculation without referencing members at all.

===Comments===

Exactly where and how to place comments is a matter of personal preference. However, at the very least, ''all'' public methods and functions should be commented in their associated header file, with details of their parameters, return value and function, along with any other important information (such as prerequisites for calling the function, who is responsible for destroying returned data etc.).

{{darkradiant-internal|sort=Coding}}

DarkRadiant coding standards

2020-08-26T08:22:54Z

Orbweaver: Update certain guidelines, add section on indentation

Although DarkRadiant was forked from GTKRadiant, the style of legacy GTKRadiant code should ''not'' be used as an example for new code. Therefore these '''coding standards''' should be used for new code, in order to maximise readability for developers.

==Indentation==

* Prefer 4-space indentation in new code. However, when editing legacy code which is using a different indentation style, it is acceptable to maintain consistency with the legacy code rather than reformatting. Try to avoid mixing tabs and spaces within the same file as this can break alignment when viewing diffs.
* Function and method bodies should use either the [https://en.wikipedia.org/wiki/Indentation_style#Allman_style Allman] or [https://en.wikipedia.org/wiki/Indentation_style#K&R_styleK&R K&R] brace styles, and where possible the opening brace should be in column 0. This enables developers using Vim to make use of the "[[" shortcut to jump to the beginning of the method.

==Naming conventions==

* All new code should be in a namespace, such as '''ui''' for UI-related code or '''model''' for code dealing with models.
* Class names should begin with a capital letter and capitalise each word: '''RenderablePicoModel''', '''TextMenuItem'''
* Classes represent "things", therefore they should be named after nouns not verbs: '''ModuleLoader''' rather than '''LoadModule'''.
* Each class should be in a file pair with file names matching the class name: '''MyClass''' is contained in '''MyClass.h''' and '''MyClass.cpp'''. Local classes used in a single .cpp file may be defined within that .cpp file. It is also acceptable to define trivial data structures returned by methods in the header file declaring the method, if that data structure is not used elsewhere.
* Method names and local variables should start with a lowercase letter, with subsequent words using camelcase: '''start()''', '''getDataStructure()'''. With wxWidgets, however, the convention is different — methods begin with capital letters just like class names. When writing code that is tightly bound to wxWidgets, it is acceptable to use this same style for methods (but please be consistent).
* Member variables should begin with an underscore: '''_widget'''. Do not use the "m_name" convention in new code, as this is harder to read.

===Typedefs===
Using the typedef keyword can improve readability and save typing by providing a simple name for a more complex data structure, however inappropriate use can also reduce readibility by forcing the reader to look up numerous typedefs which do no more than rename a standard type.

For example:

typedef std::vector<std::string> StringList

is a good typedef, because it is obvious what the type means, it allows easy editing if it were required to change it to a std::list rather than a vector (for example), and it makes it easy to work with derived types ('''StringList::iterator''' rather than '''std::vector<std::string>::iterator''').

On the other hand,

typedef float ShaderScaleParameter

is a bad typedef. It provides no improved readability over simply using the primitive type, and gives the impression to a reader unfamiliar with the code that a more complex data structure is being used.

* Never use typedefs to rename a standard type (unless there is a specific purpose, like providing a standard public typedef as part of a functor interface).

==General code structure==

* Always use Object-Oriented design methods wherever possible. Think in terms of objects which define methods to act on those objects, rather than C-style functions that process data structures passed as arguments. Non-member functions are OK for minor tasks, as long as they are within a namespace rather than at global scope.
* Never use global variables (non-constants at file or global scope). Constants at file scope are acceptable, either as primitive types or composite data structures (e.g. vectors or maps) whose content never needs to change.

===Data types and objects===

* Always use STL or Boost objects, rather than home-grown reinventions of the same thing. Use '''std::string''' for string variables, and '''std::map''' in favour of '''HashedCache'''. Classes that use these home-grown versions should be modified so as not to use them if at all possible, and eventually they will be removed.
* Do not use '''const char*''' objects except where necessary to pass to a library function (such as the C-based GTK library), or where a string constant is needed. Functions that accept or return strings should use '''std::string''' instead.

=== Data allocation ===
Use '''std::shared_ptr'''s (or '''std::unqiue_ptr''') wherever you need to allocate objects on the heap, as these objects auto-destruct when the last ptr instance is destroyed. Use '''new''' only if you need tight control of when the object should be removed from the heap, or to instantiate GUI classes that auto-destruct in their callbacks.

A shared ptr should be named like this (Ptr suffix):
typedef std::shared_ptr<MyClass> MyClassPtr;

===Static variables===

If a static variable is required, encapsulate it within a small method that returns a reference to the static, e.g.
MyObject& staticInstance() {
static MyObject _instance;
return _instance;
}
This ensures that the static instance will be initialised when the method is first called, which avoids problems with the undefinability of static initialisation.

===Access===

* All data members should be private, except in data structures which provide no methods (other than constructors).
* Members which need to be accessed externally should be provided with get/set methods. This is an important part of separating interface from implementation, since a get/set method might actually modify more than one member variable, or even perform a calculation without referencing members at all.

===Comments===

Exactly where and how to place comments is a matter of personal preference. However, at the very least, ''all'' public methods and functions should be commented in their associated header file, with details of their parameters, return value and function, along with any other important information (such as prerequisites for calling the function, who is responsible for destroying returned data etc.).

{{darkradiant-internal|sort=Coding}}

DarkRadiant - Compiling in Linux

2012-07-11T15:52:45Z

Orbweaver: Added update information

== Install Libraries and Tools ==

=== Ubuntu 11.10 ===
Copy and paste the following into a terminal (at least that's what worked in the beta2):

<code>sudo apt-get install automake libtool g++ zlib1g-dev libjpeg62-dev libxml2-dev libgtkmm-2.4-dev libglew1.6-dev libalut-dev libvorbis-dev libboost-dev libboost-regex-dev libboost-filesystem-dev libboost-python-dev libgtksourceviewmm-2.0-dev libgtkglextmm-x11-1.2-dev</code>

The python and the gtksourceviewmm headers are needed for the optional scripting plugin. The alut and vorbis headers are used by the optional sound module.

=== Ubuntu 10.10 ===
Copy and paste the following into a terminal:

<code>sudo apt-get install automake libtool g++ libgtkmm-2.4-dev libjpeg62-dev libgtkglextmm-x11-1.2-dev libxml2-dev libglew1.5-dev libboost-dev libboost-regex-dev libboost-filesystem-dev libboost-python-dev libalut-dev libvorbis-dev libgtksourceviewmm-2.0-dev</code>

The python and the gtksourceviewmm headers are needed for the optional scripting plugin. The alut and vorbis headers are used by the optional sound module.

=== Ubuntu 9.10 ===
Copy and paste the following into a terminal:

<code>sudo apt-get install g++ libboost1.38-dev libgtk2.0-dev libglew1.5-dev libgtkglext1-dev libxml2-dev libalut-dev libvorbis-dev libboost-python-dev python-dev libgtksourceview2.0-dev</code>

The python headers are needed for the optional scripting plugin.

Adjust the configure.ac file, as Ubuntu 9.10 appends the postfix -mt for each boost library installed in /usr/lib:
boost_regex => boost_regex-mt
boost_filesystem => boost_filesystem-mt
boost_system => boost_system-mt
boost_python => boost_python-mt

# Boost.Regex
AC_CHECK_LIB([boost_regex-mt], [main],
[REGEX_LIBS='-lboost_regex-mt'],
[AC_MSG_ERROR([Boost.Regex not found])])
AC_SUBST([REGEX_LIBS])

# Boost.Filesystem
AC_CHECK_LIB([boost_filesystem-mt], [main],
[BOOST_FILESYSTEM_LIBS='-lboost_filesystem-mt'],
[AC_MSG_ERROR([Boost.Filesystem not found])])
AC_SUBST([BOOST_FILESYSTEM_LIBS])

# Boost.System
AC_CHECK_LIB([boost_system-mt], [main],
[BOOST_SYSTEM_LIBS='-lboost_system-mt'],
[AC_MSG_ERROR([Boost.System not found])])
AC_SUBST([BOOST_SYSTEM_LIBS])

Same for the Python check below in configure.ac:
AC_CHECK_LIB([boost_python-mt], [main],
[BOOST_PYTHON_LIBS='-lboost_python-mt'],
[script_module=''])
Then re-run ./autogen.sh and ./configure

=== Ubuntu 8.04 ===
Copy and paste the following into a terminal:

<code>sudo apt-get install g++ libboost-dev libboost-regex-dev libgtk2.0-dev libglew1.5-dev libgtkglext1-dev libxml2-dev libboost-serialization-dev libboost-filesystem-dev libboost-date-time-dev libalut-dev libvorbis-dev libboost-python-dev python-dev</code>

The python headers are needed for the optional scripting plugin.

In the terminal, Ctrl Shift V is used for pasting instead of Ctrl V.

=== Fedora 15 ===
Open a console and type:
sudo yum install gcc gcc-c++ automake zlib-devel libjpeg-turbo-devel libxml2-devel glew-devel boost-devel
sudo yum install gtk2-devel gtkmm24-devel gtkglextmm-devel gtksourceviewmm-devel libvorbis-devel freealut-devel python-devel

== Obtain the source ==

Install the '''git''' client. On Ubuntu this can be done via the Synaptic Manager or the command line:
sudo apt-get install git
Fedora users can use this yum command line:
sudo yum install git
Change to the directory where you want the source code to be in and then clone the Git repository with:

git clone git://github.com/orbweaver/DarkRadiant.git

Once the initial clone is done, the source can be updated to the latest version from inside the working directory with:

git pull

== Compile ==

'''Note: in the past, DarkRadiant was built using SCons. This build system has now been removed in favour of the standard Automake build.'''

First, make sure you have the automake toolchain downloaded.

Debian/Ubuntu/Aptitude users:
sudo apt-get install libtool autoconf
Fedora 15 users:
sudo yum install libtool gettext-devel
Then run
./autogen.sh
in your darkradiant folder.

DarkRadiant employs an Autoconf/Automake build system under Linux as used in the majority of open-source projects. Compilation can be achieved using the standard

$ ./configure
$ make
$ make install

on most systems.

By default, a release build will be created; if a debug build is required pass the '''--enable-debug''' option to the configure script.

Other points to note about the configure process:

* The DarkMod-specific plugins are not built by default. To enable these, pass '''--enable-darkmod-plugins''' to ./configure.
* The configure script autodetects required dependencies, and will conditionally-enable optional components of DarkRadiant (such as the sound plugin) based on what it finds.
* For quick testing of a DarkRadiant build, it is desirable to install it into a temporary location rather than the default of '''/usr/local'''; for this, simply pass a prefix option such as '''--prefix=/tmp/dr''' to configure, after which DarkRadiant will be installed in '''/tmp/dr/bin/darkradiant'''.

=== Multiprocessor Systems ===
You can pass the --jobs=N parameter to make:
make --jobs=2
to use more than one processor for the compilation.

=== Building a .deb package ===

To build a Debian/Ubuntu package, simply run

dpkg-buildpackage -rfakeroot

in the main '''darkradiant''' directory. The .deb will be created in the parent directory.

== See also ==
* [[DarkRadiant Linux Issues]]

{{coding}}
{{darkradiant|sort=Compilation}}

DarkRadiant - Compiling in Linux

2012-07-11T15:51:42Z

Orbweaver: Removed obsolete SVN commands

== Install Libraries and Tools ==

=== Ubuntu 11.10 ===
Copy and paste the following into a terminal (at least that's what worked in the beta2):

<code>sudo apt-get install automake libtool g++ zlib1g-dev libjpeg62-dev libxml2-dev libgtkmm-2.4-dev libglew1.6-dev libalut-dev libvorbis-dev libboost-dev libboost-regex-dev libboost-filesystem-dev libboost-python-dev libgtksourceviewmm-2.0-dev libgtkglextmm-x11-1.2-dev</code>

The python and the gtksourceviewmm headers are needed for the optional scripting plugin. The alut and vorbis headers are used by the optional sound module.

=== Ubuntu 10.10 ===
Copy and paste the following into a terminal:

<code>sudo apt-get install automake libtool g++ libgtkmm-2.4-dev libjpeg62-dev libgtkglextmm-x11-1.2-dev libxml2-dev libglew1.5-dev libboost-dev libboost-regex-dev libboost-filesystem-dev libboost-python-dev libalut-dev libvorbis-dev libgtksourceviewmm-2.0-dev</code>

The python and the gtksourceviewmm headers are needed for the optional scripting plugin. The alut and vorbis headers are used by the optional sound module.

=== Ubuntu 9.10 ===
Copy and paste the following into a terminal:

<code>sudo apt-get install g++ libboost1.38-dev libgtk2.0-dev libglew1.5-dev libgtkglext1-dev libxml2-dev libalut-dev libvorbis-dev libboost-python-dev python-dev libgtksourceview2.0-dev</code>

The python headers are needed for the optional scripting plugin.

Adjust the configure.ac file, as Ubuntu 9.10 appends the postfix -mt for each boost library installed in /usr/lib:
boost_regex => boost_regex-mt
boost_filesystem => boost_filesystem-mt
boost_system => boost_system-mt
boost_python => boost_python-mt

# Boost.Regex
AC_CHECK_LIB([boost_regex-mt], [main],
[REGEX_LIBS='-lboost_regex-mt'],
[AC_MSG_ERROR([Boost.Regex not found])])
AC_SUBST([REGEX_LIBS])

# Boost.Filesystem
AC_CHECK_LIB([boost_filesystem-mt], [main],
[BOOST_FILESYSTEM_LIBS='-lboost_filesystem-mt'],
[AC_MSG_ERROR([Boost.Filesystem not found])])
AC_SUBST([BOOST_FILESYSTEM_LIBS])

# Boost.System
AC_CHECK_LIB([boost_system-mt], [main],
[BOOST_SYSTEM_LIBS='-lboost_system-mt'],
[AC_MSG_ERROR([Boost.System not found])])
AC_SUBST([BOOST_SYSTEM_LIBS])

Same for the Python check below in configure.ac:
AC_CHECK_LIB([boost_python-mt], [main],
[BOOST_PYTHON_LIBS='-lboost_python-mt'],
[script_module=''])
Then re-run ./autogen.sh and ./configure

=== Ubuntu 8.04 ===
Copy and paste the following into a terminal:

<code>sudo apt-get install g++ libboost-dev libboost-regex-dev libgtk2.0-dev libglew1.5-dev libgtkglext1-dev libxml2-dev libboost-serialization-dev libboost-filesystem-dev libboost-date-time-dev libalut-dev libvorbis-dev libboost-python-dev python-dev</code>

The python headers are needed for the optional scripting plugin.

In the terminal, Ctrl Shift V is used for pasting instead of Ctrl V.

=== Fedora 15 ===
Open a console and type:
sudo yum install gcc gcc-c++ automake zlib-devel libjpeg-turbo-devel libxml2-devel glew-devel boost-devel
sudo yum install gtk2-devel gtkmm24-devel gtkglextmm-devel gtksourceviewmm-devel libvorbis-devel freealut-devel python-devel

== Obtain the source ==

Install the '''git''' client. On Ubuntu this can be done via the Synaptic Manager or the command line:
sudo apt-get install git
Fedora users can use this yum command line:
sudo yum install git
Change to the directory where you want the source code to be in and then check the current version out of Git with:

git clone git://github.com/orbweaver/DarkRadiant.git

== Compile ==

'''Note: in the past, DarkRadiant was built using SCons. This build system has now been removed in favour of the standard Automake build.'''

First, make sure you have the automake toolchain downloaded.

Debian/Ubuntu/Aptitude users:
sudo apt-get install libtool autoconf
Fedora 15 users:
sudo yum install libtool gettext-devel
Then run
./autogen.sh
in your darkradiant folder.

DarkRadiant employs an Autoconf/Automake build system under Linux as used in the majority of open-source projects. Compilation can be achieved using the standard

$ ./configure
$ make
$ make install

on most systems.

By default, a release build will be created; if a debug build is required pass the '''--enable-debug''' option to the configure script.

Other points to note about the configure process:

* The DarkMod-specific plugins are not built by default. To enable these, pass '''--enable-darkmod-plugins''' to ./configure.
* The configure script autodetects required dependencies, and will conditionally-enable optional components of DarkRadiant (such as the sound plugin) based on what it finds.
* For quick testing of a DarkRadiant build, it is desirable to install it into a temporary location rather than the default of '''/usr/local'''; for this, simply pass a prefix option such as '''--prefix=/tmp/dr''' to configure, after which DarkRadiant will be installed in '''/tmp/dr/bin/darkradiant'''.

=== Multiprocessor Systems ===
You can pass the --jobs=N parameter to make:
make --jobs=2
to use more than one processor for the compilation.

=== Building a .deb package ===

To build a Debian/Ubuntu package, simply run

dpkg-buildpackage -rfakeroot

in the main '''darkradiant''' directory. The .deb will be created in the parent directory.

== See also ==
* [[DarkRadiant Linux Issues]]

{{coding}}
{{darkradiant|sort=Compilation}}

DarkRadiant - Compiling in Linux

2012-07-11T15:50:41Z

Orbweaver: Using git now not svn

== Install Libraries and Tools ==

=== Ubuntu 11.10 ===
Copy and paste the following into a terminal (at least that's what worked in the beta2):

<code>sudo apt-get install automake libtool g++ zlib1g-dev libjpeg62-dev libxml2-dev libgtkmm-2.4-dev libglew1.6-dev libalut-dev libvorbis-dev libboost-dev libboost-regex-dev libboost-filesystem-dev libboost-python-dev libgtksourceviewmm-2.0-dev libgtkglextmm-x11-1.2-dev</code>

The python and the gtksourceviewmm headers are needed for the optional scripting plugin. The alut and vorbis headers are used by the optional sound module.

=== Ubuntu 10.10 ===
Copy and paste the following into a terminal:

<code>sudo apt-get install automake libtool g++ libgtkmm-2.4-dev libjpeg62-dev libgtkglextmm-x11-1.2-dev libxml2-dev libglew1.5-dev libboost-dev libboost-regex-dev libboost-filesystem-dev libboost-python-dev libalut-dev libvorbis-dev libgtksourceviewmm-2.0-dev</code>

The python and the gtksourceviewmm headers are needed for the optional scripting plugin. The alut and vorbis headers are used by the optional sound module.

=== Ubuntu 9.10 ===
Copy and paste the following into a terminal:

<code>sudo apt-get install g++ libboost1.38-dev libgtk2.0-dev libglew1.5-dev libgtkglext1-dev libxml2-dev libalut-dev libvorbis-dev libboost-python-dev python-dev libgtksourceview2.0-dev</code>

The python headers are needed for the optional scripting plugin.

Adjust the configure.ac file, as Ubuntu 9.10 appends the postfix -mt for each boost library installed in /usr/lib:
boost_regex => boost_regex-mt
boost_filesystem => boost_filesystem-mt
boost_system => boost_system-mt
boost_python => boost_python-mt

# Boost.Regex
AC_CHECK_LIB([boost_regex-mt], [main],
[REGEX_LIBS='-lboost_regex-mt'],
[AC_MSG_ERROR([Boost.Regex not found])])
AC_SUBST([REGEX_LIBS])

# Boost.Filesystem
AC_CHECK_LIB([boost_filesystem-mt], [main],
[BOOST_FILESYSTEM_LIBS='-lboost_filesystem-mt'],
[AC_MSG_ERROR([Boost.Filesystem not found])])
AC_SUBST([BOOST_FILESYSTEM_LIBS])

# Boost.System
AC_CHECK_LIB([boost_system-mt], [main],
[BOOST_SYSTEM_LIBS='-lboost_system-mt'],
[AC_MSG_ERROR([Boost.System not found])])
AC_SUBST([BOOST_SYSTEM_LIBS])

Same for the Python check below in configure.ac:
AC_CHECK_LIB([boost_python-mt], [main],
[BOOST_PYTHON_LIBS='-lboost_python-mt'],
[script_module=''])
Then re-run ./autogen.sh and ./configure

=== Ubuntu 8.04 ===
Copy and paste the following into a terminal:

<code>sudo apt-get install g++ libboost-dev libboost-regex-dev libgtk2.0-dev libglew1.5-dev libgtkglext1-dev libxml2-dev libboost-serialization-dev libboost-filesystem-dev libboost-date-time-dev libalut-dev libvorbis-dev libboost-python-dev python-dev</code>

The python headers are needed for the optional scripting plugin.

In the terminal, Ctrl Shift V is used for pasting instead of Ctrl V.

=== Fedora 15 ===
Open a console and type:
sudo yum install gcc gcc-c++ automake zlib-devel libjpeg-turbo-devel libxml2-devel glew-devel boost-devel
sudo yum install gtk2-devel gtkmm24-devel gtkglextmm-devel gtksourceviewmm-devel libvorbis-devel freealut-devel python-devel

== Obtain the source ==

Install the '''git''' client. On Ubuntu this can be done via the Synaptic Manager or the command line:
sudo apt-get install git
Fedora users can use this yum command line:
sudo yum install git
Change to the directory where you want the source code to be in and then check the current version out of Git with:

git clone git://github.com/orbweaver/DarkRadiant.git

== Compile ==

'''Note: in the past, DarkRadiant was built using SCons. This build system has now been removed in favour of the standard Automake build.'''

First, make sure you have the automake toolchain downloaded.

Debian/Ubuntu/Aptitude users:
sudo apt-get install libtool autoconf
Fedora 15 users:
sudo yum install libtool gettext-devel
Then run
./autogen.sh
in your darkradiant folder.

DarkRadiant employs an Autoconf/Automake build system under Linux as used in the majority of open-source projects. Compilation can be achieved using the standard

$ ./configure
$ make
$ make install

on most systems.

By default, a release build will be created; if a debug build is required pass the '''--enable-debug''' option to the configure script.

Other points to note about the configure process:

* The DarkMod-specific plugins are not built by default. To enable these, pass '''--enable-darkmod-plugins''' to ./configure.
* The configure script autodetects required dependencies, and will conditionally-enable optional components of DarkRadiant (such as the sound plugin) based on what it finds.
* For quick testing of a DarkRadiant build, it is desirable to install it into a temporary location rather than the default of '''/usr/local'''; for this, simply pass a prefix option such as '''--prefix=/tmp/dr''' to configure, after which DarkRadiant will be installed in '''/tmp/dr/bin/darkradiant'''.

If you want to update the source with the latest version from the SVN, just issue:

svn update
in the darkradiant source directory. <code>svn info</code> shows you what version you currently have.

=== Multiprocessor Systems ===
You can pass the --jobs=N parameter to make:
make --jobs=2
to use more than one processor for the compilation.

=== Building a .deb package ===

To build a Debian/Ubuntu package, simply run

dpkg-buildpackage -rfakeroot

in the main '''darkradiant''' directory. The .deb will be created in the parent directory.

== See also ==
* [[DarkRadiant Linux Issues]]

{{coding}}
{{darkradiant|sort=Compilation}}

Location Settings

2010-12-05T19:30:48Z

Orbweaver: Another note about overriding ambient volumes

== Introduction ==

This article describes how to setup '''locations''' (also called "location zones" or "zones") in your level, and then use these to:

* fade to different ambient '''light levels''' for each zone
* fade between different ambient '''sounds''' in each zone
* run '''scripts''' automatically when the player enters or exits a zone

----

You need to use four types of entities in your map:

* a special global entity (e.g. add only one, the position does not matter): '''atdm:location_settings'''
* a special global light entity named '''ambient_world'''
* multiple '''info_location''' and '''info_locationseparation''' entities

<small>
:Note: Two alternative ways to get ambient sounds in your map are using speakers ([[Adding ambient Sounds to your Map]]), and using triggers ([[Ambient Sounds - Zone (using triggers)]]). Speakers are good if you only want your ambient to cover a definite radius and have a very simple setup. Triggers are basically obsoleted by the method in this tutorial. The only time you might still want to use a trigger-system is if you want a ambient sound to begin at a place where for some reason you can't create a portal to mark the zone boundary, but you can still have a trigger brush. There are some issues with a trigger system, too (f.i. their CPU and memory usage), that make the method in this tutorial superior.
</small>

== The atdm:location_settings entity ==

Create a '''atdm:location_settings''' entity in your blueroom (i.e., a room off to the side the player will never enter) or somewhere else in your map:

'''{{RMB}} -> Create entity -> Darkmod -> Info -> atdm:location_settings'''

=== Default values ===

The location_settings entity takes a few ''default'' spawnargs related to the ambient light settings:

* [[Location Settings#"ambient_light_fade_time"]]
* [[Location Settings#"ambient_light_fade_delay"]]

For their meaning and values, please refer to their sections.

=== update_period ===

The spawnarg '''update_period''' specifies the time in seconds between updates. A good value is 0.2, e.g. 5 times per second. That avoids to run the script too often, and still allows seamless transitions.

=== Sound Shaders ===

In the entity's spawnargs, put the names of all the ambient sounds you want to play in your map. (This pre-loads the sounds into the speaker so there isn't a pause when they start playing.) Put it in one of these property/value forms (without the quote marks):

'''"snd_streets" "city_night01_loop_z"'''

'''"snd_mansion" "sound/ambient/ambience/mansion_tense01a.ogg"'''

The left hand spawnarg should have a "snd_" prefix, and any name, but most useful is probably the name of the area it is for. You'll use this name again when you place the location markers.

The right hand value points to the actual sound file that will play. You can enter either the soundshader name, or the address where the sound file is (but see footnote). You can see the soundshader names of ambient-ready sounds in the sub-folder "Darkmod/sound/tdm_ambient_ambience_zoned.sndshd". You can find the address of the sound files in "Darkmod/sound/ambient/ambience" (remember to start the address with "sound" in the spawnarg). You can also listen to the sounds at that location. They are are in .ogg format.

Edit:Baddcog-Running through this first time, leaving notes to be fixed/editted later.
Hint on sounds, you can also create a speaker (left-click>speaker) and it will give you a sound directory where you can play sound files and find the names. No searching through sound folders outside of DR.

:Note that it is very easy to add custom ambients with this system. Just create a folder in your .pk4 (a .zip file renamed to .pk4) and name the folder "sound", with another folder inside it named after your FM or an abbreviation. Put your custom sound inside that second folder. (E.g., I have a custom ambient named Frozen.ogg, and my FM's name is Patently Dangerous. So in my .pk4 was "sound/patent/frozen.ogg". Note that ambients must be in either .ogg or .wav format. Now in your speaker_zone_ambient, just put the sound's address in the spawnarg (but see footnote). In my case, I have "snd_warehouse" "sound/patent/frozen.ogg".

It is worth noting that one special "sound" is already loaded by default.

'''"snd_silence" "silence"'''

You can see it if you check "Show Inherited Properties". This is the sound you use to turn "off" the ambient sounds playing, so there is silence in the zone.

=== On Shader Names ===

One footnote on the sound shader names. The ''shader tdm_ambient_ambience_zoned.sndshd'' has a special command ("leadin") for its sounds that begins the ambient with a short pause. This is to pre-empt a possible *pop* of sound for loud ambients which can occur when the player's system slows down (and only occasionally, at that), so the player never hears the pop. (It's a quirk of how Doom3 does fade-ins; when you start a new sound, you have to rapidly fade it out first, like .001 seconds, then slowly fade back in. But if the system slows and the ambient starts loud, it might stretch that .001 to something audible.)
Edit:Baddcog- These seem to now have been appended with a _z if you look at sound names in speaker dialog.

If you alternatively use the address or the shader name from "Darkmod/sound/tdm_ambient_ambience.sndshd" (which lack the "leadin" property) it will otherwise work fine, but you won't be protected from that occasional little pop (at least until we find another fix). For ambients that start quietly or areas that won't slow the system down, it will probably never even be a problem and the player will never hear it, so using the address is fine, or using the tdm_ambient_ambience shader name if you don't want the tiny pause for whatever reason. But if you want to control it, use the tdm_ambient_ambience_zoned name, and for a custom sound, to pre-empt the pop you'll need to use a custom shader with the "leadin" line. Use the "Darkmod/sound/tdm_ambient_ambience_zoned.sndshd" as a template to do that, and name the custom shader file something like YourFMsName.sndshd, and put it in the "sound" folder in your .pk4.

=== Sound Properties ===

Regarding properties, the speaker (the '''atdm:location_settings''' entity is a speaker in disguise :) has by default the properties "omni", "global", and "looping" already turned on, so that all sounds played are heard everywhere, from no direction, and will loop. If you change these properties (e.g., for one ambient) the change will apply to all ambients on the speaker. So you probably don't want to turn these properties off.

"volume" is another potential property; but it has been left off as a default. You can change the volume of sounds played on the speaker with the property, but again it will apply to all the ambients on the speaker. It is better to defined individual "volume" spawnargs on each '''info_location''' entity, and there put the value between "-60" ("silence") and "0" (full volume) in decibels (so around "-10" is about half volume). See the section below on "volume" for more detail and some warnings about positive volume values.

Your entity will look like this:

[[Image:Speaker4.jpg]]

You are finished with the ambient sound part now.

== The Ambient Light ==

You need to create an ambient light in your level. This will cover the entire level, and provide a minimum default light for when there is no other light covering a surface:

# '''{{RMB}} -> Create light'''
# Move the light's origin to the center of your map, and drag it's size so that it covers your entire map, and then some more. Remember to increase the size of that light when you build more area into your map!
# Open the light inspector (default shortcut {{key|L}}) and set the light texture to '''lights/ambientlightnfo'''
# Set the color of the light to a reasonable default, f.i. "8 8 8" This value will be used when a zone has no other ambient light settings
# Open the entity inspector (default shortcut {{key|N}}) and set the name of the light to '''ambient_world'''

The last step is important!

You are done now with the global ambient light.

== The Location Entities ==

Now you need to set up the location system so the game knows where the zones are, and their boundaries where changes will happen. A location is basically any area that's closed in by brushes and marked portals and contains an info_location entity. Unlike a vis-portaled area (which is one area between [[vis_portals]], a.k.a. a "leaf"), a zone can cover more than one portaled area ("leaves").

As an aside, locations are also used for setting the EAX properties in the area (e.g., the echo-y-ness of a big hall or cave, or the dullness of a small carpeted room). So you have a good reason to have them even in addition to handling ambient sounds and lights.

=== info_locationseparator ===

As I suggested above, you have to mark all the portals leading in and out of a zone by hand. You do this with an entity called a '''info_locationseparator'''. Create one so it touches the portal you want as a boundary.

'''{{RMB}} -> Create entity -> Darkmod -> Info -> info_locationseparator'''

If you don't touch a portal with this entity, than it will not register in the game as the boundary to a new zone, and the zone will continue into the area on the other side of the portal. This happens even if you have a second info_location (described below) on the other side (the game will just pick one and use that for the whole zone). This can be a good thing because, say you have a mansion with 30 portals inside. You can cover the whole area inside it by just marking the 2 or 3 portals leading into the mansion area through the doors and open windows, and everything inside that marked area will be counted as one location (just don't miss marking an exit, or have an un-portaled gap to the outside between brushes, or the location will leak outside. It has to be hermetically sealed).

I have read discussion that a door touching a portal marks it as a location boundary, but in my experiments the door did not create a new location and I still had to use a info_locationseparator over the portal to register it as a boundary.

=== info_location ===

Now, inside the zone you want to have, create an '''info_location''' entity:

'''{{RMB}} -> Create entity -> Darkmod -> Info -> info_location'''

Anywhere in the space of the zone is fine. Name it the name of the zone you want (to make it easy to find when you push {{key|J}}).

== Settings per location/zone ==

On each info_location, you can set multiple spawnargs that adjust the light or sound for that location, as well
as run scripts. We cover them next:

=== Ambient sound ===

Now create a spawnarg property of "ambient" with the value being the speaker-name of the sound you used in the location_settings entity above (NOT the soundshader name or file name). For example,

'''"ambient" "snd_streets"'''

This will send a command to the location_settings (in its speaker capacity) to play the ambient it has registered under "snd_streets" that you entered. When you enter a new zone, in turn, the new info_location sends a command to the speaker to turn off that ambient and start a new one.

If you wanted to have no ambient playing in the zone (and turn off any ambient started from another zone), you would use "snd_silence" as the value to command the speaker to turn off. Also, if you have an info_location with no "ambient" value at all, it will also turn off the ambient (in the present version of this system). That means if you make a new location but want the same ambient playing in it as the location next to it, you still need to add the ambient name for the already-playing ambient for it to continue playing into the new zone; otherwise it will turn off.

==== Examples ====

Here are two info_locations on two sides of a portal, with an info_locationseparator touching the portal (more like piercing it), and with each info_location containing the name of the ambient that will play in its respective zone.

[[Image:Snd_streets.jpg]]

[[Image:Snd_silence.jpg‎]]

That's basically it. The ambients will now turn on when you enter a zone and turn off when you enter a new zone, turning on the new ambient in that new zone. If you open up the console, you should see a message saying that a new ambient is now playing in your current location, naming the ambient and location.

=== Sound Fading ===

Finally, there are a few other spawnargs on the info_locations that you usually don't have to worry about (with the possible exception of "volume"), but you can use them if you like, so I will mention them. They concern the properties of the ambient fading. Check the "Show Inhereted Properties" to see their default values. Entering a new value will over-write the default value, but only for that one object.

[[Image:Info_loc.jpg‎]]

==== fiduration ====

"Fade in duration". This is the length of time in seconds it takes for the in-coming ambient (the one for this zone) to completely fade-in. The default value is 4 seconds. You can, e.g., make the fade last much longer with a larger value.

If you don't want your ambient to fade in at all, but start immediately at full volume, change this value to ".001" (NOT zero).

==== foduration ====

"Fade out duration". This is the length of time in seconds it takes for the out-going ambient (the one from the zone you're leaving) to completely fade-out. Again, if you want it to cut right off without fading, use a value of ".001".

==== fidelay ====

"Fade in Delay". You can delay the beginning of the in-coming ambient's fade-in after you enter the new area. You might want to do this, for example, if you want the out-going ambient to completely fade out before you begin fading in the new ambient. So you would set fidelay to the same time as the foduration. By default it is set to .001 so that there is no delay and the fade in starts immediately. If the out-going fade-out also starts immediately (which happens by default), then they blend together in a nice transition fade.

==== fodelay ====

"Fade out Delay". Similarly you can delay the beginning of the out-going ambient's fade out. You might want to do this if you wanted the in-coming ambient to completely fade in before you started the fade out of the old ambient. Then you would set it to fiduration. Like fidelay, it is set to .001 so there is no delay and the fade out starts immediately.

==== fovolume ====

"Fade out volume". This sets the volume to which the out-going ambient fades to. -60 turns it off, which is the default (0 means no decrease in volume at all). If you go any higher than -60, than it will leave the old ambient still playing at a lower volume under the new ambient (at least until you enter a 3rd new zone). Not sure why you'd ever want to do that, so you probably don't want to change it.

==== volume ====

This allows the mapper to override the volume of the ambient sound once it has fully faded in, and uses the same scale as the '''s_volume''' speaker parameter. See [[Setting Up Speakers#volume/ s_volume]] & [[Volume Issues]] for more detailed discussion of the volume parameter.

'''Do not override ambient volumes unless strictly necessary'''. Maps with wildly different ambient volume settings result in a poor experience for players, and limit the ability of the Dark Mod team to respond to volume-related issues by changing default volumes in sound shader declarations.

These last two ('''foduration_2foip''' and '''fiduration_2foip''') are pretty obscure situations, so you probably don't need to ever mess with them unless you want to completely get rid of ambient fades (then you can set them to .001 like the other 'fade duration' properties).

==== foduration_2foip ====

"Fade-out duration during a '2 Fade-outs in progress' situation". This provides a shorter fade-out duration (in seconds) for when the player quickly runs into a 3rd location, such that the 1st and 2nd ambients from areas the player just left are still fading out (hence the 2 fade-outs). But the quickend-fade-out only applies to the 1st ambient fading out. (i.e., not of the ambient you just left, but the one you left just before that -- unless you're backtracking, then it just fades the prev-prev ambient back in). Fading out that prev-prev ambient more quickly in turn quickens the time the new fade-in can start (because you can't have 3 sounds on at the same time on the zone speaker, only 2). So it in effect reduces the gap of quiet that happens before the newest ambient fully fades-in by enabling it to start its fade-in faster. The default is 1 second.

==== fiduration_2foip ====

"Fade-in duration during a '2 Fade-outs in progress' situation". Like its counterpart, this sets a shorter duration of a fade-in of a new ambient (in seconds) when you run into a 3rd location, while the ambients from the 1st and 2nd locations are fading out. Again, because so many ambients are fading out, it can leave a gap of silence for a bit until the new 3rd ambient fades in. So setting a shorter duration than usual for the newest ambient to fully fade in helps shorten the quiet space. The default is 2 seconds (as opposed to a normal default fade-in duration of 4 seconds).

==== Example of Location with No Fading Transition ====

As mentioned above, if you wanted a set-up that turned off all fades so that the out-going ambient shut directly off and the in-coming ambient turns directly on, you'd change all the duration properties to .001, like the following image. (Note that this modifies the transition only for entering this one location. All the other info_locations maintain their default values unless you also change them by hand.)

[[image: Fade_duration.jpg‎]]

=== Ambient light settings ===

These spawnargs can be set on '''atdm:info_location''' entities and apply to the current zone then:

==== "ambient_light" ====

This spawnarg specifies the ambient light color for this zone. Setting it f.i. to "0.10 0.02 0.02" would fade the ambient light to a slightly reddish color. This can be useful for covering a lava cave. Other examples are slightly blue light for moonlit outsides, greenish cast for caves or underwater areas etc.

If you do not set this on an info_location entity, the default value of the global "ambient_world" entity will be used.

'''Notes:'''

:*You need to set the color values as fractions between 0 and 1, e.g. '''"0.08 0.08 0.02"''' and '''NOT''' as integers like so <s>"8 8 2"</s>, or it will not work.

:*If the color change between two zones is too big, the fading and change can become obvious to the player and spoil the subtlety. This can happen for instance if you zoom from a bluish-lit outside directly to a reddish-glowing cave inside. To help the transition, consider adding an intermidiate zone with a light color that is either in between the two, or a more neutral grey. Making it not possible to look from one zone to the other also helps, this way they player can't see that f.i. the outside ground suddenly also glows reddish when looking back from the cave entrance to the outside.

==== "ambient_light_fade_time" ====

This specifies the time in seconds it will take to fade from the current ambient light color to the one specified for this location. A slower fade means more gradual light changes, so they don't become too obvious to the player. Use at least 3, better 5 or 7 seconds.

If set to -1, the default time specified at the '''atdm:location_settings''' entity will be used.

==== "ambient_light_fade_delay" ====

This specifies the time in seconds the fading will be delayed when the player changes location.

Useful to prevent fades toggling back and forth when the player stands in a doorway and goes a nudge forward/backwards. A good value is at least 1 second.

If set to -1, the default time specified at the '''atdm:location_settings''' entity will be used.

==== "ambient_light_dynamic" ====

'''This is a factor''', all lights in the current area will be summed together and scaled by this value.

If set to a value other than "0 0 0", the lights in the current zone will be all summed together and then
added to the current base ambient light. This happens with the frequency of '''update_period'''.

The basic effect is that a roaring fire also slightly makes the walls flicker, and extinguishing all lights in a room would decrease the ambient light slightly.

The factor should be set up so that for large and dark rooms (e.g. caves) the dynamic part is small, while for small, bright rooms (white walls) the dynamic part is bigger. Examples are: "0.05 0.05 0.05" and "0.1 0.1 0.1".

Note that setting the dynamic factor to high can result in the player being busted by lights that are turned on in the room even when the player is in the shadow.

See also the article about [[Dynamic ambient light]].

==== "ambient_light_dynamic_cap" ====

Used to cap the dynamic ambient light part. If set to 0, will be ignored, so to have a very very small
cap, set to "0.01", e.g. if you want only the red part to be dynamic, set it f.i. "0.15 0.01 0.01".

See also the article about [[Dynamic ambient light]].

==== "ambient_light_dynamic_falloff" ====

Possible values are:

* -1 on info_location: use the value from the atdm:location_settings entity
* 0 - no dynamic falloff
* 0.5 - small, based on square root of distance
* 1 - medium, linear dynamic falloff (should be used as it looks best)
* 2 - high, square of distance based falloff

See also the article about [[Dynamic ambient light]].

==== "ambient_light_dist_scale" ====

A factor to scale the distance before applying a dynamic light falloff. Only used then '''ambient_light_dynamic_falloff''' is not 0. Good valuesa are around 1.0.

See also the article about [[Dynamic ambient light]].

=== Script calls ===

The next four spawnargs all specify scripts to call when the player enters or exits a zone. Note that the very first zone is also "entered" by the player when the map starts. That means "call_once_on_entry" for the start zone should be called at start-time.

==== "call_once_on_exit" ====

Called only once when the zone is left by the player.

==== "call_once_on_entry" ====

Called only once when the zone is entered by the player.

==== "call_on_exit" ====

Always called when the player leaves that zone.

==== "call_on_entry" ====

Always called when the player enters that zone.

==== Example scripts ====

Here is an example script that spawns an object where the '''info_location''' entity is for the zone the player just left. You can call this script by setting:

'''"call_once_on_exit" "spawn_pear"'''

on your info_location entity.

<pre>
void spawn_pear( entity old_zone )
{
// Get the name of the location that the player just left:
string location_name = old_zone.getName();
// and display it on the console for debugging
sys.print ("Spawning pear after leaving " + location_name + "\n");
// spawn the pear entity
entity pear = sys.spawn("atdm:moveable_food_pear");

// and now get the position of the old location entity:
vector origin = old_zone.getOrigin();
// finally move the pear to the point of the info_location
pear.setOrigin( origin );
// so once the player exits this location, ONE pear will spawn and fall down
}
</pre>

== See also ==

* [[Adding ambient Sounds to your Map]]
* [[Dynamic ambient light]].
* [[Ambient Sounds - Zone (using triggers)]]
* [[Sound File Formats]]

{{tutorial-sound}}
{{editing}}
{{tutorial-scripting}}

Setting Up Speakers

2010-12-05T19:22:55Z

Orbweaver: Note to discourage per-speaker volume overrides

This article shows how a mapper can drop a speaker entity in the map and set it up correctly in DarkRadiant. The focus is on shoundshader keywords and how to override them.

== Create A Speaker Entity ==

To create a speaker you can simply click {{RMB}} in DarkRadiant and select "Create speaker...". This will:
* create a speaker entity
* open a window that lets you choose a sound
After choosing a sound you can alter the sound's properties in the entity inspector.

To do that it is handy to know how sounds in our game basically work. Via sound shaders, that is:

== Sound Shaders And Spawnargs ==

A sound shader is a text file that resides in darkmod/sounds and comes with the .sndshd extension. These shaders tell the engine where the .waves or .oggs can be found along with some common parameters.

As an example we look at the shader for "footsteps on stone materials while walking" (you would not put these in game via a speaker normally, but you ''could'' do it since all sounds work technically the same):

<pre>
tdm_footstep_stone_walk
{
description "Made by GoldChocobo"
no_dups
minDistance 1
maxDistance 30
volume -12

sound/sfx/movement/footsteps/player/stone_walk01.ogg
sound/sfx/movement/footsteps/player/stone_walk02.ogg
sound/sfx/movement/footsteps/player/stone_walk03.ogg
sound/sfx/movement/footsteps/player/stone_walk04.ogg
}
</pre>

It starts with the shader name "tdm_footstep_stone_walk". This will show up in DarkRadiant's "Choose sound" dialog. Then we have some keywords followed by the actual sound files and their relative path.

There are four sounds (not only one) to allow variety. They get played in a random order, one each time the sound is triggered. (In most cases, see [[Problem Hearing Varied Sounds]].)

Picking the ''volume'' keyword you can see it is followed by a negative value. These are meant to be decibel (dB), so we can expect 0 to be the maximum while a reduction by 10 approximately is half the volume.

If you created your speaker and wanted to change it's volume in DarkRadiant you would go to the entity inspector (default shortcut: n) and add the spawnarg ''s_volume''. Whatever number you enter here is meant to override the shader setting.

This is what it looks like:

[[Image:Entity-inspector-speaker.png]]

The icons left to the keyword indicate Radiant knows them -- you will get a tooltip on mouseover. If you mistype anything you will see nothing there, which is a good indicator.

So what we have is a system where our shaders provide the default values. We can override these values in the map file using the appropriate spawnargs. Note that not defining anything in the shader as well as in your map file won't crash the game -- there are still fallback values (propably hardcoded in the engine).

In the following list the keywords are presented as a pair, where possible. The soundshader keyword is followed by the corresponding counterpart you would use in DR.

=== volume/ s_volume ===

:The ''volume'' is set in dB. Usually this means there is a maximum of ''0'' dB. The minimum is ''-60'' dB which results in absoulute silence.

:Up to a certain point the game allows the use of positive values as well, but be aware, as this is sensitive:

:To prevent clipping the engine has a mechanism that does not allow the ''volume'' to overdrive your sound hardware. For testing, it can be disabled via the ''s_clipVolumes'' cvar, but if it is active it will clip the ''volume'' for every output sound channel after all the other calculations are done -- this includes stereo panning, so once the volume setting is too high all the speakers (in your headphones, on your stereo) will play the sound at the same maximum volume. It gets virtually monofied, the player no longer is able to locate the sound.

:In general it is best to avoid setting the volume on an individual speaker unless strictly necessary, because it prevents future updates to the volume specified in the sound shader from taking effect in your map. It is preferable to set the volume correctly on the sound shader declaration itself (or request that the Dark Mod team do so, if it is a core asset supplied with the mod).

=== unclamped/ s_unclamped ===

:Possible values are ''0'' and ''1''. This overrides the global ''volume'' clipping and will make your sound bypass the ''s_clipVolumes'' setting.

:Should be used with extra care, can trigger hardware clipping. This will not damage your hardware, but sound real crappy -- keep in mind this is a game and not your favourite tube amp.

=== minDistance/ s_mindistance ===

:This works together with ''maxDistance'' like this:

:[[Image:Mindistance-maxdistance-falloff.png]]

:Around the speaker there is a spherical volume, defined by ''minDistance''. Inside that, the sound plays at the specified full ''volume''. The (hopefully) larger ''maxDistance'' defines a bigger sphere. Outside of it the ''volume'' will be ''0'', inside of it there is a falloff from max. to min.

:Note: '''Do not set ''s_mindistance'' to ''0''!'''

:While a real sound does not have a "mindistance" it will not work to set ''s_mindistance'' to ''0''. A quick test revealed the following behavior:

:[[Image:Mindistance-overrides.png]]

:This shows we can overide the shader values with our spawnarg in DR, but when we set it to ''0'' it counts not as a number but as a toggle that simply disables our intended input. This is as good as deleting the property.

:The value will fall back to the shader default (lucky case is purple, bad cases are red). In the right column (red and yellow field) you can see what happens when no values are provided by the shader nor the spawnarg: doom simply sets the ''minDistance'' to ''1''.

:As a resort mappers can always use ''s_mindistance 1'', that's close enaugh for rock'n'roll.

=== maxDistance/ s_maxdistance ===

:See above. The outlines of ''maxDistance'' can be drag-resized in DarkRadiant. This does not show you the real dispersion of the sound in most cases (due to occlusion, see below).

:Not setting the ''maxDistance'' or at the same time setting ''s_maxdistance'' to ''0'' (which is insane anyway) will cause doom to use ''10'' instead.

=== looping/ s_looping ===

:Turns on and off looping. The sound will repeat endlessly in a forward loop.

=== omnidirectional/ s_omni ===

:The sound will have the same ''volume'' on all speakers, so it sounds like not having a specific origin. Normally used for ambience music (when not using the preferred method via [[Location Settings]]). Works with falloff as provided by ''minDistance'' and ''maxDistance''.

=== global/ s_global ===

:Plays the sound at full ''volume'' everywhere in the map.

=== no_occlusion/ s_occlusion ===

:The shader keyword turns occlusion off, ''s_occlusion'' must be set to ''1'' for the same effect (this is counterintuitive).

:'''What is occlusion?''' -- To resemble a realistic falloff for sounds, the game traces the route to the speaker from the player position through vis_portals instead of line of sight. Even closed doors or windows are taken into account for that calculation.

:If you want your specific sound to be not affected by this, you can turn it off this way.

:Note: it is highly recommended to turn occlusion off for ambient music, or it will fade when you close a door etc.

=== shakes/ s_shakes ===

:A special effect, that shakes the screen when the sound plays. Possible values are fractions between ''0'' and ''1''. This is multiplied with the ''volume'' to determine the intensity of the effect.

:Note: ''s_shakes 0'' will disable itself and fall back to the ''shakes'' value in the shader.

:Note2: Iddevnet says it should not be used with .ogg files.

=== n. a./ s_waitfortrigger ===

:If set to ''1'' the speaker will wait for a trigger to activate it.

=== n. a./ s_shader ===

:Points to the sound shader the speaker uses. Can as well be used to reference audio files directly, when not present in any shader.

=== leadin/ n. a. ===

:Specifies a file that is played as a lead-in to a looped part of the sound.

=== leadinVolume/ n. a. ===

:''Volume'' of the lead-in part in a looped sound.

=== no_dups/ n. a. ===

:This prevents the same audio file out of the multiple ones in a shader to be played twice in a row when randomly playing them.

:Not of any use when your shader references only one file.

=== private/ n. a. ===

:The sound is only present to the player.

=== description/ n. a. ===

:A short discription in the shader. In DarkMod it usually names the creator of the sound.

== See Also ==

When you set up a few sounds, you propably like to check them out in game. Learn about additional tools for [[Debugging Your Speakers]].

Unfortunately I missed [[Sounds: Background and Local]], before creating a bit of an overlap with this article.

Further information can be found at [http://www.modwiki.net/wiki/Sound_(keywords) modwiki.net] or [http://www.iddevnet.com/doom3/sounds.php iddevnet].

[[Category:Sound]]
[[Category:Editing]]

Sounds: Background and Local

2010-06-23T13:07:38Z

Orbweaver: /* Loudness, Volume */

''written by Fidcal''

== Introduction ==

All that is assumed is you know the essentials described in [[Dark Radiant Must Know Basic Intro]]

If you want a global ambient sound heard throughout your mission then also read [[Adding ambient Sounds to your Map]].

This tutorial covers general background sounds, local ambience, environmental, or sounds related to specific objects in the game such as a machine or a drain.

== Sound File Types ==

OGG and WAV files are used in Dark Mod. For details see [[Sound File Formats]]

OGG files are compressed whereas WAV files do not compress well even in zip files (so I'm told!)

You can create your own sounds but there is already a large range provided in Dark Mod ready to use.

Those sound files can be referenced either directly (with full path and name) or via a definition file called a sound shader which can include various controls as well as the name of the sound file and path. Multiple sound file definitions can be included in one sound shader file. Other controls are available as properties in the speaker entity in the map file. These properties will override the equivalent definition in the sound shader.

== Speaker Entity ==

The speaker entity is like a loudspeaker that you place in your mission.

To include a sound in your mission...

* create a speaker entity and position it where you want the sound to be centred.
* Add the property s_shader
* In Dark Radiant you can select a sound shader from the button below the entity properties.

== Properties of the Speaker Entity ==

The following are properties to add to the speaker entity to adjust the way it plays sounds. There is no need to dmap between adjustments of these properties. Assuming you have dmapped once you can just use map to test changes.

Before proceeding, it's worth quoting Orbweaver:

# If a speaker is looping, it will play all the time, but will obviously only be audible when the player is within range.
# If a speaker is non-looping but waits for trigger, then it will do nothing until triggered. Once triggered it will play but will only be audible if the player is within range.
# If a speaker is non-looping and untriggered, it will play once at startup, irrespective of whether the player is near enough to hear it.

== Loudness, Volume ==

The '''s_volume''' property allows you to change the volume of a sound. It specifies the change to the volume of the audio file, in decibels, and may be positive or negative.

Be careful about making sounds too loud with this keyvalue, decibels are fairly "small" units and setting a volume increase of +20dB may well make the sound too loud for players. Ambient sounds should be at a similar volume throughout the map, and should not be so loud as to obliterate important gameplay sounds such as footsteps, or cause the player to reach for their volume control every time they enter a new area.

== Control of volume by 'Ambient Volume' menu setting ==
If you want to give the player user-friendly control over the sound volume (as with ambient music, which some players prefer off), include the keypair "s_music" "1" on the speaker entity.

== Direction of Source, Propogation through Doorways==

s_occlusion 1 makes the sound go in a straight line and not through visportalled gaps like doorways etc. If set to 0 then it follows a natural route through openings.

s_omni 1 makes the sound come from no particular direction so this is ideal for ambience like rainfall or mood music (unless that music is meant to come from something in the game.) Set s_omni to 0 if you want your sound to sound like it is coming from the speaker entity.

== Range, Radius, Distance covered by Sound ==

The units used for the distance reached by the speaker entity are in ''metres'' not Doom units so these approximate 40 normal units. In DoomEd the radius is shown in the grid view and this feature is also being added to Dark Radiant.

* s_mindistance N = distance in metres from speaker at which sound starts to fade. Within that radius it is at full volume.

* s_maxdistance N = distance in metres from speaker beyond which it cannot be heard at all.

==Triggering a Sound==

Speakers by default will start to play at mission start even if the player is not in range to hear them. But speakers can be set to wait for a trigger - so any switch, button or other trigger can start and stop them. To do this, set the property s_waitfortrigger to 1 then the speaker is disabled until triggered by a switch of some sort. Default is 0.

== Playing a Sound Once ==

By default, if no looping or repeat is set up then a speaker will play once at mission start then stop. But unless the player is within range it will not be heard.

So to play a sound once when the player approaches you need a separate vicinity trigger (see also [[#Triggering a Sound]]) that triggers only once. This is how...

* Create and place your speaker and give it the property ''s_waitfortrigger'' with a value of 1
* At the place where you want the player to trigger the sound create a brush with a volume suitable for the trap so the player will pass into it.
* With the brush selected, assign it (create) an entity ''trigger_once''
* The brush automatically gets a ''trigger'' texture which is invisible in-game.
* Add the property ''target'' with the value being the name of your speaker.

When the player moves into that invisible brush it should trigger the speaker to play its sound once only.

== Repeating a Sound Continuously ==

=== s_looping ===

s_looping repeats a sound seamlessly and is the one to use for continuous sound like rain, continuous machinery, etc. (compare also [[#wait (repeat)|wait]] before using this.

s_looping set to 1 means...

# Play sound immediately the player is within range (set by s_maxdistance)
# Wait until the sound has finished playing
# Repeat endlessly unless the player moves out of range (set by s_maxdistance)

Set s_looping to 0 to disable (default)

=== wait (repeat) ===

wait n means repeat every n seconds endlessly so is the one to use to repeat with a gap between plays of the sound. Do NOT use it with s_looping set to 1 because 'wait' repeats on its own and s_looping will override it and repeat immediately and endlessly.

wait n means...

# Play sound immediately the player is within range (set by s_maxdistance)
# Wait n seconds from START of playing sound
# Repeat endlessly unless the player moves out of range (set by s_maxdistance)

What if n is shorter than the length of the wav or ogg file? If there is only a single sound in the sound shader file then it cuts the sound short and starts again. Here's an example of what happens If, eg, you play a bell sound that is 6 seconds long (the original ogg or wav file) and if you set wait 1 then it will...

# start to play the sound
# plays it for 1 second
# will not complete that but...
# begin again at the start every 1 second.

However, if there are multiple sounds in the sound shader file which are selected randomly then they one will be played every N seconds and they will overlap unless it happens to call the same one twice in a row (which can be prevented with nodupes in the sound shader file.)

Use with random to vary the wait time...

=== random ===

Use with the wait property to vary the repeat time. random n varies the wait time randomly by plus or minus n seconds. So for example...

* wait 30
* random 10

...will play the sound repeatedly between 20 to 40 seconds from the start of playing the sound.

If random is greater than wait then it works the same but with a minimum of zero, so....

* wait 10
* random 15

... will play the sound repeatedly between 0 and 25 seconds from the start of playing the sound.

he sound no directional source, ie, it will not seem to come from the direction of the speaker but from all directions.

== Screen Shaking, Explosions, etc. ==

s_shakes set to 1 makes the screen shake when the sound is loud. Suitable for explosions, earthquakes.

==Sound Shader Definition Files==

This to be written. It might need a separate article in which case adjust the link above. Meanwhile here is an external link...

http://www.iddevnet.com/doom3/sounds.php

[[Category:Sound]]
[[Category:Editing]]