Skip to content

Introduction

LKostyra edited this page Aug 16, 2016 · 12 revisions

Directory structure

The engine's root directory looks as follows:

  • Bin - compiled binaries
  • Logs - various logs
  • nfEngine - main engine's code directory
    • nfCommon - common utilities library that could be used outside the engine
    • nfCommonTest - unit tests for nfCommon
    • nfCommonPerfTest - performance tests for nfCommon
    • nfCore - the engine's core
    • nfCoreTest - unit tests for nfCore
    • Tools
      • PackerTool - command line utility for PAK files creation
      • ResourceManager - Tool to manage and convert engine's asset and large files
    • Renderers - directory containing low-level renderer backends and related stuff
      • RendererInterface - set of headers defining low-level renderer API
      • nfRendererD3D11 - Direct3D 11 low-level renderer implementation
      • nfRendererD3D12 - Direct3D 12 low-level renderer implementation
      • nfRendererVk - Vulkan low-level renderer implementation
      • nfRendererOGL4 - OpenGL 4 low-level renderer implementation (currently excluded from build)
    • nfRendererDemo - demo application used for renderers testing
    • nfRendererTest - unit test for renderers
  • nfEngineDeps - engine's dependencies directory (git submodule). See "Dependencies" section for more information
  • nfEngineDemo - demo application
  • Obj - temporary compilation objects
  • Scripts - miscellaneous batch and bash scripts

Dependencies

The engine is dependent on following libraries:

To keep library versions constant throughout development, all dependent libraries are kept in our external nfEngineDeps repo. Libraries are updated on the repo when such need occurs.

Building the project - Windows

To make the code compilable, the following requirements have to be met:

  1. Installed Visual Studio 2015 with Windows SDK.
    • NOTE: Install Windows 10 SDK for Direct3D 12 support.
  2. Pulled external dependencies from here
    • "nfEngineDeps" directory will be created by using git submodules inside repo - fetch its contents by using git submodule update --init command
    • NOTE: Dependencies need to be built separately from engine. See README.md inside nfEngineDeps repo for more info.
  3. Downloaded resources from our FTP server
    • A script called syncher.py allows for quick synchronization with our FTP server. Launch it with syncher.py init to download all the data in one go.
    • After building the Engine, resources must be processed to Core-readable format. For that purpose there is a ResourceManager tool, which will process all downloaded files on one go. After downloading our resources and building the Engine, remember to launch ResourceManager.exe binary.

If there is a need to debug Vulkan Renderer, also remember to install LunarG's Vulkan SDK for Windows

Building the project - Linux

Currently, buildable parts of nfEngine are: nfCommon, nfCommonTest, nfCommonPerfTest, nfRendererVk and nfRendererDemo. Requirements:

  1. Installed a C++11-compatible compiler (right now the only compiler tested to work is GCC 5 and higher versions).
  2. Installed CMake 2.6 or higher.
  3. Pulled external dependencies from here:
    • "nfEngineDeps" directory will be created by using git submodules inside repo - fetch its contents by using git submodule update --init
    • NOTE: Dependencies need to be built separately from engine. See README.md inside nfEngineDeps repo for more info.

To rebuild the entire project in one go, Scripts/rebuild-all.sh script is available, which works similarly to "Batch Build" feature in Visual Studio. The script will call cleaning script and build the engine in all configurations possible. Unlike Windows platform, due to conflict between 32-bit and 64-bit versions of some packages, the Engine builds only in version which conforms Distros version.

In order to build the project on one selected configuration, it is recommended to use our building script located in Scripts/build.sh. As an argument, it takes a build type, which is either Debug or Release (case-insensitive). The script will perform an out-of-source build by creating a build directory (ex. build-Release) and calling cmake & make inside it.

If there is a need, user can manually trigger building with CMake by calling cmake and make.