Main.h file
Common nCine header file, includes Common.h and project metadata.
Defines
- #define NCINE_APP
- Application name.
- #define NCINE_APP_NAME
- Application full name.
- #define NCINE_VERSION
- Application version.
- #define NCINE_PROTOCOL_VERSION
- Application multiplayer protocol version.
- #define NCINE_PROTOCOL_VERSION_MIN
- Oldest client multiplayer protocol version the server accepts.
- #define NCINE_PROTOCOL_VERSION_MAX
- Newest client multiplayer protocol version the server accepts.
- #define NCINE_BUILD_YEAR
- Application build year.
- #define NCINE_LINUX_PACKAGE
- Application package name on Linux.
- #define NCINE_INSTALL_PREFIX
- Install prefix on Unix systems, usually
"/usr/local". - #define NCINE_HAS_GAMEPAD_RUMBLE
- Whether the current platform supports a gamepad rumble, see IInputManager::
joystickRumble(). - #define NCINE_HAS_KEYBOARD
- Whether the current platform can deliver keyboard input.
- #define NCINE_HAS_NATIVE_BACK_BUTTON
- Whether the current platform has a native (hardware) back button.
- #define NCINE_HAS_WINDOWS
- Whether the current platform supports vibrations of the device.
- #define NCINE_HAS_TOUCH_CONTROLS
- Whether the current platform can have a touchscreen.
- #define NCINE_HAS_RGB_LIGHTS
- Whether the current platform can drive the RGB lighting of connected devices.
- #define NCINE_HAS_WRITABLE_CACHE
- Whether the current platform can convert the original game data into a cache of its own.
- #define NCINE_HAS_RESUMABLE_STATE
- Whether the current platform can store a resumable mid-level session.
- #define NCINE_CURRENT_FUNCTION
- Whether the audio device plays sound in formats of its own instead of samples the engine decodes.
Define documentation
#define NCINE_PROTOCOL_VERSION
Application multiplayer protocol version.
Decides whether a client and a server can play together, independently of NCINE_
It is compared in full, patch included, so a bump of any component is enough to separate two builds and the number is free to move independently of the release it ships in. Only ever set here: it is deliberately not derived from the build or from Git, so two builds of the same wire format always agree on it.
A server accepts the clients from NCINE_
#define NCINE_PROTOCOL_VERSION_MIN
Oldest client multiplayer protocol version the server accepts.
Together with NCINE_
Lower it only when the server still talks to the older clients correctly, i.e. the wire changed since then only in ways they don't notice, or the server handles those clients differently. Both bounds are inclusive.
#define NCINE_PROTOCOL_VERSION_MAX
Newest client multiplayer protocol version the server accepts.
See NCINE_
#define NCINE_HAS_KEYBOARD
Whether the current platform can deliver keyboard input.
The consoles excluded below have no keyboard the engine can read: their input backends implement IInputManager::
#define NCINE_HAS_WINDOWS
Whether the current platform supports vibrations of the device.
Whether the current platform has non-fullscreen windows
#define NCINE_HAS_TOUCH_CONTROLS
Whether the current platform can have a touchscreen.
Listed rather than excluded, so a platform that has no touchscreen doesn't acquire one by not being mentioned - which is how the consoles ended up offering to configure touch controls.
Where it is not defined, no touch event ever reaches the game (the input backends drop them at the source), so the on-screen controls can never appear - and the code that only serves them is compiled out: the HUD's touch buttons and joystick, the touch dispatch and back arrow of the menus, the touch handling of the in-game console and the multiplayer lobby, and the section that configures the controls. The PS Vita does have a front touchscreen and a rear touchpad, but both sit exactly where the console is held, so they only ever fire by accident - it is played with the sticks and buttons.
#define NCINE_HAS_RGB_LIGHTS
Whether the current platform can drive the RGB lighting of connected devices.
Only Windows (through the Razer Chroma™ SDK) and the web build (through a local bridge) actually do so; the other desktop platforms are included because that is where such a device is plugged in, and where RgbLights could gain a backend without the option having to reappear.
#define NCINE_HAS_WRITABLE_CACHE
Whether the current platform can convert the original game data into a cache of its own.
The Dreamcast and PlayStation 2 play from a disc, the Nintendo 64 from a read-only ROM image, and the GameCube has nowhere to put a cache the size of a converted installation, and the web build is prepared entirely ahead of time - none of them can write one, so they consume a content tree prebaked with AssetPacker, skip the conversion altogether and never look for the original game files, which are not there in the first place.
Everywhere else the first-run conversion exists, including the PlayStation Portable and the Wii, where the content sits on a writable memory stick or SD card. Those two are usually given a prebaked tree as well, which is recognized at runtime rather than assumed here, see ContentResolver::
#define NCINE_HAS_RESUMABLE_STATE
Whether the current platform can store a resumable mid-level session.
The state file is written next to the configuration, and on the Nintendo 64 that is the cartridge EEPROM: libdragon's eepromfs is a fixed table of files declared up front, and the two kilobytes it has hold the configuration alone, so a second file cannot be created there at all. Everything else writes it, including the platforms with no writable content cache — the Dreamcast and the GameCube put it on a memory card next to their settings.
Episode progress does not depend on this. That lives in the configuration itself (PreferencesCache::
#define NCINE_CURRENT_FUNCTION
Whether the audio device plays sound in formats of its own instead of samples the engine decodes.
The content prepared for the Nintendo 64 carries every sound effect as a .wav64 file the mixer streams from the cartridge, and every track as an .xm64 module or a .wav64 recording, all of which libdragon plays without the engine decoding anything. There AudioBuffer and AudioStream only hand files over to the device, and the whole decoding path is compiled out: the audio loaders and readers, sample uploads, the streaming buffer queue and the decoding thread. Everywhere else it is the other way around, and the native playback interface does not exist.
Function name