Jump to navigation Jump to search

A backend is part of the engine that handles some low-level task like displaying graphics and can be swapped out for a replacement which achieves the same thing in a different way, usually by using a different library. The OHRRPGCE uses several different backends for graphics and music. Different builds of the engine are available with differing backends or other "compile-time" options. Actually you can only get non-standard nightly builds; if you want a non-standard stable release you either need to compile it yourself, or use a nightly build from a nearby date.

The easiest way to see which backends you are using is to run Game or Custom. At the bottom of the initial screen you'll see a line like "OHRRPGCE wip 20160610 directx/sdl" meaning gfx_directx and music_sdl. You can also examine c/g_debug.txt for lines starting with gfx_### or music_### (don't be fooled by the version info line, which lists all backends compiled in).

You can switch gfx backend by pressing Ctrl-F8 (also available from the F8 in-game debug menu, or the F9 in-editor global settings menu). You can't switch music backend; instead you need to download a different build of the engine.


gfx backends provide the graphics and user-input (keyboard, mouse, joystick/gamepads) and often more (gfx_sdl contains nearly everything to do with Mac OSX or Android). The OHRRPGCE can be compiled with any combination of graphics backends, and the one to use selected with the --gfx commandline switch (run with commandline option "/?" or "--help" for usage information), or swapped at runtime by pressing Ctrl-F8. By default the OHRRPGCE is compiled with support for any of gfx_sdl, gfx_directx, and gfx_fb which are available for the current platform. gfx_sdl2, gfx_alleg and gfx_console are not included by default.

name status description fullscreen smoothing platforms resolutions other than 320x200
gfx_sdl stable Simple DirectMedia Layer (SDL) 1.2 graphics. This is the default backend on GNU/Linux, Macintosh, and Android, and for Custom.exe on Windows Yes Yes GNU/Linux, BSD, Mac, Windows, Android Yes
gfx_sdl2 near-stable Simple DirectMedia Layer (SDL) 2 graphics. Brand new, barely tested. Much better fullscreen handling than gfx_sdl or gfx_fb. Included in Windows nightly builds. The build system currently can't compile gfx_sdl2 for Mac, but it should work there too. gfx_sdl2 can't co-exist in a build that includes gfx_sdl or music_sdl Yes Yes Probably all Yes
gfx_directx stable This backend exists as gfx_directx.dll - all Windows builds normally include support for it even if the .dll isn't included. This is the default backend on Windows for Game.exe. It has better joystick and fullscreen support than gfx_sdl Yes Yes (texture scaling) Windows No
gfx_fb stable Based on Freebasic's standard graphics library. This backend is fairly well-tested and used to be the default, but has a few minor unsolvable problems Windows:Yes
Yes GNU/Linux, BSD, Windows No
gfx_alleg working?, but very little testing
Linux: keyboard input broken
Allegro backend. Not currently compiled for nightly builds (due to a problem with the build machine) Yes No (Mac?, Linux?), Windows No
gfx_console diagnostic Curses-based backend (displays text only, no graphics). For testing only; no builds available. NA NA All No


music backends provide the music and sound effects. Unlike the graphics backend, each build of the engine only supports a single music backend and it isn't possible to switch to a different backend without recompiling. Windows nightly build .zip files have the name of the music backend in the download name, eg All other builds for all platforms, including Windows installers and stable releases use the default, music_sdl.

name status description advanced MIDI looping
music_native Windows:only plays MIDI (MIDI playback very buggy)
Linux:No MIDI support
Audiere and Native windows MIDI. MIDI playback is very buggy. Usually does not work on Linux because Audiere uses OSS. Since some years ago, Audiere has also mysteriously stopped playing anything on Windows. Windows:Yes
music_sdl stable (sometimes crashy on Windows) SDL 1.2+SDL_mixer backend. This is the default everywhere. MIDI playback on Windows sometimes crashes. Variable-bitrates and unusual sample rates are broken. MP3 files with unusual sample rates also cause crashes on Linux machines with old versions of SDL_mixer. Converting .mp3s to .oggs avoids some of these problems. No
music_sdl2 stable SDL 2+SDL2_mixer backend. This must be used instead of music_sdl when compiling with gfx_sdl2. SDL2_mixer and music_sdl2 are almost identical to SDL_mixer and music_sdl, except that they can play audio files of any sample rate correctly, without crashing. Also SDL2_mixer defaults to better libraries for .mp3 and module playback (this affects GNU/Linux users only, as we supply SDL_mixer builds for Windows and Mac which use the better libraries) No
music_allegro obsolete Allegro backend. Unmaintained; no longer works or even compiles. Only worked together with gfx_alleg No
music_native2 only plays MIDI (MIDI playback buggy) (Windows-only) music_native variant with alternative, "better" (but still pretty buggy) MIDI implementation. Identical Audiere sound effects implementation. Since some years ago, Audiere has also mysteriously stopped playing anything on Windows. Controller 111 loop points only
music_silence diagnostic Does not play any music or sound at all. Useful for checking whether or not a bug is related to music. No

Other builds[edit]

These aren't backends but rather are other compile-time options.

name status description
-debug diagnostic Any nightly build with -debug in the filename has been compiled with -g which adds debugging symbols for use with the GNU Debugger, and with -exx which adds extra error checking (asserts) for out-of-bounds array access and null pointer dereferencing. Failed asserts cause the program to instantly exit. These builds are many times slower, something which might be noticeable on very old computers.

See Also[edit]