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_VERSION. Bump it whenever the wire changes incompatibly — packet types, property types, field layouts or the meaning of a field — and leave it alone for releases that don't touch the wire, so those can still play together.

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_PROTOCOL_VERSION_MIN to NCINE_PROTOCOL_VERSION_MAX, which is only this version unless set otherwise.

#define NCINE_PROTOCOL_VERSION_MIN

Oldest client multiplayer protocol version the server accepts.

Together with NCINE_PROTOCOL_VERSION_MAX it bounds the protocol versions of the clients a server lets in, which is checked when a client authenticates. The server announces the range in local discovery, in the public server list and in its answer to the authentication, so the server list can tell which servers the local client fits, and the client can leave a server whose answer carries no range (a server older than the range, which let it in by a looser check of its own).

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_PROTOCOL_VERSION_MIN. Raise it above NCINE_PROTOCOL_VERSION only for a newer protocol version already known to stay compatible with this one.

#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::keyboardState() only to satisfy the interface and never produce a key event, so a key binding on them can never fire. It would still be built into the mapping tables and listed in the controls screen, which is why the defaults skip them entirely.

#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::IsContentPrebaked().

#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::GetEpisodeContinue()) and is saved on every platform, so the N64 remembers which levels have been finished and where an episode was left — only continuing from the middle of a level is unavailable there.

#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